Voting Disk corrompu et... aucune sauvegarde!

Suite à un "downgrade" du clusterware 11gR2 à la version 10gR2 (10.2.0.4), nous n'avons pas réussi à redémarrer le CRS correctement. Après quelques investigations dans les différents fichiers de trace (.log), j'ai alors remarqué le message suivant dans le fichier "cssd.log"

ERROR:   clssnmvReadFatal: voting device corrupt (0x00000000/0x00000000/0//dev/vd1_sys_1g)

Pour remédier à ce problème, nous avons du recréer le "voting disk" car nous n'avions aucune sauvegarde à notre disposition ni de mirroring... chose à ne pas faire.

Voici les étapes effectuées. Ceci a été effectué sur une plate-forme AIX dont les produits Oracle étaient de la version 10gR2 (10.2.0.4)

• Arrêt complet du clusterware

Dans notre cas, la commande "crsctl stop crs" ne fonctionnait pas alors nous avons désactivé le démarrage automatique (init.crs disable) puis redémarrer chacun des noeuds.

• Ajout d'un nouveau raw device

L'administrateur de système nous a alloué un nouveau disque d'une capacité d'un gigaoctet.

• Afficher le voting disk actuel

#crsctl query css votedisk

Cette commande nous a retourné le nom complet du voting disk (ex. /dev/vd1_sys_1g)

• Ajouter un voting disk en précisant l'emplacement exact

# crsctl add css votedisk [/chemin/nom] -force

Ex. # crsctl add css votedisk /dev/vd1_sys_2g -force

• Détruire le voting disk corrompu en spécifiant le chemin complet

# crsctl delete css votedisk [/chemin/nom] -force

Ex. # crsctl delete css votedisk /dev/vd1_sys_1g -force

• Redémarrer le cluster

# crsctl start crs

• Vérifier le nouveau voting disk

# crsctl query css votedisk

Suite à toutes ces étapes, nous nous sommes empressé de recommander la mise en place d'une sauvegarde du voting disk dans la procédure de sauvegarde existante et, de créer au minimum un second voting disk.

Statut inconnu (UNKNOWN) de l'instance ASM sous RAC

Voici une situation vécue avec une instance ASM 10g (10.2.0.4) dans un environnement Oracle Real Application Cluster (RAC) 10gR2 sur la plateforme IBM AIX 64 bits.

Le statut de l'instance ASM est devenu "UNKNOWN" et celles des bases de données hébergées sur le même noeud sont OFFLINE. Que se passe-t-il ?

Afin de comprendre, je me suis dirigé vers les fichiers de trace sous l'ORACLE_HOME d'Oracle ASM situé à l'emplacement suivant puis vérifier le contenu du fichier "ora.noeud01.ASM1.asm.log" :

$ cd /opt/oracle/product/asm10g/log/noeud01/racg
$ vi ora.noeud01.ASM1.asm.log (writing error)

Le fichier de trace contenait l'erreur suivante :

RACG][1] [905406][1][ora.noeud01.ASM1.asm]: CLSR-0006: Error encountered when writing file /opt/oracle/product/crs10g/racg/tmp/ora.noeud01.ASM1.asm.ora

Je me suis alors déplacé vers le répertoire "/opt/oracle/product/crs10g/racg/tmp" pour vérifier les fichiers présents et leurs permissions.

$ cd /opt/oracle/product/crs10g/racg/tmp
$ ls -al

Voyant que tout semblait correct et que rien n'attirait mon attention, j'ai prit la décision de déplacer tous les fichiers de ce répertoire vers un autre répertoire dans le but de laisser Oracle les recréer au besoin :

# mkdir -p /tmp/backup
# mv * /tmp/backup

Suite au déplacement, j'ai redémarré le CRS puis revérifier graduellement le statut de chacune des composantes :

# crsctl stop crs
# crsctl start crs
# crsctl check crs
# crs_stat.sh

Toutes les composantes ont redémarrées correctement. Maintenant, je dois investiguer pour comprendre ce qu'il s'est réellement passé.

INS-40406 avec Oracle Universal Installer

Lors d'une tentative de migration d'Oracle Clusterware de 10g à la version 11gR2, nous avons rencontré l'erreur INS-40406. Le programme d'installation ne voyait pas la présence d'un cluster.

Suite à plusieurs recherches, nous avons remarqué qu'il manquait le paramètre : CRS="true" dans le fichier "inventory.xml" vis-à-vis la balise correspondant à l'ORACLE_HOME du cluster.

Après avoir ajouter le paramètre, le programme d'installation a reconnu le cluster.

Exemple : CRS="true"