Le responsable « Stockage » s’est caché sous votre bureau devant lequel s’entasse l’ensemble de la sous-direction ?
Votre base métier stratégique en RAC s’est littéralement écrasée ?
Le DBA vous annonce qu’il ne peut absolument rien faire ?
La Database est incapable d’écrire dans ses volumes ASM, il n’y a tout simplement plus de LUN ? Et malgré la remise ne place du LUN, il semble impossible de remettre en place le diskgroup ASM impacté…
N’esquivez plus le bureau de votre DSI ! Lisez ce retour sur incident, cela vous dépannera peut être…

Situation et vocable

Tout se déroulait tranquillement, l’opération de maintenance du SAN n’était qu’une routine, cela, jusqu’à ce que les Applications vous appellent, puis les Users, puis les Sales ect…
Votre base métier principale est à l’arrêt tout net, et votre DBA ne peut absolument rien faire; et pour cause, un intervenant de l’équipe storage a provoqué la perte sèche d’un LUN sur lequel s’appuyait ASM et cela en plein fonctionnement nominal de votre production. Nous disposons donc d’une baie de disques découpée en espaces de stockage présentés sous forme de volumes aux serveurs distants du réseau SAN via des LUN. Ce sont ces volumes que l’on a formaté en partition, puis utilisé comme diskgroup Oracle ASM.
LUN (Logical Unit Number) désigne une unité logique d’un équipement SCSI. Par extension cet acronyme désigne également le numéro d’identification d’une unité de stockage SAN. Bien que LUN réfère strictement à l’identifiant numérique de l’unité, il est également souvent employé pour désigner l’espace de stockage lui-même.
Dans un réseau SAN, un LUN est le numéro d’identification d’un espace de stockage présenté à un ou plusieurs serveurs. Chaque carte HBA d’un serveur connecté possède un WWN unique et l’administrateur du SAN peut ainsi définir pour chaque espace de stockage existant le numéro sous lequel il doit être présenté à chacun des serveurs connectés. Cette notion est importante dans un SAN puisqu’elle permet de présenter ou pas chaque LUN selon le serveur, c’est la notion de LUN masking ou présentation.
¤ Dans notre cas, en plein fonctionnement nominal de la production, le serveur ne s’est plus vu présenté son LUN de stockage sur lequel s’appuyait ASM.
ASM (Automatic Storage Management) est une fonctionnalité incluse dans Oracle 10g (depuis la version 10gR1), qui a pour but de simplifier la gestion des fichiers de la base de données.
Pour ce faire, ASM ajoute la capacité à gérer un système de fichiers et des volumes de disques durs directement dans le noyau du gestionnaire de la base de données Oracle, permettant la gestion des disques et fichiers avec des requêtes SQL familières à l’intérieur même d’Oracle. Ainsi, les administrateurs de bases de données n’ont plus besoin d’avoir des compétences supplémentaires sur les systèmes de fichiers ou les gestionnaires de volumes habituellement proposés par les systèmes d’exploitation.
Avec l’utilisation d’ASM :
* Les Écritures/Lectures sont réparties sur tous les disques disponibles
* Réorganisation automatique et à chaud dès l’ajout ou la suppression de capacité de stockage
* Maintien des copies redondantes et support des fonctionnalités RAID tiers
* Supporte le multipathing via des technologies tiers (Tolérance de panne et répartition de charge sur les accès SAN par exemple)
L’installation ASM consiste à installer et à créer une instance Oracle ASM, puis à configurer les groupes de disques ASM nécessaires.
Un groupe de disques ASM correspond à un ensemble de périphériques de disques qui stocke les fichiers de données gérés par les instances Oracle ASM en tant qu’unité. Les instances Oracle ASM montent les groupes de disques afin que les fichiers Oracle ASM soient disponibles pour toutes les instances de base de données.
¤ Dans notre cas, en plein fonctionnement nominal de la production, les instances Oracle ASM ont perdu un périphérique de disque (la partition montée sur le LUN présenté au serveur).

Exposé de la situation

On arrête les applications impactées, on arrête le serveur de DB proprement et on s’arrange pour qu’en cas de reboot de ce serveur la DB et son listener ne démarrent pas en automatique. On demande au responsable Storage de « remettre en place » (présentation) le LUN exactement comme il l’était. Ici ce qui est le plus dangereux ce n’est pas tant d’avoir perdu la présentation du LUN, que de ne surtout pas perdre le LUN et l’espace physique correspondant en baie de disque. Pas de bricolage, on remonte à l’identique si on le peut. Enfin on démarre le serveur de DB
Dans notre cas, disons que nous avons perdu le groupe de disque DGINDEX1 et ce qu’il contenait, le tablespace IDXTAB.
Essayons de remonter le diskgroup DGINDEX1.

SQL> alter diskgroup DGINDEX1 mount
NOTE: cache registered group DGINDEX1 number=2 incarn=0xc93853dc
NOTE: cache began mount (first) of group DGINDEX1 number=2 incarn=0xc93853dc
NOTE: Assigning number (2,0) to disk (/dev/oracleasm/disks/INDEX21)
NOTE: GMON heartbeating for grp 2
GMON querying group 2 at 78 for pid 31, osid 19791
NOTE: Assigning number (2,1) to disk ()
GMON querying group 2 at 79 for pid 31, osid 19791
NOTE: cache dismounting (clean) group 2/0xC93853DC (DGINDEX1)
NOTE: messaging CKPT to quiesce pins Unix process pid: 19791, image: oracle@OWEB-B6-H (TNS V1-V3)
NOTE: dbwr not being msg'd to dismount
NOTE: lgwr not being msg'd to dismount
NOTE: cache dismounted group 2/0xC93853DC (DGINDEX1)ora
NOTE: cache ending mount (fail) of group DGINDEX1 number=2 incarn=0xc93853dc
NOTE: cache deleting context for group DGINDEX1 2/0xc93853dc
GMON dismounting group 2 at 80 for pid 31, osid 19791
NOTE: Disk in mode 0x8 marked for de-assignment
NOTE: Disk in mode 0x8 marked for de-assignment
ERROR: diskgroup DGINDEX1 was not mounted
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "1" is missing from group number "2"

