Plusieurs PMON sur la meme base

[ctenot]

Bonjour à tous,

je souhaiterai avoir vos lumières pour corriger une anomalie que nous rencontrons depuis un certain temps sur une de nos bases 10G/Linux-Redhat.

Je vous explique le phénomène:
- Sur la meme base ORCL en 10g/Linux-Redhat j'ai deux pmon de demarrer. oui oui je sais c'est pas possible... un gentil "ps aux |grep pmon" nous sort 2 process PMON bien diffèrents.

oracle@xxxxx:~> ps aux | grep pmon
oracle 8798 0.0 0.2 749468 18340 ? Ss Aug24 0:25 ora_pmon_orcl
oracle 11967 0.0 0.2 749476 17400 ? Ss 02:08 0:02 ora_pmon_orcl
oracle 29673 0.0 0.0 4800 844 pts/4 S+ 14:43 0:00 grep pmon

- Deux chargements en mémoire est effectué (semaphor)
- En se connectant sous sqlplus (avec le bon ORACLE_SID) en tappant "connect sys@ORCL as sysdba" => la base est open
- En se connectant sous sqlplus (avec le bon ORACLE_SID) en tappant "connect / as sysdba" => la base est Montée mais pas ouverte... et donc quoique l'on fasse, impossible d'avoir des log, puisque en toute logique le DBWriter
- Le dbshut arrete le Pmon qui n'est pas ouverte
- Nous n'avons qu'un jeu de datafile.
- Nous écoutons pour des raisons applicatives sur le port 1523 !!!

Nous avons une seconde machine impossible de reproduire ce phénomène... Une petite idee où chercher???? toute idée serait la bien venue.... car là on commence à devenir dingue !!!!

merci d'avance

Christophe

[a.presles]

il n'y a que le pmon en double ?

On dirai qu'il y a une instance qui pointe bien sur les datafiles et une autre du même nom qui n'a pas pu acceder aux datafile elle n'est pas open car les datafile sont déjas utilisé par la premiere instance.

1) faire un "shutdown immediate" a partir de la connection "/ as sysdba"
2) voir les process en cours pour ORCL :

Code :

ps -ef|grep ORCL

(il ne devrait plus y en avoir)
2bis) si il reste des process les killer
3) si il n'y en a plus. "startup" de la base par la connection "/ as sysdba"

4) re-check des process en cours pour ORCL :

Code :

ps -ef|grep ORCL

bonne chance.

[Heaven93]

ben si, il y a forcément (enfin, j'espère) une alert.log quelque part. tu regardes la date, l'heure de démarrage de la base et tu devrais identifier le PMON qui sert à quelque chose pour pouvoir killer le PMON superflu. ou sinon, shutdown abort et tu killes ce qui reste...
alors c'est quoi l'histoire? une restauration sur une base déjà ouverte par un programme quelconque?

[pachot]

Bonjour,

Sous Unix, une instance est identifiée par ORACLE_HOME + ORACLE_SID
C'est à partir de ces 2 valeurs que les process se rattachent à la SGA

Je pense que tes 2 instances ont été lançées avec 2 valeurs de ORACLE_HOME différents.

Attention, il peut même s'il s'agir du même répertoire, genre:
/oracle/10.2 et /oracle/10.2/ ou /oracle//10.2

Il faut faire attention à setter ORACLE_HOME de la même manière partout (variables d'environnement, oratab, listener.ora, ... )

Cordialement,
Franck.

[ctenot]

Amis DBA,

Bon je n'ai pas eu trop de temps pour répondre et vous informer de la solution... "pachot" a répondu au problème.
En faite il s'agit d'un bug Oracle sur le parseur du ORACLE_HOME.
En resumé si ton ORACLE_HOME est egal à "/oracle/10.2", tu démarres ta base sans soucis... Pour peu que dans ton ORATAB tu ai "/oracle/10.2/" et bien pour lui c'est diffèrent mais pareil, il redémarre une base avec le même ORACLE_SID, même fichier etc.... On peut aller très loin comme ça... au diable l'avarice, ORACLE_HOME= "/oracle/10.2//", et hop on en redémarre une troisième...etc... etc.... je vous laisse imaginer la cata sur une base de prod... Autant de mémoire bouffée, de sémaphores, le même fichier alert, plusieurs pmon, nmon, etc... toute pointant sur les mêmes datafiles.... tout ça pour un P***** de "/".... aaaaahhh !!!!!

En espérant que ce post sera util à qq un et qu'il gagnera le temps que j'ai perdu à m'arracher les cheveux !!!!!!

Christophe