Benutzer-Werkzeuge

Webseiten-Werkzeuge


Action disabled: index
dba:asm_platten_verteilen

Oracle 12c - Oracle ASM Disk Groups über zwei Storages verteilen - Ein Oracle Cluster für zwei Brandabschnitte aufsetzen

min. ab Oracle 11g gut möglich

09.2016

Aufgabe: In einem Oracle Cluster halten zwei Storage System die Daten der ASM Disk Gruppen redundant vor. Fällt ein Storage aus, läuft die Datenbank Umgebung problemlos weiter.

Tip:

  • Auf HIGH Redundancy verzichten - nur normal mit zwei Failgroups einsetzen!
  • Bei der Anlage des Cluster ASM Diskgruppe zu Beginn Diskgroup MNGMT nennen, gleich 3*20GB Platten einplanen - hier verbleibt dann nur die MNGMT DB und ASM SPFile/ASM PWD File - Das normal Redundancy wird am Ende dann wieder eine Platte gelöscht so das zwei Failgroups verbleiben
  • Disk Gruppe VOTPROD anlegen und dort später die VOT Files ablegen (mit NFS als Dritter Location je eine Disk pro Storage!)
  • Für Wartungsarbeiten je eine VOTSPARES1 und VOTSPARES2 mit Platten nur in je einem Storage einplannen (normal Redundancy mit 3 Failgroups) und bereits vorbereiten, das hilft bei Wartungsaufgaben und Recovery Fragestellungen
  • OCR zusätzlich auf zwei weitere Platten nach der Installation spiegeln, wie RedoA und RedoB
  • Repair Timer auf den Disk Gruppen großzügig setzen > 24h!
Übersicht

 Oracle ASM über verteilte Storages

Zwei Storage Systeme werden kreuzweise an die Oracle Real Application Cluster Knoten per FC angeschlossen.

Die Luns in den Storages sind paarweise immer gleich groß und haben die gleichen Namen. Diese Luns werden als ASM Disks auf jedem Server paarweise eingerichtet

Damit das übersichtlich bleibt, heißt die ASM Platte gleich wie die Lun im Storage, aus DATA01 wird dann ein DATA01_S1 für die Datenplatte von Storage 1 und DATA01_S2 für die Datenplatte vom Storage 2.

Danach wird eine ASM „Disk Group“ mit „Normal Redundancy“ und zwei expliziten Fail Groups (eine für das Storage 1 und eine für das Storage 2) angelegt.

Die Platten werden intern von Oracle ASM synchronisiert, die Daten werden also doppelt vorgehalten.

Für die normalen Datenbank Platten ist das keine Problem und funktioniert mit Normal Redundancy wie gewünscht.

Die OCR Files lassen sich über mehrere ASM Disk Gruppen spiegeln, wie VOT und noch zusätlich REDOA und REDOB.

Allerdings funktioniert die für die VOT Files so einfach nicht!

Hier benötigen wir noch einen dritten Speicherort der völlig unabhängig von den beiden Storages ist!

Oracle bietet hier die Möglichkeit an ein NFS an einer weiteren, zuverlässigen Stelle zu verwenden.

