RAC Crash Szenarien – Zerstörter ASM Header einer Disk in gespiegelter ONLINE Diskgroup

Ziel

Dieser Blogeintrag stellt den Start einer neuen Blogserie dar. In dieser Serie werden Ausfall Szenarien in einer Oracle Hochverfügbarkeitsumgebung simuliert. Der erste Beitrag dieser Serie befasst sich mit einem zerstörten Header einer ASM Disk, die Bestandteil einer gemounteten ASM Diskgroup ist.

 

Voraussetzungen

Für das Simulieren von Ausfällen kritischer RAC Komponenten verwende ich einen virtuellen Oracle Real Application Cluster in der Version 11g Release 2 (Version 11.2.0.1). Als Betriebssystem kommt CentOS 5.5 und als Systemarchitektur wurde x86_64 gewählt. Eine Anleitung für die Einrichtung eines RACs findet sich hier

 

In meinem Testsystem wurden drei Diskgroups angelegt, die die folgenden Merkmale aufweisen:

  1. Diskgroup CONFIG, Redundancy NORMAL – Gespiegelte Diskgroup für OCR und Voting Disks (ab 11g Release 2 möglich)
  2. Diskgroup DATA, Redundancy NORMAL – Gespiegelte Diskgroup zur Speicherung der Datendateien der Datenbank
  3. Diskgroup FRA, Redundancy NORMAL – Gespiegelte Diskgroup für die Fast Recovery Area (ehemals Flash Recovery Area)

Für die Simulation wird nur die Diskgroup DATA verwendet.

Die ASM Disks wurden mithilfe von ASMLib gelabelt. Das Mapping sieht wie folgt aus.

[root@rac01 ~]# /etc/init.d/oracleasm querydisk /dev/sd[c-k]1 Device "/dev/sdc1" is marked an ASM disk with the label "CONFIG01" Device "/dev/sdd1" is marked an ASM disk with the label "CONFIG02" Device "/dev/sde1" is marked an ASM disk with the label "CONFIG03" Device "/dev/sdf1" is marked an ASM disk with the label "DATA01" Device "/dev/sdg1" is marked an ASM disk with the label "DATA02" Device "/dev/sdh1" is marked an ASM disk with the label "FRA01" Device "/dev/sdi1" is marked an ASM disk with the label "FRA02" 

Bevor der Ausfall simuliert wird, muss sicher gestellt werden, dass alle notwendigen RAC Ressourcen ordnungsgemäß funktionieren.

[grid@rac01 ~]$ crsctl status res -t -------------------------------------------------------------------------------- NAME           TARGET  STATE        SERVER                   STATE_DETAILS -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.CONFIG.dg                ONLINE  ONLINE       rac01                ONLINE  ONLINE       rac02 ora.DATA.dg                ONLINE  ONLINE       rac01                ONLINE  ONLINE       rac02 ora.FRA.dg                ONLINE  ONLINE       rac01                ONLINE  ONLINE       rac02 ora.LISTENER.lsnr                ONLINE  ONLINE       rac01                ONLINE  ONLINE       rac02 ora.asm                ONLINE  ONLINE       rac01                Started                ONLINE  ONLINE       rac02                Started ora.eons                ONLINE  ONLINE       rac01                ONLINE  ONLINE       rac02 ora.gsd                OFFLINE OFFLINE      rac01                OFFLINE OFFLINE      rac02 ora.net1.network                ONLINE  ONLINE       rac01                ONLINE  ONLINE       rac02 ora.ons                ONLINE  ONLINE       rac01                ONLINE  ONLINE       rac02 -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.LISTENER_SCAN1.lsnr       1        ONLINE  ONLINE       rac01 ora.oc4j       1        OFFLINE OFFLINE ora.rac01.vip       1        ONLINE  ONLINE       rac01 ora.rac02.vip       1        ONLINE  ONLINE       rac02 ora.scan1.vip       1        ONLINE  ONLINE       rac01 ora.test.db       1        ONLINE  ONLINE       rac01                Open       2        ONLINE  ONLINE       rac02                Open

 

Hinweis: Der Befehl crs_stat wurde in 11g Release 2 als deprecated gekennzeichnet, kann aber weiterhin verwendet werden.

 

Wie man sieht laufen alle RAC Ressourcen ordnungsgemäß. Es wurde bereits eine Datenbank mit dem Namen TEST angelegt, die ich für die Veranschaulicherung eines zerstörten ASM Headers verwenden werde.

 

Simulation – Zerstörter ASM Header bei Disk in gespiegelter Diskgroup

