L’alerte commence, comme souvent, avec un « connexion impossible à la base, le tnsping fonctionne, il doit y avoir un problème avec l’enregistrement des bases dans le listener » . Il s’agit d’un cluster hébergeant deux bases BLU et RED en actif/passif, une instance seule sur chacun des noeuds.
Donc me voilà parti tête baissée vérifier avec un lsnrctl status, et là, première lampe rouge qui clignote, les entrées statiques pour le dataguard vont bien, mais instances de bases qui ont un statut BLOCKED. Dans ces conditions BLOCKED = base en statut NOMOUNT!!
Je relève la tête et pars voir les alert logs, et là plus gros soucis

...
ALTER DATABASE   MOUNT
Tue Jun  5 17:20:42 2012
ORA-00202: control file: '+BLU_REDO/blu/control01.ctl'
ORA-17503: ksfdopn:2 Failed to open file +BLU_REDO/blu/control01.ctl
ORA-15001: diskgroup "BLU_REDO" does not exist or is not mounted
ORA-15077: could not locate ASM instance serving a required diskgroup
...

Donc sans les 3 controlfile usuels, nous n’allons pas aller loin sans chirurgie majeure, mais que se passe-t-il avec nos disques ASM? Comme c’est du Grid Infrastrucure 11gR2, me voilà parti en root vérifier

oracleasm listdisks
oracleasm : command not found

Pas d’asmlib installé sur ce serveur, dommage, passons au plan B vérifier dans une session sqlplus

su - grid
sqlplus / as sysasm
select MOUNT_STATUS, HEADER_STATUS, NAME from v$asm_disk;
MOUNT_S HEADER_STATU STATE    NAME
-------- ------------ -------- ------------------------------
CLOSED  MEMBER       NORMAL
CLOSED  MEMBER       NORMAL
CLOSED  MEMBER       NORMAL
CLOSED  CANDIDATE    NORMAL
CLOSED  CANDIDATE    NORMAL
CLOSED  CANDIDATE    NORMAL
CLOSED  CANDIDATE    NORMAL
CLOSED  CANDIDATE    NORMAL
CLOSED  CANDIDATE    NORMAL
CACHED  MEMBER       NORMAL   CRS_0001
CACHED  MEMBER       NORMAL   CRS_0000
CACHED  MEMBER       NORMAL   BLU_DATA_0000
CACHED  MEMBER       NORMAL   RED_DATA_0000

Des disques en CANDIDATE, ce n’est pas bon du tout, surtout qu’en vérifiant la vue v$asm_disgroup, on voit clairement qu’il manque des disques:

select group_number,name,state,type from v$asm_diskgroup order by 1;
GROUP_NUMBER NAME            STATE
------------ --------------- -----------
           1 CRS             MOUNTED
           2 BLU_DATA        MOUNTED
           3 RED_DATA        MOUNTED
           4 BLU_REDO        DISMOUNTED
           5 RED_ARCH        DISMOUNTED
           6 RED_REDO        DISMOUNTED

Donc je m’inquiète du sort de 3 disques ASM qui doivent s’appeler RED_REDO_0000, RED_ARCH_0000 et BLU_REDO_000. Comme nous somme en stockage EMC, les LUN sont visibles dans /dev/emcpowerX:

for disk in a b c d e f ; do fdisk /dev/emcpower$disk -l | grep -i Disk; done
Disk /dev/emcpowera: 10.7 GB, 10737418240 bytes
Disk /dev/emcpowerb: 287.7 GB, 287762808832 bytes
Disk /dev/emcpowerc: 575.5 GB, 575525617664 bytes
Disk /dev/emcpowerd: 848.2 GB, 848256040960 bytes
Disk /dev/emcpowere: 805.3 GB, 805306368000 bytes
Disk /dev/emcpowerf: 21.4 GB, 21474836480 bytes