Alle Tests es auch anders zu implementieren sind mir bisher alle fürchterlich misslungen :-( . Ich hätte nicht erwartet das es auch in 12c nicht anders als mit einem dritten Storage zu implementieren ist.

D.h. nur mit einer solchen Implementierung lässt sich das am Schluss umsetzen:

 VOT Disk Verteilung über 3 Storage Systeme

Für die Umsetzung mit einem NFS Share siehe hier ⇒ NFS für einen VOT File einem 12c Oracle Real Applikation Clusters unter Linux 7 verwenden .


ASM Grundlagen und Begriffe

VOT - Oracle Clusterware voting disks
  • Platten für den Cluster Status, dient der Split Brain Vermeidung im Cluster, bei dem nicht mehr klar ist wer was gleichzeitig beschreiben darf
  • Werden für die Synchronisation im Cluster über den Storage Pfad verwendet
  • Kann nach x sekunden nicht die Location gelesen werden und stehen nicht genügend zur Auswahl wird das Cluster beendet!
OCR- Oracle Cluster Registry files
  • Enthalten die Konfiguration des Clusters
  • Können auf einer ASM Platte oder einen Cluster Filesystem liegen
  • Die Platte/das Storage muss von allen Knoten erreicht werden

Jeder Knoten der nicht auf die absolute Mehrheit der VOT und OCR Disks zugreifen kann (absolute majority of voting disks (more than half)) wird heruntergefahren und neu gestartet.

"Redundancy (mirroring)" Optionen

ASM unterstützt 3 Typen „redundancy (mirroring)“ Optionen:

  • High Redundancy - for each primary extent, there are two mirrored extents
  • Normal Redundancy - for each primary extent, there is one mirrored (secondary) extent
  • External Redundancy - only primary extents and no mirrored extents

Für unsere Umgebung werden daher die Disk Gruppen mit „Normal Redundancy“ und je einer „Failgroup“ je Storage angelegt.

Siehe auch ⇒ 12c - Administering Oracle ASM Disk Groups

REPAIR_TIMER

Die REPAIR_TIMER Spalte von V$ASM_DISK zeigt die Zeit an, bis eine Disk im Offline Status gedroppt wird.

Der Wert kann zum Beispiel mit „ALTER DISKGROUP ACFS SET ATTRIBUTE 'disk_repair_time'='24h'“ gesetzt werden.

Default erhöhen: disk_repair_time ⇒ 36h failgroup_repair_time ⇒ 72h

--abfragen:
select g.name  as group_name
     , a.name
     , a.value
	 , a.SYSTEM_CREATED
  from V$ASM_ATTRIBUTE a
      inner join  v$asm_diskgroup g on (g.group_number=a.group_number)
where g.name like upper ('&&DG_NAME') 
  and a.name like lower ('%repair%') 
order by a.name
       , g.name
/
 
--setzen:
 
ALTER DISKGROUP DATA01     SET ATTRIBUTE 'disk_repair_time'='36h';
ALTER DISKGROUP DATA01     SET ATTRIBUTE 'failgroup_repair_time'='72h';
CSS Timeout Computation

siehe CSS Timeout Computation in Oracle Clusterware (Doc ID 294430.1)

The synchronization services component (CSS) of the Oracle Clusterware maintains two heartbeat mechanisms

  1. the disk heartbeat to the voting device and
  2. the network heartbeat across the interconnect which establish and confirm valid node membership in the cluster

Both of these heartbeat mechanisms have an associated timeout value.

  • network heartbeat - seit 11g ⇒ 30 sec für alle Plattformen

The disk heartbeat has an internal i/o timeout interval (DTO Disk TimeOut), in seconds, where an i/o to the voting disk must complete. The misscount parameter (MC), as stated above, is the maximum time, in seconds, that a network heartbeat can be missed. The disk heartbeat i/o timeout interval is directly related to the misscount parameter setting.

VOT DISK auf ASM Disk Group

VOT Files auf einer ASM Gruppe liegen in einem gesonderten Bereich der Platte damit die Datei auch gelesen werden kann wenn das ASM offline ist.

/opt/12.1.0.2/grid/bin/kfed read /dev/oracleasm/disks/VOT4_02 | grep -E 'vfstart|vfend'
kfdhdb.vfstart:                      64 ; 0x0ec: 0x00000040
kfdhdb.vfend:                        96 ; 0x0f0: 0x00000060
* High Redundancy    => 5 Fail Groups notwendig
* Normal Redundancy  => 3 Fail Groups notwendig

Aus jeder Fail Group wird zufällig eine Disk herausgenommen und als Speicherort für eine VOT Datei bestimmt.

  • External Redundancy ⇒ Nur ein VOT File wird angelegt
  • High Redundancy ⇒ Es müssen min 3 VOT Files „überleben“, damit das Cluster sich nicht herunter fährt.
  • Normal Redundancy ⇒ Es müssen min 2 VOT Files „überleben“, damit das Cluster sich nicht herunter fährt.

Das führt zu dem Problem, das bei zwei Storages es sich nicht so verteilen lässt, das wirklich in jeden Fall 2 bzw 3 VOT Files einen Ausfall von einem der beiden Storages für den Betrieb des Clusters überleben, da nur 3 VOT für Normal und 5 VOT's für High angelegt werden können.

Lösung: 3 Storages ⇒ http://www.oracle.com/technetwork/database/clusterware/overview/grid-infra-thirdvoteonnfs-131158.pdf

Siehe dazu ⇒ https://docs.oracle.com/database/121/CWADD/votocr.htm#CWADD833

OCR Disks auf mehren ASM Disk Gruppen spiegeln

Damit auch beim Ausfall einer ASM Gruppe noch genügend OCR Disks verbleiben, diese auf mehrere Locations aufteilen!

export GRID_HOME=/opt/12.1.0.2/grid
 
# Hinzufügen
$GRID_HOME/bin/ocrconfig -add +REDOA
$GRID_HOME/bin/ocrconfig -add +REDOB
 
# Testen
$GRID_HOME/bin/ocrcheck

Eine iSCSI Trainingsumgebung zum Üben aufsetzen

Um die Wartungsarbeiten bzgl. Failover und Verlust eines Storages zu üben, wird nun eine bestehende iSCSI Umgebung so angepasst, das nun zwei Storages zum Üben zur Verfügung stehen ⇒ Siehe dazu auch Anmerkungen zu Installation des Oracle Real Application Cluster 12c R1 auf einem Oracle Linux 7 für die anfängliche Installation mit nur einem Storage.

Unser iSCSI Storage 1 ist zuvor bereits aufgesetzt worden ⇒ Siehe iSCSI Target für das Bereitstellen von Cluster Platten in VMWare unter Linux 7, aus diesem Storage wird das zweite Storage erzeugt.

iSCSI Storage 1 clonen

Über VMware Storage 1 klonen.

  • Neue IP Adresse und neuen Namen (storage02.pipperr.local) vergeben
  • Nun noch alles noch umbenennen, beim ersten Test stellt sich heraus, das sonst nicht mehr sauber zwischen dem System unterschieden werden kann, das wird unhandlich:
    #Volumen umbennen
     vgrename  /dev/racstore01 /dev/racstore02
     
    #LVM logical volume umbenennen
    lvrename racstore02 acfs01   acfs01_02
    lvrename racstore02 data01   data01_02 
    lvrename racstore02 data02   data02_02 
    lvrename racstore02 data03   data03_02 
    lvrename racstore02 redoa01  redoa01_02
    lvrename racstore02 redob01  redob01_02
    lvrename racstore02 vota01   vota01_02 
    lvrename racstore02 votb01   votb01_02 
    lvrename racstore02 votc01   votc01_02 
  • ISCSI iqn anpassen und Pool Name anpassen:
     vi /etc/target/targetd.yaml 
     
    pool_name: racstore02
    ..
    target_name: iqn.2016-09.pipperr.local:server
     
    # Client Settings anpassen um später zu testen
    cd /etc/iscsi/
    vi initiatorname.iscsi
    InitiatorName=iqn.2016-09.pipperr.local:client
  • mit Targetcli Konfiguration löschen und neu anlegen
    targetcli
     
    cd /
    cd /iscsi
     
    delete iqn.2015-03.pipperr.local:server 
    create iqn.2016-09.pipperr.local:server
     
    #acls wieder hinterlegen
    cd /iscsi/iqn.2016-09.pipperr.local:server/tpg1/acls
     
    create iqn.2015-03.pipperr.local:client
    create iqn.2016-09.pipperr.local:client
     
    create iqn.2015-03.pipperr.local:racdb01
    create iqn.2015-03.pipperr.local:racdb02
     
    #luns prüfen und evtl alte luns lösche
    cd /iscsi/iqn.2016-09.pipperr.local:server/tpg1/luns
     
    ls
    #löschen bei Bedarf
    delete lun0
    # usw. bis all weg sind
     
    cd /backstores/block
     
    #Block Devices löschen und dann neu anlegen
     
    ls
    delete rac01-acfs01
    # usw. bis alle gelöscht sind
     
    # neu anlegen
    create  rac02-vota01  /dev/racstore02/vota01_02
    create  rac02-acfs01  /dev/racstore02/acfs01_02  
    create  rac02-data01  /dev/racstore02/data01_02 
    create  rac02-data02  /dev/racstore02/data02_02 
    create  rac02-data03  /dev/racstore02/data03_02 
    create  rac02-redoa01 /dev/racstore02/redoa01_02
    create  rac02-redob01 /dev/racstore02/redob01_02
    create  rac02-votb01  /dev/racstore02/votb01_02 
    create  rac02-votc01  /dev/racstore02/votc01_02 
    create  rac02-votd01 /dev/racstore02/votd01_02
     
    #Luns anlegen
    cd /iscsi/iqn.2016-09.pipperr.local:server/tpg1/luns
     
    create /backstores/block/rac02-acfs01 
    create /backstores/block/rac02-data01 
    create /backstores/block/rac02-data02 
    create /backstores/block/rac02-data03 
    create /backstores/block/rac02-redoa01
    create /backstores/block/rac02-redob01
    create /backstores/block/rac02-vota01 
    create /backstores/block/rac02-votb01 
    create /backstores/block/rac02-votc01 
    create /backstores/block/rac02-votd01 
     
    #Portal anlegen bzw prüfen
     
    cd /iscsi/iqn.2016-09.pipperr.local:server/tpg1/portals
     
    ls
    # alternativ mit create neu anlegen
     
    #Config sichern
    cd /
     
    saveconfig
    exit
     
    #testen
    iscsiadm -m discovery -t sendtargets -p storage02
    10.10.10.182:3260,1 iqn.2016-09.pipperr.local:server
     
    iscsiadm --mode node --targetname iqn.2016-09.pipperr.local:server --portal storage02 --login
     
    #alle Block Devices anzeigen lassen, die neuen Platten sollten am Ende angezeigt werden
    lsblk --scsi
  • Platten neu partioniern, sollen ja als neue Platten erkannt werden! Alles in einem rutsch mit einem Script:
    #!/bin/sh
     
    disks="/dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg  /dev/sdh /dev/sdi  /dev/sdj /dev/sdk"
     
    #Header der Platten überschreiben um den ASM Stempel loszuwerden
    for i in $disks;do
    dd if=/dev/zero of=$i bs=1M count=10 ;done
     
     
    # mit n neu anlegen, p primary, 1, von start bis ende,
    # mit p testen 
    # mit w zum Schluss schreiben.
     
    for i in $disks;do
    echo "p
    n
    p
    1
     
     
    p
    w
    "|fdisk $i ;done
  • Reboot und testen ob alles noch wie gewünscht noch funktioniert

Neues Storage an die bestehenden RAC Cluster Knoten anbinden

Im nächsten Schritt muss das neue Storage 2 nun an die beiden DB Knoten angebunden werden.

  • IP Adresse neues Storage hinterlegen (DNS oder in der Host Datei)
    vi  /etc/hosts
    10.10.10.182 storage02.pipperr.local storage02
  • Testen
    # netz testen 
    ping storage02
     
    # Was stellt der Server zur Verfügung
    iscsiadm -m discovery -t sendtargets -p storage02
     
    10.10.10.182:3260,1 iqn.2016-09.pipperr.local:server
     
    #Anmelden
     
    iscsiadm -m node --login
     
    #platten
     
    lsblk --scsi
    blkid
     
    #abmelden
    iscsiadm -m node -T  iqn.2016-09.pipperr.local:server -u
  • Klappt alles, automatisch anmelden setzen
    iscsiadm -m node -T iqn.2016-09.pipperr.local:server -p storage02 --op update -n node.startup -v automatic
  • booten und testen ob die Platten automatisch dann da sind
     lsblk --scsi 

    Auf die führenden Nummer der Luns achten um die Storage System unterscheiden zu können

  • Auf dem zweiten Knoten ebenfalls wie oben die iSCSI Verbindung initialisieren und neu starten

Nun die neuen ASM Disk als Kandidaten für die neuen ASM Disk Gruppen zur Verfügung stellen.

  • Platten anzeigen lassen
      lsblk -o TYPE,MAJ:MIN,WWN,HCTL,NAME,SIZE | grep disk
    ..
    disk   8:208    0x600140553b6ccac8 4:0:0:6    sdn                 6G
    disk   8:224    0x600140548f39f107 3:0:0:6    sdo                 6G
    ..
     
    #Fehlt eine Platte neu scannen lassen
    iscsiadm -m session --rescan

    Die Herausforderung ist hierbei jedes Mal über die WWN (FC Storage) oder die HCTL (Host:Channel:Target:Lun for SCSI) die richtige Platte vom Storage wieder zu erkennen! In meinen Fall kommen die Platten vom neuen Storage über die HCTL 4:0:0:x ! Daher sehr genau prüfen ob alles stimmt und dann mit „ .. | grep 4:0“ an den obigen Befehlt nur die neuen Platten anzeigen lassen, dann wird es einfacher zu erkennen, welche Platte wie initialisiert werden muss!

  • Auf dem Storage 02 nun prüfen, mit welcher Lun Nr. welche Platte angelegt wurde!
    targetcli
    cd /iscsi/iqn.2016-09.pipperr.local:server/tpg1/luns
    ls
    ..
     o- lun8 ................. [block/rac02-votc01 (/dev/racstore02/votc01_02)]
    ..

    Die Platte rac02-votc01 soll als ASM Disk VOT3_02 angelegt werden, d.h. wir müssen die Lun 8 auf dem RAC Server suchen.

  • Disk suchen und die ASM Disks anlegen:
    lsblk -o TYPE,MAJ:MIN,WWN,HCTL,NAME,SIZE | grep disk | grep 4:0:0:8
     
    disk  65:16     0x6001405d04d48a10 4:0:0:8    sdr                 6G
     
    # D.h die ASM Platte kann nun in der 1 Partition von sdr initialisiert werden
     
    oracleasm createdisk VOT3_02 /dev/sdr1 
     
    oracleasm scandisks
    oracleasm listdisks
     
    blkid | grep oracle | sort
    ..
    /dev/sds1: LABEL="VOT3" TYPE="oracleasm"
    /dev/sdr1: LABEL="VOT3_02" TYPE="oracleasm"
    ..

    Nun alle anderen Platten nach diesem Muster anlegen, Tipp: Auf dem Storage mit „blkid“ prüfen, ob alle Platten wie gewünscht gestempelt wurden!

  • Alle weiteren Platten zuordnen und die Platten auch vom zweiten RAC Knoten auslesen lassen mit „oracleasm scandisks“!

Nun haben wir von zwei Storage Platten an unserem System.

Im nächsten Schritt werden die ASM Diskgruppen mit je eine Failgroup auf jedem Storage angelegt.



Test der verschieden Möglichkeiten für eine VOT Diskgroup

Test VOT Platte mit HIGH REDUNDANCY

Lösung mit 5 Platten in einer eigenen VOT Gruppe nur für diesen Dateityp.

Jede Platte ist in einen eigenen failgroup, damit ist auch immer zwingend eine VOT Datei auf jeder Disk.

CREATE diskgroup VOTPROD HIGH REDUNDANCY
      failgroup storage11  disk '/dev/oracleasm/disks/VOT3'    name VOT3S1 SIZE  6143M
      failgroup storage12  disk '/dev/oracleasm/disks/VOT4'    name VOT4S1 SIZE  6143M
	  failgroup storage21  disk '/dev/oracleasm/disks/VOT2_02' name VOT2S2 SIZE  6143M
	  failgroup storage22  disk '/dev/oracleasm/disks/VOT3_02' name VOT3S2 SIZE  6143M
	  failgroup storage23  disk '/dev/oracleasm/disks/VOT4_02' name VOT4S2 SIZE  6143M;
 
ALTER DISKGROUP VOTPROD SET ATTRIBUTE 'compatible.asm'='11.2.0.0.0';
ALTER DISKGROUP VOTPROD SET ATTRIBUTE 'compatible.rdbms'='11.2.0.0.0';	  
 
 
#auf zweiten knoten mounten
SYS@+ASM2-racdb02>ALTER diskgroup VOTPROD mount;

umziehen

export GRID_HOME=/opt/12.1.0.2/grid
 
$GRID_HOME/bin/crsctl query css votedisk
 
$GRID_HOME/bin/crsctl replace votedisk +VOTPROD
 
$GRID_HOME/bin/crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   9d5983cef12a4f36bff3ee52e547b91b (/dev/oracleasm/disks/VOT3) [VOTPROD]
 2. ONLINE   544ced55760f4f0cbfb8116e67a57e26 (/dev/oracleasm/disks/VOT4) [VOTPROD]
 3. ONLINE   2a0d98e828ed4fb1bfe64e94ddbfc893 (/dev/oracleasm/disks/VOT2_02) [VOTPROD]
 4. ONLINE   9fdeda9bdf354f0dbf3ac2c5c630b008 (/dev/oracleasm/disks/VOT3_02) [VOTPROD]
 5. ONLINE   1b82855066864f67bfc02cc7a8157ef4 (/dev/oracleasm/disks/VOT4_02) [VOTPROD]
 

⇒ Nun haben wir definitiv immer wenigstes noch 2 vom Storage 1 übrig

⇒ Storage 2 wird jetzt gestoppt

⇒ Logmeldung

2016-09-05 23:30:39.064000 +02:00
2016-09-05 23:30:39.064 [OCSSD(3111)]CRS-1615: No I/O has completed after 50% of the maximum interval. Voting file /dev/oracleasm/disks/VOT2_02 will be considered not functional in 99810 milliseconds
2016-09-05 23:30:39.064 [OCSSD(3111)]CRS-1615: No I/O has completed after 50% of the maximum interval. Voting file /dev/oracleasm/disks/VOT3_02 will be considered not functional in 99810 milliseconds
2016-09-05 23:30:39.064 [OCSSD(3111)]CRS-1615: No I/O has completed after 50% of the maximum interval. Voting file /dev/oracleasm/disks/VOT4_02 will be considered not functional in 99840 milliseconds
 
 
2016-09-05 23:31:45.126 [OCSSD(3111)]CRS-1649: An I/O error occurred for voting file: /dev/oracleasm/disks/VOT4_02; details at (:CSSNM00060:) in /opt/oracle/diag/crs/racdb01/crs/trace/ocssd.trc.
2016-09-05 23:31:45.126 [OCSSD(3111)]CRS-1649: An I/O error occurred for voting file: /dev/oracleasm/disks/VOT2_02; details at (:CSSNM00060:) in /opt/oracle/diag/crs/racdb01/crs/trace/ocssd.trc.
2016-09-05 23:31:45.128 [OCSSD(3111)]CRS-1649: An I/O error occurred for voting file: /dev/oracleasm/disks/VOT3_02; details at (:CSSNM00060:) in /opt/oracle/diag/crs/racdb01/crs/trace/ocssd.trc.
 
 
2016-09-05 23:32:18.947 [OCSSD(3111)]CRS-1606: The number of voting files available, 2, is less than the minimum number of voting files required, 3, resulting in CSSD termination to ensure data integrity; details at (:CSSNM00018:) in /opt/oracle/diag/crs/racdb01/crs/trace/ocssd.trc
2

Für HIGH REDUNDANCY müssen aber 3 erhalten bleiben ⇒ es funktioniert nicht!

Storage wieder hochfahren neu einlesen ( in einer Umgebung auf jeden Knoten ein iscsiadm -m session –rescan und ein oracleasm scandisks)

auf beiden Knoten ASM wieder starten
 
$GRID_HOME/bin/crsctl start resource ora.asm -init
 $GRID_HOME/bin/crsctl check cluster -all
 
 
 
 
 $GRID_HOME/bin/crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   9d5983cef12a4f36bff3ee52e547b91b (/dev/oracleasm/disks/VOT3) [VOTPROD]
 2. ONLINE   544ced55760f4f0cbfb8116e67a57e26 (/dev/oracleasm/disks/VOT4) [VOTPROD]
 3. ONLINE   2a0d98e828ed4fb1bfe64e94ddbfc893 (/dev/oracleasm/disks/VOT2_02) [VOTPROD]
 4. ONLINE   9fdeda9bdf354f0dbf3ac2c5c630b008 (/dev/oracleasm/disks/VOT3_02) [VOTPROD]
 5. ONLINE   1b82855066864f67bfc02cc7a8157ef4 (/dev/oracleasm/disks/VOT4_02) [VOTPROD]
 
 
alter diskgroup VOT  online disks in failgroup STORAGE2;
alter diskgroup ACFS  online disks in failgroup STORAGE2;
alter diskgroup DATA  online disks in failgroup STORAGE2;
alter diskgroup FRA  online disks in failgroup STORAGE2;
alter diskgroup REDOA  online disks in failgroup STORAGE2;
alter diskgroup REDOB  online disks in failgroup STORAGE2;

und schon geht wieder alles aber eben nicht so will es soll ….

Test VOT Platte mit NORMAL REDUNDANCY

Wie ist die Konfiguration:

[root@racdb01 ~]# /opt/12.1.0.2/grid/bin/crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   a73001af24b84fc0bf449a17e90fdefd (/dev/oracleasm/disks/VOT2) [VOT]
 2. ONLINE   745283cfbbef4fc3bfdc79d57242c988 (/dev/oracleasm/disks/VOT1_02) [VOT]
 3. ONLINE   6596d688af854f9dbf52bcd735c24bd0 (/dev/oracleasm/disks/VOT1) [VOT]
 
 
 
 
ASM Failgroups of a Diskgroup NORMAL Redundancy:
 
Group                Failgroup                      Disk                 Disk
name                 name                           name                 path                           MODE_STATUS
-------------------- ------------------------------ -------------------- ------------------------------ ---------------------
VOT                  STORAGE1                       VOTA2S1              /dev/oracleasm/disks/VOT4      ONLINE
VOT                  STORAGE1                       VOTAS1               /dev/oracleasm/disks/VOT1      ONLINE
VOT                  STORAGE11                      VOTB2S1              /dev/oracleasm/disks/VOT3      ONLINE
VOT                  STORAGE11                      VOTBS1               /dev/oracleasm/disks/VOT2      ONLINE
VOT                  STORAGE2                       VOTA3S2              /dev/oracleasm/disks/VOT3_02   ONLINE
VOT                  STORAGE2                       VOTAS2               /dev/oracleasm/disks/VOT1_02   ONLINE
  • ⇒> Aus jeder Failgroup ist nun eine Lun Verfügbar
  • ⇒> Die Luns sind paarweise je von einem Storage, vom Storage 2 aber nur zwei
  • ⇒> Auf Storage 1 liegen 2 VOT auf dem 2 Storage nur eine VOT Datei

⇒ Storage 2 fällt nun aus ⇒ 4 Platten bleiben dann ja für die VOT Files übrig

⇒ Platten abfragen, Fehler wird erkannt:

 
2016-09-05 21:42:08.315 [OCSSD(3111)]CRS-1615: No I/O has completed after 50% of the maximum interval. Voting file /dev/oracleasm/disks/VOT1_02 will be considered not functional in 99070 milliseconds
....
2016-09-05 21:42:38.996 [OCSSD(3111)]CRS-1649: An I/O error occurred for voting file: /dev/oracleasm/disks/VOT1_02; details at (:CSSNM00060:) in /opt/oracle/diag/crs/racdb01/crs/trace/ocssd.trc.
..
 
2016-09-05 21:42:40.122 [OCSSD(3111)]CRS-1672: The number of voting files currently available 2 has fallen to the minimum number of voting files required 2.

Abfragen:

/opt/12.1.0.2/grid/bin/crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   a73001af24b84fc0bf449a17e90fdefd (/dev/oracleasm/disks/VOT2) [VOT]
 2. ONLINE   6596d688af854f9dbf52bcd735c24bd0 (/dev/oracleasm/disks/VOT1) [VOT]
Located 2 voting disk(s).

Cluster Umgebung ist aber noch oben!

VOT File werden nicht neu erkannt!

Storage 2 wieder starten

alle Gruppen wieder mit „alter diskgroup VOT online disks in failgroup STORAGE2;“ online genommen

/opt/12.1.0.2/grid/bin/crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   a73001af24b84fc0bf449a17e90fdefd (/dev/oracleasm/disks/VOT2) [VOT]
 2. ONLINE   6596d688af854f9dbf52bcd735c24bd0 (/dev/oracleasm/disks/VOT1) [VOT]
 3. ONLINE   014991499b0a4f1abf85adb567bd3818 (/dev/oracleasm/disks/VOT1_02) [VOT]

⇒ Geht

⇒ Fällt nun aber Storage 1 aus würde es nicht mehr gehen, es bleibt nicht genug übrig.

Lösung

⇒ Wir brauchen dann ein drittes Storage, das eben nicht mit dem einen Storage zusammen ausfallen kann. Das kann auch ein NFS Mount sein, der daneben steht! ⇒ siehe NFS für einen VOT File einem 12c Oracle Real Applikation Clusters unter Linux 7 verwenden


Anlegen ASM Disk Gruppe mit Fail Group

Neue ASM Disk Group mit Fail Group anlegen

Voraussetzung:

Platten auf den Servern registrieren und mit „oracleasm“ stampen, auf beide Seiten erkennen lassen (oracleasm scandisks).

Hier ist eine gute Namenskonvention hilfreich wie <Disk_name_nr>_S<Storage Nr> oder ähnlich um hier keine Fehler zu erzeugen.

Sind die Candidate Disks auf beiden Server verfügbar, die Diskgroup mit den zwei Failgroups über die Storages anlegen.

Am Knoten 1 anmelden als sysasm:

#als USER grid mit gesetzter ASM Umgebung
 
sqlplus / AS sysasm
 
CREATE diskgroup DBFAST NORMAL REDUNDANCY
      failgroup storage1 disk '/dev/oracleasm/disks/DATA03_S1' 
      failgroup storage2 disk '/dev/oracleasm/disks/DATA03_S2';

Am knoten 2 anmelden als sysasm:

sqlplus / AS sysasm
 
ALTER diskgroup DBFAST mount;

Bestehende ASM Diskgroup umstellen

Die Fragestellung lautet, kann eine mit „External Redundancy“ angelegte „Disk Group“ so einfach in eine „Normal Redundancy“ „Disk Group“ mit zwei „failgroup“s umgestellt werden?

So wie es aussieht nicht so ohne weiteres …, aus der Doku „You cannot change the redundancy level after the disk group has been created.“ 12c- Database SQL Language Reference- CREATE DISKGROUP

⇒ Wir müssen die Daten der bestehenden Disk Group sichern, diese Disk Group dann löschen und dann neu anlegen, Daten wieder aufspielen

VOT Disk umziehen

Da die VOT Disk ja schon im Normal Mode ist, können wir hier einfach die neuen Platten des zweiten Storage hinzufügen.

SELECT g.name  AS GROUP_NAME
     , d.FAILGROUP
     , d.name AS DISK_NAME
	 , d.path
 FROM v$asm_disk d 
      INNER JOIN  v$asm_diskgroup g ON (g.group_number=d.group_number)
WHERE g.name LIKE UPPER ('VOT')
/
 
GROUP                Failgroup                      Disk                 Disk
name                 name                           name                 path
-------------------- ------------------------------ -------------------- ------------------------------
VOT                  VOT_0002                       VOT_0002             /dev/oracleasm/disks/VOT3
VOT                  VOT_0001                       VOT_0001             /dev/oracleasm/disks/VOT2
VOT                  VOT_0000                       VOT_0000             /dev/oracleasm/disks/VOT1
 
# jeweils eine neue Platte aus dem zweiten Storage jeder Failgroup hinzufügen
# Größe angegeben, da die Platten alle gleich große ein müssen, die neuen aber etwas größer waren
# um den ORA-15410: Disks IN disk GROUP VOT do NOT have equal SIZE. zu vermeiden/umgehen!
 
ALTER diskgroup VOT ADD
  failgroup VOT_0003 disk  '/dev/oracleasm/disks/VOT1_02'  SIZE 6143M
  failgroup VOT_0004 disk  '/dev/oracleasm/disks/VOT2_02'  SIZE 6143M
  failgroup VOT_0005 disk  '/dev/oracleasm/disks/VOT3_02'  SIZE 6143M;
 
# bei späteren Tests hat sich herausgestellt, das nun leider nur die immer die ersten Platten mit dem VOT File belegt werden
# Bei Neuanlage eines Clusters daher hier besser HIGH redundancy wählen!
# IN Folge daher VOT wieder umgezogen und dann Platten rein und raus um die Reihenfolge zu ändern und wieder VOT files auf die Diskgroup gelegt, dann sind die Vot Files besser über die Storages verteilt.

Als root prüfen ob die VOT Files auch wirklich verteilt sind:

/opt/12.1.0.2/grid/bin/crsctl query css votedisk
 
#es werden nur die drei alten Platten angezeigt ...

Hier besser neu das Cluster starten und prüfen ob nach dem Boot mehr VOT files angezeigt werden! Nach dem boot sieht es nicht besser aus, die Platten im neuen Storage werden nicht genützt ….!

Schlecht, VOT in eine der neu umgebauten Luns umgezogen, hier verteilt sich das besser….

Nun zwei Platte aus dem ersten Storage von der VOT entfernt um zu testen ob es an der Reihenfolge liegt, nun wieder VOT hin und her umgezogen, jetzt sind VOT Files über beide Storages verteilt.

Nicht ideal … ⇒ Bei Neuanlage eines Clusters HIGH Redundency für die VOT Gruppe wählen, dann werden 5 VOT Files über diese Platten verteilt (So ist es jedenfalls in der Produktion).

Leider ist hier noch ein zu lösendes Problem, evtl.. benötigen wir doch noch eine Platte mehr als gedacht, nur 2 der 6 Disks lassen sich offline nehmen, damit fällt VOT komplett aus, wenn ein Storage fehlt!

Schlecht, ohne 3 Storage Location bisher keine zufriedenstellende Lösung gefunden!

⇒ NFS für 3 Storage Location verwenden

Alternativ - Auf ganz neue Platten um ziehen um auf "HIGH Redundancy Disk Group" umzuschalten

Nachteil: In einer „HIGH Redundancy Disk Group“ müssen mindestens 3 VOT Files überleben! In einer „Normal Redundancy Disk Group“ nur zwei!

Das Problem in der 12c ist nun, dass auf den VOT Disks auch die neuen Management DB liegt, diese muss zuvor auf einen anderen Bereich umgezogen werden, um die Platten leer zu bekommen.

siehe dazu auch ⇒ Oracle Clusterware 12c - Grid Infrastructure Management Repository (GIMR) .

Die GIMR kann gelöscht und neu erzeugt werden.

#rüfen welche Dateien auf diese Platte gerade noch online sind:

SELECT    f.group_number
       ,  f.file_number
       ,  round (  f.bytes  / 1024  / 1024,  2)  AS mb_bytes
       ,  a.name AS file_name
    FROM v$asm_file f, v$asm_alias a, v$asm_diskgroup dg
   WHERE f.file_number = a.file_number
     AND f.group_number = a.group_number
     AND dg.group_number = f.group_number
     AND dg.name LIKE UPPER ('&&DG_NAME')
ORDER BY f.file_number
/
 
=> Hier sind nun noch ALL Dateien der Management DB Offen .....

Management DB umziehen siehe ⇒ Umziehen des GIMR

Auch müssen wir den SPFile und die PWD Datei der ASM Instance umziehen ⇒ Oracle 12c RAC- ASM SPfile und PWD File auf eine neue Disk Gruppe verschieben

Als nächstes ziehen wir dann die VOT DISK mit den VOT und OCR Files des Clusters um.

Für die VOT Disk Group auf einer HIGH Redundancy Disk Group benötigen wir min. 5 ASM Disks in 5 unterschiedlichen Fail Groups!

Ist das nicht der Fall, erhalten wir einen „ORA-15274: Not enough failgroups (5) to create voting files)“ beim Versuch die Daten umzuziehen. Auch dürfen wir nicht vergessen auf die Compatibilität richtig einzustellen sonst gibt es einen „ORA-15221: ASM operation requires compatible.asm of 11.2.0.0.0 or higher“ Fehler!

