J'ai vécu dernièrement un problème chez un client.
Les contrôleurs du SAN ont été mis à jour pour passer de la version IBM NSeries N7950T Data ONTAP 8.0.2P3 à la version 8.1.1.
Il faut dire que chez ce client nous utilisons Oracle Linux 5.5 with Unbreakable Enterprise Kernel 2.6.32. Comme produit oracle impacté, nous avons le Grid Infrastructure 11.2.0.3.
Il faut aussi souligner que dans cet environnement ASMLIB est utilisé.
Après la mise à jour, aucun diskgroup ne pouvait être monté, et comme nous avons l'OCR et le voting disk dans ASM, le clusterware ne pouvait démarrer.
Nous avions pourtant quelques process du clusterware:
[oracle@node1 ~]$ ps -ef | grep d.bin
oracle 18807 1 0 17:43 ? 00:00:01 /ora01/logi/crs/crs_11g/bin/ocssd.bin
root 25069 1 0 15:19 ? 00:00:16 /ora01/logi/crs/crs_11g/bin/ohasd.bin reboot
oracle 27383 27339 0 17:51 pts/3 00:00:00 grep d.bin
oracle 31906 1 0 15:21 ? 00:00:00 /ora01/logi/crs/crs_11g/bin/mdnsd.bin
oracle 31921 1 0 15:21 ? 00:00:06 /ora01/logi/crs/crs_11g/bin/gpnpd.bin
oracle 31936 1 0 15:21 ? 00:00:14 /ora01/logi/crs/crs_11g/bin/gipcd.bin
root 31955 1 1 15:21 ? 00:02:21 /ora01/logi/crs/crs_11g/bin/osysmond.bin
[oracle@node1 ~]$
Dans le fichier $GRID_HOME/log/node1/cssd/ocssd.log, on avait l'information suivante:
2012-10-13 13:47:50.130: [ CSSD][1095424320]clssnmvDiskVerify: Successful discovery of 0 disks
2012-10-13 13:47:50.130: [ CSSD][1095424320]clssnmCompleteInitVFDiscovery: Completing initial voting file discovery
2012-10-13 13:47:50.130: [ CSSD][1095424320]clssnmvFindInitialConfigs: No voting files found
Lorsqu'on essayait de monter un diskgroup manuellement, on avait le message d'erreur:
SQL> alter diskgroup DATA11G mount;
alter diskgroup DATA11G mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15017: diskgroup "DATA11G" cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup
"DATA11G"
ORA-15085: ASM disk "" has inconsistent sector size.
ORA-15085: ASM disk "" has inconsistent sector size.
ORA-15085: ASM disk "" has inconsistent sector size.
ORA-15085: ASM disk "" has inconsistent sector size.
ORA-15085: ASM disk "" has inconsistent sector size.
Voila ce qu'oracle dit de ce message d'erreur:
======================================================
15085, 00000, "ASM disk \"%s\" has inconsistent sector size."
// *Cause: An attempt to mount a diskgroup failed because a disk reported
// inconsistent sector size value.
// *Action: Use disks with sector size consistent with Diskgroup sector size,
// or make sure the operating system can accurately report the disk
// sector size.
======================================================
Le problème est dû au fait qu'après la mise à jour des controleurs du SAN, ASMLIB a commencé à voir des blocks de 4k alors qu'avant la mise à jour il voyait des blocks de 512 bytes.
Conséquence, le Sector size est passé de 512 à 4096:
> for i in `ls /dev/oracleasm/disks/*`
> do
> blockdev --report $i
> done
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 0 838914048 /dev/oracleasm/disks/DISK_AD1
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 0 838914048 /dev/oracleasm/disks/DISK_AD2
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 0 838914048 /dev/oracleasm/disks/DISK_AD3
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 0 838914048 /dev/oracleasm/disks/DISK_AD4
Les utilitaires tels que le ASM Metadata Dump Utility (AMDU) et KFED montrent qu'il n'y a pas de corruption.
Pour plus d'informations sur ces utilitaires, voir le document:
ASM tools used by Support : KFOD, KFED, AMDU [ID 1485597.1]
Pour tous les disques ASM de l'environnement, la signature ASM imprimée sur le disque semble correcte comme le montre la commande suivante:
[oracle@node1 ~]$ /usr/sbin/oracleasm listdisks |xargs -n 1 oracleasm querydisk -v -d
Disk "DISK_AD1" is a valid ASM disk on device [253, 4]
Disk "DISK_AD2" is a valid ASM disk on device [253, 5]
Disk "DISK_AD3" is a valid ASM disk on device [253, 6]
Disk "DISK_AD4" is a valid ASM disk on device [253, 16]
Après plusieurs échanges entre Oracle, IBM et NetApp, Oracle a décidé qu'on contourne la couche ASMLIB car les autres compagnies ne voulaient pas faire de retour arrière par rapport à leur mise à jour, trouvant cela trop risqué pour notre environnement.
Solution:
Pour résoudre le problème, nous avons été obligé de contourner ASMLIB.
À la suite de ce problème Oracle a créé le document suivant:
Alert: After SAN Firmware Upgrade, ASM Diskgroups ( Using ASMLIB) Cannot Be Mounted Due To ORA-15085: ASM disk "" has inconsistent sector size. (Doc ID 1500460.1)
Pour contourner Asmlib:
1) Démarrer le cluster en mode exclusive comme décrit dans le document:
=)> How to restore ASM based OCR after complete loss of the CRS diskgroup on Linux/Unix systems (Doc ID 1062983.1)
2) Désactiver ASMLIB comme décrit dans le document:
=)> V$ASM_DISK View Shows Both "ORCL:*" & "/dev/oracleasm/disks/*" Paths On 11.2 Release. (Doc ID 1410243.1)
3) Vérifier la configuration:
ASMCMD> dsget
parameter:/dev/oracleasm/disks/*
profile:ORCL:DISK_AD*,ORCL:DISK_FD*,ORCL:DISK_DD*
ASMCMD> dsset --profile '/dev/oracleasm/disks/*'
ASMCMD> dsget
parameter:/dev/oracleasm/disks/*
profile:/dev/oracleasm/disks/*
ASMCMD>
4) Monter les diskgroups:
ASMCMD> mount ocr_vote
ASMCMD> mount data
ASMCMD> mount fra
ASMCMD> mount data11g
ASMCMD> mount fra11g
5) Arrêter et démarrer le clusterware en mode normal (CRS)
Le clusterware a démarré correctement et tous les diskgroups ont été montés.
6) Vérifier les disques:
SQL> select path from v$asm_disk;
PATH
--------------------------------------------------------------------------------
/dev/oracleasm/disks/DISK_AD4
/dev/oracleasm/disks/DISK_AD2
dev/oracleasm/disks/DISK_AD3
/dev/oracleasm/disks/DISK_AD1
7)Vérifier les paramètres:
ASMCMD> dsget
parameter:/dev/oracleasm/disks/*
profile:/dev/oracleasm/disks/*
ASMCMD>
8) Nous avons exécuté “check all norepair“ pour chaque diskgroup et aucune erreur n'a été rapportée:
SQL> alter diskgroup DATA check all norepair;
SQL> alter diskgroup DATA11G check all norepair;
SQL> alter diskgroup FRA check all norepair;
SQL> alter diskgroup FRA11G check all norepair;
SQL> alter diskgroup OCR_VOTE check all norepair;
Évidemment, nous nous sommes posé la question de savoir quelles sont les conséquences de désactiver ASMLIB dans un environnement Linux. À ce sujet, voici la réponse d'oracle support:
The benefits of using ASMLIB are described in the next document:
=)> How To Setup ASM on Linux Using ASMLIB Disks, Raw Devices or Block Devices? (Doc ID 580153.1)
=)> “Page #17”
======================================================
Therefore, by disabling ASMLIB those benefits will not be present.
Après ce problème, oracle a sorti un document dans "My Oracle Support" qui explique quoi faire pour éviter cette situation:
Hope it helps...
Aucun commentaire:
Enregistrer un commentaire