Merci à Jérôme pour la requête ;o)
Et quasiment la même chose sur l’autre noeud, sauf que emcpowerb et emcpowerd sont inversés, mais cela ne devrait pas causer de soucis pour ASM. Donc les LUNS sont correctement présentées et vues par les systèmes. Allons voir du coté des en-têtes ASM. Là je tombe sur la note 1062954.1 qui fait référence à un bug EMC qui a la fâcheuse manie d’effacer des entêtes de disques au hasard, là je commence à avoir des sueurs froides: a-t-on fait une sauvegarde des méta-données avec md_backup, si oui où est-il? Comment utiliser md_restore? Allons-nous devoir recréer les entêtes des 3 disques ASM, y recopier des controlfile et certainement redescendre les sauvegarde RMAN de 2 bases en production?
Donc commençons par vérifier les en-têtes ASM, nous pouvons utiliser 2 outils: od et kfed:
od est outil système qui permet de faire un dump des en-têtes:

od -c /dev/emcpowerc1 | head -15
0000000 001 202 001 001               200 247   l   y   m
0000020                               
0000040   O   R   C   L   D   I   S   K               
0000060                               
0000100          v     001 003  R  E  D _   R   E   D   O
0000120   _   0   0   0   0                     
0000140                   R   E   D   _   R   E   D   O
0000160                               
0000200                   R   E   D   _   R   E   D   O
0000220   _   0   0   0   0                     
0000240

une fois que l’on enlève les espaces, on voit clairement deux infos importantes:
ORCLDISK qui signifie « Je suis un disque ASM », et RED_REDO_0000 qui est le libellé du disque ASM. Pour être sur que les en-têtes sont bonnes, on peut utiliser kfed dans $GRID_HOME/bin pour voir le détail en language humain. Je l’ai lancé en root, donc avant pour positionner les variables d’environnement un coup de:

. oraenv
+ASM1

Et kfed est dans le $PATH!! On doit aussi pouvoir utiliser kfed en grid, mais je ne l’ai pas testé. Comme c’est assez verbeux, on filtre le résultat:

kfed read /dev/emcpowerc1 | egrep 'dskname|grpname|fgname|hdrsts|prov'
kfdhdb.driver.provstr:         ORCLDISK ; 0x000: length=8
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:           RED_REDO_0000 ; 0x028: length=13
kfdhdb.grpname:                RED_REDO ; 0x048: length=8
kfdhdb.fgname:            RED_REDO_0000 ; 0x068: length=13

Donc le disk ASM est sain (noter les noms du disque ASM et du groupe auquel il appartient) et surtout pas de md_restore à faire, donc tentons de force un montage de ces disques, connectons nous en sqlplus / as sysasm:

alter diskgroup BLU_REDO mount;
alter diskgroup RED_REDO mount;
alter diskgroup RED_ARCH mount;

Et là l’ASM revoit ses disques comme si de rien était:

select group_number,name,state,type from v$asm_diskgroup order by 1;
GROUP_NUMBER NAME            STATE
------------ --------------- -----------
           1 CRS             MOUNTED
           2 BLU_DATA        MOUNTED
           3 RED_DATA        MOUNTED
           4 BLU_REDO        MOUNTED
           5 RED_ARCH        MOUNTED
           6 RED_REDO        MOUNTED

les bases BLU et RED démarrent, toujours en grid, avec leur commande

crsctl start resource BLU.db
crsctl start resource RED.db

Conclusion

• On pourrait croire que v$asm_disk référence tous les disques contenant des en-têtes ASM, et bien pas complètement, on a vu que la vue pouvait ne pas afficher le nom, et qu’il suffit de remonter les groupes de disques avec la commande alter diskgroup <NOM_DG> mount;
• On peut utiliser les commande od et kfed pour examiner les entêtes des disques ASM
• kfed peut également réparer les entêtes avec une commande du style

kfed repair /dev/emcpowerc1

• Attention cette commande est risquée, et Oracle déconseille de l’utiliser sans l’aval du Support. Elle fonctionne car depuis Oracle ASM 11.1.0.7, ASM écrit de lui-même une sauvegarde des données dans l’en-tête
• Sauvegardez les meta-données avec md_backup tous les jours et, bien sûr, testez la procédure de restauration (md_destore) sur votre pre-prod