D.h. wir benötigen temporäre eine ASM Diskgroup mit min 5 Fail Groups mit je einer Disk für HIGH Redundancy (oder min 3 Failgroups für Normal Redundancy!)

In meiner Umgebung lösche ich dazu eine leere „Disk Group“ um freie ASM Candidate Disks zu erhalten.

#Auf ASM instance 2
SYS@+ASM2-racdb02>ALTER diskgroup DBFAST dismount;
 
#Auf ASM instance 1
SYS@+ASM1-racdb01>DROP diskgroup DBFAST;
 
Diskgroup dropped.

Aus den nun freien Disks erzeuge ich eine neuen Disk Group VOT_TRANS für den Umzug mit Normal Redundancy :

-- Was ist noch frei? Header Status muss ungleich MEMBER sein
 
COLUMN PATH format a35
 
SELECT HEADER_STATUS,MOUNT_STATUS,PATH 
  FROM v$asm_disk WHERE HEADER_STATUS !='MEMBER';
 
 
HEADER_STATUS                        MOUNT_STATUS          PATH
------------------------------------ --------------------- -----------------------------------
FORMER                               CLOSED                /dev/oracleasm/disks/DATA02
PROVISIONED                          CLOSED                /dev/oracleasm/disks/DATA02_02
FORMER                               CLOSED                /dev/oracleasm/disks/DATA03_02
 
 
-- wir bauen uns nun die passende Diskgroup nur für den Umzug
 