In dieser Simulation werde ich den Header von einer der beiden ASM Disks der Diskgroup DATA zerstören. Dafür verwende ich das dd Kommando. Bevor ich den ASM Header zerstöre, lass ich ihn mir mithilfe von kfed (Kernel Files Editor) auslesen. Mithilfe, des von Oracle bereitgestellten Werkzeugs, kfed kann man sich die Headerinformationen einer ASM Disk auslesen. 

[root@rac01 ~]# /u01/app/11.2.0/grid/bin/kfed read /dev/sdg1 kfbh.endian:                          1 ; 0x000: 0x01 kfbh.hard:                          130 ; 0x001: 0x82 kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD kfbh.datfmt:                          1 ; 0x003: 0x01 kfbh.block.blk:                       0 ; 0x004: T=0 NUMB=0x0 kfbh.block.obj:              2147483650 ; 0x008: TYPE=0x8 NUMB=0x2 kfbh.check:                  1541245862 ; 0x00c: 0x5bdd8ba6 kfbh.fcn.base:                     4179 ; 0x010: 0x00001053 kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000 kfbh.spare1:                          0 ; 0x018: 0x00000000 kfbh.spare2:                          0 ; 0x01c: 0x00000000 kfdhdb.driver.provstr:   ORCLDISKDATA02 ; 0x000: length=14 kfdhdb.driver.reserved[0]:   1096040772 ; 0x008: 0x41544144 kfdhdb.driver.reserved[1]:        13104 ; 0x00c: 0x00003330 kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000 kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000 kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000 kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000 kfdhdb.compat:                186646528 ; 0x020: 0x0b200000 kfdhdb.dsknum:                        2 ; 0x024: 0x0002 kfdhdb.grptyp:                        2 ; 0x026: KFDGTP_NORMAL kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname:                  DATA02 ; 0x028: length=6 kfdhdb.grpname:                    DATA ; 0x048: length=4 kfdhdb.fgname:                   DATA02 ; 0x068: length=6 kfdhdb.capname:                         ; 0x088: length=0 kfdhdb.crestmp.hi:             32951179 ; 0x0a8: HOUR=0xb DAYS=0x1c MNTH=0x2 YEAR=0x7db kfdhdb.crestmp.lo:           1711486976 ; 0x0ac: USEC=0x0 MSEC=0xce SECS=0x20 MINS=0x19 kfdhdb.mntstmp.hi:             32951179 ; 0x0b0: HOUR=0xb DAYS=0x1c MNTH=0x2 YEAR=0x7db kfdhdb.mntstmp.lo:           1711770624 ; 0x0b4: USEC=0x0 MSEC=0x1e3 SECS=0x20 MINS=0x19 ...

In dieser Ausgabe erkennt man zum Beispiel, dass die Festplatte /dev/sdg1 zu der Diskgroup DATA (fdhdb.grpname) gehört und mit dem ASM Label ORCLDISKDATA02 (kfdhdb.driver.provstr) gelabelt wurde.

 

Hinweis: Mit Oracle 11g ist kfed ein zentraler Bestandteil geworden. Es muss nicht mehr, wie bei Oracle 10g, zunächst mit make erstellt werden.

 

Alternativ kann man sich den Header der Disk mit od in der ASCII Schreibweise anzeigen lassen.

[root@rac01 ~]# od -c /dev/sdg1 | head -n 10 0000000 001 202 001 001  \0  \0  \0  \0 002  \0  \0 200 246 213 335   [ 0000020   S 020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 0000040   O   R   C   L   D   I   S   K   D   A   T   A   0   2  \0  \0 0000060  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 0000100  \0  \0      \v 002  \0 002 003   D   A   T   A   0   2  \0  \0 0000120  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 0000140  \0  \0  \0  \0  \0  \0  \0  \0   D   A   T   A  \0  \0  \0  \0 0000160  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0 0000200  \0  \0  \0  \0  \0  \0  \0  \0   D   A   T   A   0   2  \0  \0 0000220  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

 

Im nächsten Schritt wird nun der ASM Header übrschrieben. Die Diskgroup ist weiterhin ONLINE und auch die Datenbank ist geöffnet.

[root@rac01 ~]# dd if=/dev/zero of=/dev/sdg1 bs=8k count=1 1+0 Datensätze ein 1+0 Datensätze aus 8192 Bytes (8,2 kB) kopiert, 4,7e-05 Sekunden, 174 MB/s

Was passiert nun mit der Datenbank und der ASM Diskgroup?

Überprüfen wir zunächst den Status der ASM Diskgroup.

[grid@rac01 ~]$ srvctl status diskgroup -g DATA Plattengruppe DATA wird auf rac01,rac02 ausgeführt

