Bonjour, Communauté! Bonne journée! Le local technique est soudainement mis hors tension, mais Oracle ne peut pas être démarré après le démarra

 Bonjour mon cher

Partager un cas avec vous
L'erreur 1102 peut avoir les possibilités suivantes:
1. Dans le système haute disponibilité, d'autres nœuds ont démarré des instances, occupant des ressources partagées par les deux machines (telles que des périphériques bruts sur la matrice de disques);
2. Expliquez que lorsque Oracle a été arrêté de manière anormale, certaines ressources n'ont pas été libérées, il existe généralement les possibilités suivantes:
1. Le segment de mémoire partagée ou le sémaphore d'Oracle n'a pas été libéré;
2. Les processus d'arrière-plan Oracle (tels que SMON, PMON, DBWn, etc.) ne sont pas fermés;
3. Les fichiers lk <sid> et sgadef <sid> .dbf utilisés pour verrouiller la mémoire n'ont pas été supprimés.
Tout d'abord, bien que notre système soit un système HA, l'instance du nœud de secours est toujours dans un état fermé, ce qui peut être confirmé en vérifiant l'état de la base de données sur le nœud de secours.
Deuxièmement, la base de données était en panne en raison d'une panne de courant du système. Le système a été redémarré après la mise sous tension, nous avons donc exclu le deuxième point possible 1, 2 points. Le plus suspect est le point 3.
Vérifiez le répertoire $ ORACLE_HOME / dbs:
$ cd $ ORACLE_HOME / dbs
$ ls sgadef *
sgadef * not found
$ ls lk *
lkORA92
Effectivement, le fichier lk <sid> n'a pas été supprimé. Supprimez-le
$ rm lk *
Redémarrez la base de données et réussissez.
Si vous pensez que la mémoire partagée n'a pas été libérée, vous pouvez utiliser la commande suivante pour afficher:
$ ipcs -mop État
IPC de / dev / kmem au jeu 6 juillet 14:41:43 2006
T ID KEY MODE OWNER GROUP NATTCH CPID LPID
Mémoire partagée:
m 0 0x411c29d6 --rw-rw-rw- root root 0899899
m 1 0x4e0c0002 --rw-rw-rw- racine racine 2899901
m 2 0x4120007a --rw-rw-rw- racine racine
2899901 m 458755 0x0c6629c9 --rw-r ----- racine sys 2 9113 17065
m 4 0x06347849 --rw-rw-rw- racine racine 1 1661 9150
m 65541 0xffffffff --rw-r - r-- racine racine 0 1659 1659
m 524294 0x5e100011 --rw ------- racine racine 1 1811 1811
m 851975 0x5fe48aa4 --rw-r ----- oracle oinstall 66 2017 25076
Ensuite, son numéro d'identification efface le segment de mémoire partagée:
$ ipcrm –m 851975
Pour les sémaphores, vous pouvez utiliser la commande suivante pour afficher:
$ ipcs -sop
IPC état de / dev / kmem au jeu.6 juillet 14:44:16 2006
T ID KEY MODE OWNER GROUP
Sémaphores:
s 0 0x4f1c0139 --ra ------- root root
... ...
s 14 0x6c200ad8 - -ra-ra-ra- racine racine
s 15 0x6d200ad8 --ra-ra-ra- racine racine
s 16 0x6f200ad8 --ra-ra-racine racine
s 17 0xffffffff --ra-r - r-- racine racine
s 18 0x410c05c7 --ra-ra-ra- racine racine
s 19 0x00446f6e --ra-r - r-- racine racine
s 20 0x00446f6d --ra-r - r-- racine racine
s 21 0x00000001 --ra-ra-ra- racine racine
s 45078 0x67e72b58 --ra- r ----- oracle oinstall
Selon l'ID du sémaphore, utilisez la commande suivante pour effacer le sémaphore:
$ ipcrm -s 45078
Si le processus Oracle n'est pas fermé, utilisez la commande suivante pour trouver le processus Oracle existant:
$ ps -ef | grep ora
  oracle 29976 1 0 22 juin? 0:52 ora_dbw0_ora92
  oracle 29978 1 0 22 juin? 0:51 ora_dbw1_ora92
  oracle 5128 1 0 5 juil.? 0:00 oracleora92 (LOCAL = NO)
...
Ensuite, utilisez la commande kill -9 pour tuer le processus
$ kill -9 <PID>
Lorsqu'une erreur 1102 se produit, vous pouvez vérifier et dépanner selon le processus suivant:
S'il s'agit d'un système HA, vérifiez si d'autres nœuds ont démarré des instances;
Vérifiez si le processus Oracle existe, s'il existe, arrêtez le processus;
Vérifiez si le sémaphore existe, s'il existe, effacez le sémaphore;
Vérifiez si le segment de mémoire partagée existe, s'il existe, effacez le segment de mémoire partagée;
Vérifiez si les fichiers de mémoire de verrouillage lk <sid> et sgadef <sid> .dbf existent, et si c'est le cas, supprimez-les.