CREATE diskgroup VOT_TRANS
  failgroup storage1 disk  '/dev/oracleasm/disks/DATA02' 
  failgroup storage2 disk  '/dev/oracleasm/disks/DATA02_02' 
  failgroup storage22 disk '/dev/oracleasm/disks/DATA03_02';
 
ALTER DISKGROUP VOT_TRANS SET ATTRIBUTE 'compatible.asm'='11.2.0.0.0';
ALTER DISKGROUP VOT_TRANS SET ATTRIBUTE 'compatible.rdbms'='11.2.0.0.0';
 
 
-- Auf den zweiten Knoten online nehmen
ALTER diskgroup VOT_TRANS mount;
 

Im nächsten Schritt ziehen wir VOT Files nun auf die ASM Disk Group VOT_TRANS um.

Hier ist es empfehlenswert den Alert.log Files der ASM Instance auf Knoten 1 mit „adrci> show alert -tail -f“ in einer zweiten Session permanent zu überprüfen um sofort Fehler zu erkennen!

Prüfen:

# als Root
export GRID_HOME=/opt/12.1.0.2/grid
 
$GRID_HOME/bin/crsctl query css votedisk
 
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   d43c5b21d0d54f17bfcd036224023069 (/dev/oracleasm/disks/VOT1) [VOT]
 2. ONLINE   a33f241cd8444f2abfae1e0bae857ac6 (/dev/oracleasm/disks/VOT2) [VOT]
 3. ONLINE   c7e65ee9a3804fcebf27d9b0c0bd8fe6 (/dev/oracleasm/disks/VOT3) [VOT]