Der Status der ASM Diskgroup hat sich nicht verändert. Oracle zeigt auch keine der Disks als OFFLINE an, wie man mithilfe des Kommandozeilenwerkzeuges asmcmd sehen kann.

[grid@rac01 ~]$ asmcmd lsdsk -p -G DATA Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path         3         0  3915922613  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DATA01         3         2  3915922616  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DATA02

Schauen wir uns nun die Datenbank an.

[grid@rac01 ~]$ srvctl status database -d TEST Instanz TEST1 wird auf Knoten rac01 ausgeführt Instanz TEST2 wird auf Knoten rac02 ausgeführt

Die Datenbank scheint noch zu laufen, aber was passiert wenn nun jemand versucht auf die Daten in der Diskgroup zuzugreifen?

[oracle@rac01 ~]$ sqlplus / as sysdba  SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 28 12:37:05 2011  Copyright (c) 1982, 2009, Oracle.  All rights reserved.  Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options  SQL> select name, open_mode from v$database;  NAME      OPEN_MODE --------- -------------------- TEST      READ WRITE  SQL> select count(*) from dba_objects;    COUNT(*) ----------      13079

Wie man sehen kann, läuft die Datenbank ohne Probleme weiter. Auch Abfragen auf das Data Dictionary sind ohne Weiteres möglich.

 

Überprüft man nun wieder mit kfed den ASM Header der Disk, sieht man folgendes.

[root@rac01 ~]# /u01/app/11.2.0/grid/bin/kfed read /dev/sdg1 kfbh.endian:                          0 ; 0x000: 0x00 kfbh.hard:                            0 ; 0x001: 0x00 kfbh.type:                            0 ; 0x002: KFBTYP_INVALID kfbh.datfmt:                          0 ; 0x003: 0x00 kfbh.block.blk:                       0 ; 0x004: T=0 NUMB=0x0 kfbh.block.obj:                       0 ; 0x008: TYPE=0x0 NUMB=0x0 kfbh.check:                           0 ; 0x00c: 0x00000000 kfbh.fcn.base:                        0 ; 0x010: 0x00000000 kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000 kfbh.spare1:                          0 ; 0x018: 0x00000000 kfbh.spare2:                          0 ; 0x01c: 0x00000000 ERROR!!!, failed to get the oracore error message

Das Abrufen des ASM Headers schlägt fehl. Der Wert KFBTYP_INVALID für den Parameter kfbh.type bedeutet, dass es sich bei der Platte um keine ASM Disk handelt oder das der Header defekt ist.

 

Ein zweiter Test wird direkt über die ASM Instanz durchgeführt. Es werden die ASM Disks Informationen über die View v$asm_disk abgerufen. Bei der Verwendung von v$asm_disk wird ein Disk Discovery durchgeführt. Wird dagegen die View v$asm_disk_stat verwendet, ruft Oracle die Disk Informationen aus dem Speicher ab. In diesem Fall muss v$asm_disk verwendet werden!

[grid@rac01 ~]$ sqlplus / as sysasm  SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 28 12:40:23 2011  Copyright (c) 1982, 2009, Oracle.  All rights reserved.  Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Real Application Clusters and Automatic Storage Management options  SQL> select group_number, name from v$asm_diskgroup;  GROUP_NUMBER NAME ------------ ------------------------------            1 CONFIG            2 FRA            3 DATA  SQL> set linesize 250 SQL> col path for a40 SQL> select disk_number, mount_status, header_status, state, name, path from v$asm_disk where group_number=3  DISK_NUMBER MOUNT_S HEADER_STATU STATE    NAME                           PATH ----------- ------- ------------ -------- ------------------------------ ----------------------------------------           0 CACHED  MEMBER       NORMAL   DATA01                         ORCL:DATA01           2 CACHED  CANDIDATE    NORMAL   DATA02                         ORCL:DATA02

Wie man sieht erkennt Oracle die Disk nicht mehr als Member einer Diskgroup (Header Status CANDIDATE).

 

Erneutes Mounten der ASM Diskgroup

In diesem Test wird nun überprüft was passiert, wenn die Diskgroup erneut gemountet wird (zum Beispiel durch einen Neustart des Servers). Ich stoppe zuvor die Datenbank.

[grid@rac01 ~]$ srvctl start database -d TEST

Anschließend remounte ich die ASM Diskgroup DATA.