=> KO : c’est un échec.
Les disques présentés à ASM sont-ils tous éligibles aux diskgroups ?

oracleasm listdisks
 DATA11
 DATA12
 etc...
 INDEX21 => non présent, or le disque INDEX21 est celui sur lequel il y avait le diskgroup DGINDEX1.
 INDEX22

=> KO
Essayons de voir si l’on peut recréer le disque INDEX21 au niveau système

oracleasm createdisks /dev/mapper/INDEX22p1
=> OK
oracleasm listsdiks
 DATA11
 DATA12
 etc...
 INDEX21 => présent !
 INDEX22
Tentative de mount du diskgroup dans ASM : même erreur qu'au début.

=> KO
Essayons de supprimer le diskgroup et le disque ASMlib

SQL>DROP DISKGROUP DGINDEX1 including contents;
SQL> select name from v$asm_diskgroup;
=> OK : il n'est plus présent.
Suppression du disque ASMlib
oracleasm deletedisks INDEX22
=> OK
oracleasm deletedisks INDEX21
=> KO
(nous sommes en RAC dans cet exemple)
On désactive crs sur les 2 serveurs
crsctl disable crs
On reboot les serveurs
reboot
Suppression du disque ASMlib
oracleasm deletedisks INDEX21
=> KO

=> KO
Bilan et qualification du problème
En fait quoique vous fassiez vous allez tourner en boucle et en arriver à un instant ou à un autre à ne pas pouvoir monter, réparer ou supprimer le diskgroup ASM. De plus il est même possible que les données physiques présentes dans le disque ne soient plus utilisables. Hors en situation d’arrêt de production, vous n’avez pas le temps qu’il faudrait pour analyser tout cela avec minutie, il vous faut une procédure rapide (et souvent radicale) mais surtout efficace.

Et maintenant, que fait-on ?

Le vrai problème c’est qu’en fait la suppression à chaud d’un LUN provoque dans notre exemple une corruption, et que cette corruption se solutionne par une purge complète avec recréation complète. OracleMySupport conseille donc de faire un erase de la partition pour en purger le données, descripteurs ect… Et remettre tout à plat comme au premier jour. Et ici ATTENTION, nous avons pu le faire car nous avions dans les logs le script de création du diskgroup. Cela est peu probable, mais cela existe, il est possible aussi d’avoir des backups des référentiels ASM. Dans tout les cas vous constaterez ici, combien il est essentiel de conserver noté ce qui a été crée et comment. Si vous n’avez pas accès à ces informations la suite de cet article ne vous aidera pas.

Erase de la partition
dd if=/dev/null of=/dev/mapper/INDEX21p1
=> OK
Suppression du disque ASMlib
oracleasm deletedisks INDEX21
=> OK
Recréation des disks ASMlib
oracleasm createdisks /dev/mapper/INDEX21p1
oracleasm createdisks /dev/mapper/INDEX22p1
=> OK
Recréation diskgroup à partir du script de creation du diskgroup trouvé dans l'alert log ou du dossier d'installation
CREATE DISKGROUP DGINDEX1 EXTERNAL REDUNDANCY DISK '/dev/oracleasm/disks/INDEX21' SIZE 204797M ,
'/dev/oracleasm/disks/INDEX22' SIZE 204797M ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='4M';
=> OK

=> OK!

Restauration

Nous tentons un démarrage de la BD sur un seul noeud, comme cela était prévisible le datafile d’index a été endommagé. En pareil cas il faut donc restaurer et réparer le datafile.

[oracle@OWEB-B6-H ~]$ rman target /
RMAN> restore tablespace idxtab;
RMAN> recover tablespace idxtab

=> OK
On ouvre la base et si tout est OK on reboot le serveur en remettant les paramètres par défaut (ici démarrage automatique de la DB et du listener).

RMAN> alter database open
RMAN> shutdown immediate
ROOT> reboot

=> OK
On réactive la couche CRS du RAC.

=NODE2=
ROOT> /u01/oracle/grid/11.2.0.3/bin/crsctl enable crs
CMD> srvctl stop LISTENER
CMD> srvctl disable LISTENER
CMD> tnsping OWEBR2
CMD> ps -ef | grep lnsr
ROOT> reboot
=NODE1=
ROOT> ps -ef | grep pmon
ROOT> ps -ef | grep lnsr

=> OK

=NODE1=
SQL> select * from v$instance;
SQL> select TABLESPACE_NAME,FILE_NAME,STATUS from dba_data_files;
CMD> tail -fn 100 /u01/oracle/product/diag/rdbms/XXXXX/XXXXX1/trace/alert_XXXXX1.log
 ORA-12012: erreur d'exécution automatique du travail
 => Jobs liés à la DB => impossible de les empêcher de démarrer.
=NODE2=
ROOT> ps -ef | grep pmon
 ROOT> ps -ef | grep lnsr
SQL> select * from v$instance;
SQL> select TABLESPACE_NAME,FILE_NAME,STATUS from dba_data_files;
CMD> tail -fn 100 /u01/oracle/product/diag/rdbms/owebr/OWEBR2/trace/alert_OWEBR2.log

=> OK
On start les listeners et on start les applicatifs

CMD> srvctl enable LISTENER
CMD> srvctl start LISTENER
CMD> ps -ef | grep lnsr

Start, tests, et retour des applications ?
=> OK !!!