Located 3 voting disk(s).

VOT zumziehen:

# User root!
 
$GRID_HOME/bin/crsctl replace votedisk +VOT_TRANS
 
Successful addition of voting disk f7d6ba140c684fd2bf38163c4de13516.
Successful addition of voting disk 8896b49fe1bd4f93bf9423164da2d496.
Successful addition of voting disk 157f9944830c4f9dbf7955b637a4511e.
Successful deletion of voting disk d43c5b21d0d54f17bfcd036224023069.
Successful deletion of voting disk a33f241cd8444f2abfae1e0bae857ac6.
Successful deletion of voting disk c7e65ee9a3804fcebf27d9b0c0bd8fe6.
Successfully replaced voting disk group with +VOT_TRANS.
 
CRS-4266: Voting file(s) successfully replaced
 
 
/opt/12.1.0.2/grid/bin/crsctl query css votedisk
 
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   f7d6ba140c684fd2bf38163c4de13516 (/dev/oracleasm/disks/DATA02) [VOT_TRANS]
 2. ONLINE   8896b49fe1bd4f93bf9423164da2d496 (/dev/oracleasm/disks/DATA02_02) [VOT_TRANS]
 3. ONLINE   157f9944830c4f9dbf7955b637a4511e (/dev/oracleasm/disks/DATA03_02) [VOT_TRANS]
Located 3 voting disk(s).

Die OCR Files umziehen:

# als Root
#Alles überprüfen
$GRID_HOME/bin/ocrcheck
..
 Device/File Name         :       +VOT
..
Cluster registry integrity check succeeded
..
 
 
#zweite Location hinzufügen
 