[root@rac01 ~]# /u01/app/11.2.0/grid/bin/srvctl stop diskgroup -g DATA -n rac01,rac02 -f PRCR-1064 : Ressource ora.DATA.dg konnte auf Knoten rac01 nicht gestartet werden ORA-15032: not all alterations performed ORA-15040: diskgroup is incomplete ORA-15042: ASM disk "2" is missing from group number "3"  CRS-2674: Starten von "ora.DATA.dg" auf "rac01" nicht erfolgreich PRCR-1064 : Ressource ora.DATA.dg konnte auf Knoten rac02 nicht gestartet werden ORA-15032: not all alterations performed ORA-15040: diskgroup is incomplete ORA-15042: ASM disk "2" is missing from group number "3"  CRS-2674: Starten von "ora.DATA.dg" auf "rac02" nicht erfolgreich

Oracle verweigert das Mounten der Diskgroup, da Oracle die ASM Disk mit der Nummer 2 nicht finden kann.

 

Sollte es sich, wie in diesem Fall, um eine durch ASM gespiegelte Diskgroup handeln und sollte nur einer der beiden ASM Header zerstört sein, lässt sich das Mouten der Diskgroup erzwingen.

[grid@rac01 ~]$ sqlplus / as sysasm  SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 28 13:08:50 2011  Copyright (c) 1982, 2009, Oracle.  All rights reserved.   Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Real Application Clusters and Automatic Storage Management options  SQL> alter diskgroup DATA mount force;  Diskgroup altered.

Überprüft man nun die Diskgroup, sieht man, dass Oracle die Platte mit dem intakten Header mounten konnte.

[grid@rac01 ~]$ asmcmd lsdsk -p -G DATA Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path         3         2  3915922621  MISSING     UNKNOWN      OFFLINE    NORMAL         3         0  3915922620  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DATA01

Hinweis: Bei einer nicht gespiegelten Platte muss der ASM Header wiederhergestellt werden. Hierfür sollte der Oracle Support zur Hilfe gezogen werden.

 

Wiederherstellen des ASM Spiegels

Möchte man nun den ASM Spiegel wiederherstellen, sollte man sich zunächst eine neue LUN von Administrator geben lassen. Ich empfehle die alte zerstörte ASM Disk nicht mehr zu verwenden.

 

Ich verwende dafür die neue Disk /dev/sdj1.

[root@rac01 ~]# /etc/init.d/oracleasm querydisk /dev/sdj1 Device "/dev/sdgj" is marked an ASM disk with the label "DATA03"

Nachdem die Disk formatiert und mit einem ASM Label (nur bei Verwendung von ASMLib) gelabelt wurde, kann die neue Disk der Diskgroup DATA hinzugefügt werden.

[grid@rac01 ~]$ sqlplus / as sysasm  SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 28 13:15:16 2011  Copyright (c) 1982, 2009, Oracle.  All rights reserved.  Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Real Application Clusters and Automatic Storage Management options  SQL> alter diskgroup DATA add disk 'ORCL:DATA03';  Diskgroup altered. 

Oracle stellt nun den Spiegel wieder her. Dieser Vorgang wird Rebalance genannt.

[grid@rac01 ~]$ asmcmd lsop Group_Name  Dsk_Num  State  Power DATA        REBAL    RUN    1

Oracle entfernt die alte, defekte Disk erst nach erfolgreichen Abschluss des Rebalance aus der Diskgroup.

[grid@rac01 ~]$ asmcmd lsdsk -p -G DATA Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State    Path         3         2  3915922621  MISSING     UNKNOWN      OFFLINE    FORCING         3         0  3915922620  CACHED      MEMBER       ONLINE     NORMAL   ORCL:DATA01         3         1  3915922623  CACHED      MEMBER       ONLINE     NORMAL   ORCL:DATA03

Nach Abschluss des Rebalance ist der ASM Spiegel wieder korrekt hergestellt. Die alte ASM Disk wurde endgültig entfernt.

[grid@rac01 ~]$ asmcmd lsdsk -p -G DATA Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path         3         0  3915922620  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DATA01         3         1  3915922623  CACHED      MEMBER       ONLINE     NORMAL  ORCL:DATA03

 

Fazit

Ein zerstörter ASM Header hat zunächst keinen Einfluss auf den Betrieb der ASM Diskgroup oder möglicher Datenbanken, die auf diese Diskgroup zugreifem. Erst der Versuch eines erneuten Mounts der Diskgroup schlägt fehl.

 

Die Headerinformationen sind für Oracle nur während des Startens der ASM Instanz bzw. des Mounten der ASM Diskgroups von Relevanz.

 

Ich persönlich empfehle das Spiegeln der Diskgroups mithilfe von ASM. Dadurch ist man gegen zerstörte Header besser geschützt.  

Leave a Reply

Your email address will not be published. Required fields are marked *