$GRID_HOME/bin/ocrconfig -add +VOT_TRANS
 
 
# erste wieder entfernen
$GRID_HOME/bin/ocrconfig -delete +VOT
 
#Alles überprüfen
$GRID_HOME/bin/ocrcheck
..
Device/File Name         : +VOT_TRANS
..
Cluster registry integrity check succeeded

Nun auch gleich falls nicht schon gesehen die OCR Files spiegeln!

# Hinzufügen
$GRID_HOME/bin/ocrconfig -add +REDOA
$GRID_HOME/bin/ocrconfig -add +REDOB
 
# Testen
$GRID_HOME/bin/ocrcheck

Nun können wir unser eigentliches Ziel angehen, die alte VOT Gruppe wird gelöscht und mit NHIGH Redundancy und min. 5 Fail Groups neu angelegt, danach kann das wieder wie zuvor umgezogen werden.


Failgroup wegen Wartungsarbeiten deaktivieren

Muss nun das Storage 2 wegen Wartungsarbeiten wie einen Software Update, heruntergefahren werden, kann zu vor die Fail Group abgeschaltet werden.

Problem: „ORA-15283: ASM operation requires compatible.rdbms OF 11.1.0.0.0 OR higher“

ALTER diskgroup DBFAST offline disks IN failgroup storage2 ;
 
 
ERROR at line 1:
ORA-15032: NOT ALL alterations performed
ORA-15283: ASM operation requires compatible.rdbms OF 11.1.0.0.0 OR higher
 
# Attribute setzen
ALTER DISKGROUP DBFAST SET ATTRIBUTE 'compatible.asm'='11.2.0.0.0';
ALTER DISKGROUP DBFAST SET ATTRIBUTE 'compatible.rdbms'='11.2.0.0.0';
 
 
SYS@+ASM1-racdb01>ALTER diskgroup DBFAST offline disks IN failgroup storage2 ;
 
Diskgroup altered.
 
 
SELECT name, header_status,mount_status,mode_status,state, repair_timer,GROUP_NUMBER, path 
  FROM v$asm_disk 
WHERE   name LIKE 'DBFAST%'
ORDER BY GROUP_NUMBER;

Alle Platten vom Storage 2 sind am Ende mit „_02“ bzw „_S2“ in Prod. markiert, daher lässt so einfach das Script generieren um alle Disks vom Storage 2 abzuschalten:

SELECT 'ALTER diskgroup '|| g.name
      ||' offline disks IN failgroup '
      || d.FAILGROUP 
      ||';' 
FROM v$asm_disk d 
      INNER JOIN  v$asm_diskgroup g ON (g.group_number=d.group_number)
WHERE d.path LIKE UPPER ('%-_02') ESCAPE '-'
GROUP BY d.FAILGROUP,g.name
;
 
# Erzeugte SQL Statements nun kopieren und ausführen!

Tipp: Mit „ESCAPE '-'“ den Underscore im like suchbar machen siehe Suchen mit dem Like Operator nach Texten, die einen "_" enthalten.

Sind die Platten offline wird das Storage heruntergefahren.

Fail Group nach Wartungsarbeiten wieder aktivieren

ALTER diskgroup DBFAST online disks IN failgroup storage2 ;

Problem ORA-15410: Disks in disk group xxxx do not have equal size.

Zuerst wurde eine Diskgroup ACFS normal angelegt.

sqlplus / AS sysasm
 
CREATE diskgroup ACFS normal redundancy 
      failgroup storage1 disk '/dev/oracleasm/disks/ACFS01' 
      failgroup storage2 disk '/dev/oracleasm/disks/ACFS01_S2'
/

Am knoten 2 anmelden als sysasm:

sqlplus / AS sysasm
 
ALTER diskgroup acfs mount;

Nach ein paar Tagen hat sich herausgestellt, dass die ACFS Volume zu klein ist, daher einfach neue Platten zu den Fail groups hinzugefügt:

ALTER diskgroup ACFS 
  ADD failgroup storage1 disk '/dev/oracleasm/disks/ACFS1_S1' 
      failgroup storage2 disk '/dev/oracleasm/disks/ACFS1_S2';
 
 
*
ERROR at line 1:
ORA-15032: NOT ALL alterations performed
ORA-15410: Disks IN disk GROUP ACFS do NOT have equal SIZE.

Problem: ORA-15410: Disks in disk group ACFS do not have equal size.

Seit dem 12.1.0.2 ASM tritt diese Fehlermeldung auf wenn die Platten nicht wirklich ganz gleich groß sind!

In meinem Fall sind die neue Platte um 4 MB größer, das heißt wir können das so dann doch hinzufügen, es wird dann halt etwas Platz auf den Platten nicht verwendet:

-- Candidate Disks anzeigen lassen
 
SELECT OS_MB , DISK_NUMBER,NAME FROM v$asm_disk WHERE GROUP_NUMBER=0;
 
       OS_MB  DISK_NUMBER NAME
------------ ------------ --------------------
      153600            1
      153600            0
 
-- aktuelle ACFS Disks anzeigen lassen
 
SELECT OS_MB , DISK_NUMBER,name FROM v$asm_disk WHERE NAME LIKE 'ACFS%';
 
 
       OS_MB  DISK_NUMBER NAME
------------ ------------ --------------------
      153599            0 ACFS_0000
      153599            1 ACFS_0001
 
 
ALTER diskgroup ACFS 
  ADD failgroup storage1 disk '/dev/oracleasm/disks/ACFS1_S1' SIZE 153599M 
      failgroup storage2 disk '/dev/oracleasm/disks/ACFS1_S2' SIZE 153599M;
 
-- rebalance
ALTER diskgroup ACFS rebalance POWER 5;

Hier haben wir jetzt Glück gehabt, ist die neue Platte kleiner, muss die Platte erst auf OS Ebene vergrößert und neu als ASM Platte eingebunden werden!

Siehe dazu auch die Metalink Node Doc ID 1938950.1.

Nachdem das Rebalance durchgelaufen ist, kann das ACFS Filesystem mit „acfsutil size +40G /opt/oracle/diag_acfs“ online vergrößert werden.

acfsutil size +40G /opt/oracle/diag_acfs
acfsutil size: new file system size: 300647710720 (286720MB)
 
acfsutil info fs

Problem Add Disk - ORA-15033: disk "''" belongs to diskgroup ""

War die Platte bereits schon dieser Gruppe zugeordnet und muss nun neu anlegt werden:

ASM Failgroups OF a Diskgroup
 
GROUP                Failgroup                      Disk                 Disk                           mode
name                 name                           name                 path                           STATUS
-------------------- ------------------------------ -------------------- ------------------------------ ------
REDO01               STORAGE1                       REDO0S1              /dev/oracleasm/disks/REDO0_S1  ONLINE
REDO01               STORAGE2                       _DROPPED_0001_REDO01                                OFFLINE
 
SYS@+ASM1>ALTER diskgroup REDO01 ADD failgroup STORAGE2 disk '/dev/oracleasm/disks/REDO0_S2' name REDO0S2;
 
ALTER diskgroup REDO01 ADD failgroup STORAGE2 disk '/dev/oracleasm/disks/REDO0_S2' name REDO0S2
*
ERROR at line 1:
ORA-15032: NOT ALL alterations performed
ORA-15033: disk '/dev/oracleasm/disks/REDO0_S2' belongs TO diskgroup "REDO01"
 
# Force OPTION verwenden!
SYS@+ASM1>ALTER diskgroup REDO01 ADD failgroup STORAGE2 disk '/dev/oracleasm/disks/REDO0_S2' name REDO0S2 force;

Mit der Force Option kann die Platten wieder eingefügt werden.



Fehler Behandlung in einer ASM Umgebung mit Fail Groups über zwei Storage Systeme

Nachdem wir nun eine Testumgebung für ASM über zwei Storages erstellt haben, können wir die verschiedenen Fehler simulieren um uns auf den Ernstfall vorzubereiten.

Geht ein Storage verloren werden die Platten NICHT automatisch wieder gemountet! Wird der Fehler nicht erkannt droht eine Katastrophe!

Fehler Kontrolle

Im ersten Schritt muss das Überwachungssystem (wie Nagios etc. oder dann halt der DBA) regelmäßig prüfen, ob alle Platten noch richtig am System gemountet sind!

Script:

-- Disks auslesen 
SELECT name, header_status,mount_status,mode_status,state, repair_timer,GROUP_NUMBER, path 
  FROM v$asm_disk 
ORDER BY GROUP_NUMBER;
 
SELECT g.GROUP_NUMBER,g.name 
  FROM v$asm_diskgroup ;
 
-- und Path der fehlenden Platte ermitteln
SELECT failgroup,name,path FROM v$ASM_DISK WHERE GROUP_NUMBER=6 ORDER BY name ;

Verhalten im Fehlerfall

Geht ein Pfad zu einer der Platten oder gar dem ganzen Storage verloren, wird die ASM Disk von Oracle offline genommen.

Im Beispiel fehlen der Disk Group VOT die Platten, die Platten heißen OCR_1 bis 6:

SYS@+ASM2-tng1db02>alter diskgroup VOT mount;
alter diskgroup VOT mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "4" is missing from group number "6"

Pürfen ob die Platten in Betriebsystem noch sichtbar ist und neu scannen:

oracleasm scandisks
oracleasm listdisks | grep OCR

Nach dem Einlesen versuchen erneut zu mounten:

ALTER diskgroup VOT mount;

Das geht jetzt zwar aber 2 Platten fehlen immer noch, und haben als Member ID plötzlich die 0!.

Je nach eingestellten Compatible Parameter auf der Diskgroup geht es unterschiedlich weiter!

Bei einer neuen 12c Installation steht der Compatible Parameter per Default noch auf 10g!

Wurde zuvor der richtige Compatible Parameter gesetzt, einfach die Failgroup in 12c wieder online setzen:

ALTER diskgroup VOT  online disks IN failgroup STORAGE2;
 
-- Rebalance beobachten
SELECT * FROM v$asm_operation;
 
-- bei Bedarf last erhöhen
ALTER diskgroup vot rebalance POWER 4;

Falls nicht:

ALTER diskgroup VOTPRD  online disks IN failgroup STORAGE1
*
ERROR at line 1:
ORA-15032: NOT ALL alterations performed
ORA-15283: ASM operation requires compatible.rdbms OF 11.1.0.0.0 OR higher

Ablauf bei rdbms.compatible auf 10g, über den Pfad der Platte diese mit Force wiederaufnehmen:

-- Disks auslesen und Path der fehlenden Platte ermitteln
SELECT name, header_status,mount_status,mode_status,state, repair_timer,GROUP_NUMBER, path FROM v$asm_disk ORDER BY GROUP_NUMBER;
SELECT g.GROUP_NUMBER,g.name FROM v$asm_diskgroup ;
SELECT failgroup,name,path FROM v$ASM_DISK WHERE GROUP_NUMBER=3 ORDER BY name ;
 
 
-- Platte wiederaufnehmen
 
ALTER diskgroup VOT ADD failgroup STORAGE1 disk '/dev/oracleasm/disks/OCR01_S1' name OCR01_S1 force;
 
-- bzw bei Groups mit vielen Platten
 
ALTER diskgroup ACFS ADD 
      failgroup STORAGE1 disk '/dev/oracleasm/disks/DATA08_S_S1' name DATA08_S_S1 force
      failgroup STORAGE1 disk '/dev/oracleasm/disks/DATA09_S_S1' name DATA09_S_S1 force
      failgroup STORAGE1 disk '/dev/oracleasm/disks/DATA10_S_S1' name DATA10_S_S1 force
      failgroup STORAGE1 disk '/dev/oracleasm/disks/DATA11_S_S1' name DATA11_S_S1 force;
 
-- Rebalance beobachten
SELECT * FROM v$asm_operation;
 
-- bei Bedarf last erhöhen
ALTER diskgroup vot rebalance POWER 4;

Bei den OCR/VOT Platten ist es ratsam zu prüfen ob noch VOT Files übrig sind!

# als Root
/opt/12.1.0.2/grid/bin/crsctl query css votedisk

Falls das sehr kritisch aussieht kann es auch Sinn machen umzuziehen, allerdings muss die neue Diskgruppe min 3 Failgroups für Normal Redundancy oder 5 für HIGH Redundancy besitzen! Mein Fehler:

$GRID_HOME/bin/crsctl replace votedisk +REDO01
Failed to create voting files on disk group REDO01.
Change to configuration failed, but was successfully rolled back.
CRS-4000: Command Replace failed, or completed with errors.
 
Im Alert log der ASM Instance:
..
ORA-15274: Not enough failgroups (3) to create voting files
..
Solange sich ein VOT File auf einer Disk befinden kann diese NICHT gelöscht werden!

Problem:

-- löschen
ALTER diskgroup vot DROP disk VOT_0001;
 
Diskgroup altered.
 
-- rebalance startet und wird fertig
 
SELECT * FROM v$asm_operation;
 
-- Platte wird aber immer nach als Member der Gruppe angezeigt!
 
ALTER diskgroup vot DROP disk VOT_0005 ;
 
ERROR at line 1:
ORA-15032: NOT ALL alterations performed
ORA-15071: ASM disk "VOT_0005" IS already being dropped
 
-- Platte dann wieder zurücknehmen
ALTER DISKGROUP VOT UNDROP DISKS;

Leason learned, will man die VOT Platten umbauen, zuvor die Vot Files umziehen!

Bei Problemen mit diesen Platten auch an die OCR denken!

#Alles überprüfen
$GRID_HOME/bin/ocrcheck
 
# Min. zweite Location zur Sicherheit hinzufügen
$GRID_HOME/bin/ocrconfig -add +REDOA
$GRID_HOME/bin/ocrconfig -add +REDOB

Bei einem Diskfehler in einer ACFS Gruppe

Fehlt eine Disk in einer Diskgroup die ein ACFS Volumen hält, fällt diese logischer Weise dann auch aus

Nach dem wiederhinzufügen der verlorenen Platte das ACFS Volumen prüfen und neu mounten:

ASMCMD> volinfo --all
Diskgroup Name: ACFS
 
         Volume Name: VOLDIAG1
         Volume Device: /dev/asm/voldiag1-226
         State: DISABLED
         Size (MB): 286720
         Resize Unit (MB): 64
         Redundancy: MIRROR
         Stripe Columns: 8
         Stripe Width (K): 1024
         Usage: ACFS
         Mountpath: /opt/oracle/diag_acfs
 
 
ASMCMD> volenable --all
 
 
#prüfen ob alles wieder da ist:
 
df -h 
 
Filesystem                    Size  Used Avail Use% Mounted on
 
/dev/asm/voldiag1-226         280G  141G  140G  51% /opt/oracle/diag_acfs

CRSD Demon Fehler - CRS-0184: Cannot communicate with the CRS daemon nach Plattenverlust

Fehler im CRS Log: „2016-09-05 09:07:27.709 [OHASD(5695)]CRS-2878: Failed to restart resource 'ora.storage'“

Die Datenbank sind noch erreichbar, von außen sieht alles noch gut aus, aber ein „crs_stat -t“ bringt nur einen „CRS-0184: Cannot communicate with the CRS daemon“.

Auf beiden Knoten die Platten kontrollieren, ob die Disks wieder da sind!

# als Root
#prüfen ob alle Platten vom System auch erkannt werden
oracleasm listdisks
 
#falls VOT platten fehlen
#Neu einlesen
oracleasm scandisks

Kontrolle und restart crsd:

# Check if Cluster is ok
crsctl check cluster -all
 
Als User „grid“ , Umgebung auf +ASM1 gesetzt
 
Kontrolle Cluster Stack
crs_stat -t
CRS-0184: Cannot communicate with the CRS daemon.
 
crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
 
 
Kontrolle der VOT Platten
 
/opt/12.1.0.2/grid/bin/crsctl query css votedisk
 
OK
 
Kontrolle ob die Datenbank noch oben sind:
 
ps uafx | grep smon_
 
 
Die eigentliche Datenbank ist noch da
 
 
Testen ob die ASM Platten alle OK sind.
 
Sqlplus / as sysasm
SELECT count(*)
   , header_status
   , mount_status
   , mode_status
   , state
   , repair_timer
FROM v$asm_disk
group by header_status
   , mount_status
   , mode_status
   , state
   , repair_timer;
 
 
# Nun die VOT Platten wieder online nehmen/reparieren
 
alter diskgroup VOT mount;
 
#Je nach Szenario nun die Fehler fixen bis die Diskgroup wieder funktioniert!
# siehe weiter oben im Text wie

Testen ob Cluster Dienste vorhanden sind:

crsctl stat res -t -init
…
 
ora.crsd
      1        ONLINE  OFFLINE                               STABLE
…
ora.storage
      1        ONLINE  OFFLINE                               STABLE

Hier liegt das Problem, ora.storage und ora.crsd sind nicht vollständig gestartet!

D.h. diese Ressourcen müssen wieder aktiviert werden

Nochmals Pürfen:

crsctl status resource ora.crsd -init
NAME=ora.crsd
TYPE=ora.crs.type
TARGET=ONLINE
STATE=OFFLINE

Ressourcen neu starten:

crsctl start res ora.crsd -init
 
CRS-2672: Attempting to start 'ora.storage' on 'gpidb01'
CRS-2676: Start of 'ora.storage' on 'gpidb01' succeeded
CRS-2672: Attempting to start 'ora.crsd' on 'gpidb01'
CRS-2676: Start of 'ora.crsd' on 'gpidb01' succeeded
 
Status prüfen
crsctl status resource ora.crsd -init
 
…
STATE=INTERMEDIATE on tng1db01
.. dauert etwas
 
crsctl status resource ora.crsd -init
NAME=ora.crsd
TYPE=ora.crs.type
TARGET=ONLINE
STATE=ONLINE on tng1db01

Status vom Cluster prüfen:

crs_stat -t -v

CRS-1714: Unable to discover any voting files

Beim Start der beiden Rac Knoten startet das Cluster nicht richtig:

Fehler, VOT Files nicht das::

 
2018-02-26 12:58:23.508 [OCSSD(15723)] CRS-1714: Unable to discover any voting files, retrying discovery in 15 seconds; Details at (:CSSNM00070:) in /opt/oracle/diag/crs/racdb01/crs/trace/ocssd.trc

Prüfen ob die VOT Platten im Betriebsystem sichtbar sind!

Testen als Root auf beiden Knoten! :

# Als User root auf Knoten 1 und 2 - vergleichen ob alles da ist:
 
oracleasm listdisks
 
# in meine Fall ist ein iSCSI Storage ausgefallen
# Diesen gefixt, und dort nun neu angemeldet beiden Knoten  
# iscsiadm -m node --login
 
 
# Nachdem Fehler gefunden wurden die Platten neu einlesen
 
oracleasm scandisks
oracleasm listdisks

Nun das Cluster prüfen:

 
Als User „grid“ , Umgebung auf +ASM1 gesetzt
 
# Check if Cluster is ok
 
 crsctl check cluster -all
**************************************************************
racdb01:
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
CRS-4534: Cannot communicate with Event Manager
**************************************************************
 
 
crsctl check crs
 
CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
CRS-4534: Cannot communicate with Event Manager
 
# Überprüfen ob vom Clusterstack schon etwas gestartet ist:
 
crsctl stat res -t -init
 
# Status des CRS überprüfen
 
crsctl status resource ora.crsd -init
 
 
#CRS Starten 
 
crsctl start res ora.crsd -init
 
 
# Check ob das Cluster wieder da ist:
crs_stat -t
 
srvctl status nodeapps
srvctl status asm
srvctl status listener
 
# Als DB owner anmelden und pürfen ob die DB wieder da ist:
 
su - oracle
 
srvctl status database -d GPIDB
Instance GPIDB1 is not running on node racdb01
Instance GPIDB2 is not running on node racdb02
 
srvctl start database -d GPIDB

VOT Fehler reparieren z.b. nach einem ORA-00600: internal error code, arguments: [kfdvfGetCurrent_baddsk]

Nach einer Wartung des Storage 2 ließ sich eine Cluster Umgebung zwar wieder starten, das online Setzen der Voting ASM Gruppe führte aber dann zu einer Katastrophe, die ASM Instance wurde mit einem „ORA-00600: internal error code, arguments: [kfdvfGetCurrent_baddsk]“ Fehler beendet. Das Cluster war damit außer Funktion und der Betrieb der Datenbanken nicht mehr möglich.

Nach einer Kurzen Verschnaufpause um den Ärger zu verarbeiten führte folgende Lösung nach kurzer Zeit wieder zu einem funktionierenden Cluster:

export GRID_HOME=/opt/12.1.0.2/grid
 
# Auf beiden Knoten den Cluster Stack sauber stoppen
 
# Knoten 2 stoppen => 
$GRID_HOME/bin/crsctl stop crs –f
 
# Knoten 1 stoppen => 
$GRID_HOME/bin/crsctl stop crs -f
 
#
# Nur Knoten 1 exclusive und ohne geöffnete VOT Files öffnen:
#
$GRID_HOME/bin/crsctl start crs -excl
 
# Vot Files prüfen:
$GRID_HOME/bin/crsctl query css votedisk
 
# Hier zeigt es sich das ein VOT File ein Problem hat:
..
5. OFFLINE  2ecd33784f74bf4178909c366 () []
..
 
# Nun eine andere Disk Group auf 3 Failgroups (bei normal Redundancy) umbauen
# in eine Fall in der FRA eine Platte entfernt und wieder als neue Failgroup Platte eingebunden
 
# Nun die VOT Files umziehen
$GRID_HOME/bin/crsctl replace votedisk +FRA
 
# Im nächsten schritt die VOT Diskgruppe reparieren/prüfen
# In meine Fall was eine Disk offline
 
# Nach der Reparatur diese wieder neu Initialisieren
$GRID_HOME/bin/crsctl replace votedisk +VOT
 
 
# Cluster stoppen
$GRID_HOME/bin/crsctl stop crs
 
# Etwas warten, damit sich auch wirklich alles beendet hat
 
# Cluster wieder starten
$GRID_HOME/bin/crsctl start crs
 
# Etwas Geduld haben und prüfen ob auch alles wieder oben ist, 
$GRID_HOME/bin/crsctl stat res -t -init
 
# Bei Bedarf zur Not dann manuell neu starten
$GRID_HOME/bin/crsctl start res ora.crsd -init

Siehe Oracle Support Portal

  • ORA-00600 : [kfdvfGetCurrent_baddsk] While adding failed disk into Voting diskgroup (Doc ID 2081484.1)
  • CR / Vote disk Maintenance Operations: (ADD/REMOVE/REPLACE/MOVE) (Doc ID 428681.1)

NFS Mount längere Zeit nicht mehr vorhanden

Im Alert.log der ASM Instance:

..
NOTE: waiting for instance recovery of group 3
NOTE: waiting for instance recovery of group 3
..

Vot Gruppe 3 testen:

 crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   as______________________________  (/dev/oracleasm/disks/OCR01_S1) [VOTPRD]
 2. ONLINE   a______________________________   (/dev/oracleasm/disks/OCR01_S2) [VOTPRD]
 3. OFFLINE  7______________________________ ( /opt/oracle/votnfsdisk/vote_nfs_disk01) [VOTPRD]

Vot Disk auf NFS ist offline

Lösung

NFS Mount wieder aktivieren

Siehe auch ⇒ ASM Instance Is Hanging in an Extended Cluster When the Third Voting Disk on NFS Is Unavailable (Doc ID 1551786.1)


ASM Platten suchen

Script um alle Platten auf ASM Luns zu untersuchen:

#!/bin/sh
 
FILES=/dev/dm-*
 
LOG_FILE=/tmp/checkDMDecice.log
 
echo "Info - query all dem devices - start at  -- `date` -- " > $LOG_FILE
 
for f in $FILES
do
  echo "Info - try to read device file $f ...."    >> $LOG_FILE
  oracleasm querydisk  $f                          >> $LOG_FILE
done
 
echo "Info - finish at  -- `date` -- "        >> $LOG_FILE

Quellen

Bzgl. VOT/OCR siehe auch

Alles verloren gegangen: http://www.ewan.cc/?q=node/108

Bzgl. negativen USABLE_FILE_MB siehe:

Siehe auch:

Oracle Doku

VOT File Problem:

Hilfscript:

ASM Disk Größen Problem:

Recovery von RAC und ASM

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
dba/asm_platten_verteilen.txt · Zuletzt geändert: 2020/10/17 10:21 von gpipperr