=====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== {{ :dba:oracle_asm_failgroup_configuraton.png | 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: {{ :dba:rac:vot_disk_architecture_rac_v01.png | VOT Disk Verteilung über 3 Storage Systeme}} Für die Umsetzung mit einem NFS Share siehe hier => [[linux:nfs_share_vot_files_oracle_rac|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 [[https://de.wikipedia.org/wiki/Split_Brain_(Informatik)|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 => [[https://docs.oracle.com/database/121/OSTMG/GUID-C455CEB1-0FC3-4DF4-9CD4-25EFA4D2BE01.htm#OSTMG137|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 - the disk heartbeat to the voting device and - 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 [[dba:install_rac_linux_12c|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 [[vmware:iscsi_target_for_shared_disks|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 [[linux:nfs_share_vot_files_oracle_rac|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 _S 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."// => [[https://docs.oracle.com/database/121/SQLRF/statements_5009.htm#SQLRF01114| 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 * siehe => [[linux:nfs_share_vot_files_oracle_rac|NFS für einen VOT File einem 12c Oracle Real Applikation Clusters unter Linux 7 verwenden]] * siehe => http://www.oracle.com/technetwork/database/clusterware/overview/grid-infra-thirdvoteonnfs-131158.pdf === 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 => [[dba:oracle_rac_12c_gmir#umziehen_und_neu_anlegen_des_gimr|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 => [[dba:oracle_rac_12c_gmir#umziehen_und_neu_anlegen_des_gimr |Umziehen des GIMR]] Auch müssen wir den SPFile und die PWD Datei der ASM Instance umziehen => [[dba:rac_asm_spfile_pwdfile_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 [[prog:sql_like_escape|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 * http://www.hhutzler.de/blog/relocate-ocr-and-voting-disks-to-a-different-asm-diskgroup/ * http://uhesse.com/2012/06/13/drop-an-asm-disk-that-contains-a-voting-disk/ Alles verloren gegangen: http://www.ewan.cc/?q=node/108 Bzgl. negativen USABLE_FILE_MB siehe: * https://aprakash.wordpress.com/2014/09/17/asm-diskgroup-shows-usable_file_mb-value-in-negative/ Siehe auch: * http://uhesse.com/2015/01/15/brief-introduction-to-asm-mirroring/ * http://asmsupportguy.blogspot.de/2010/04/about-asm-allocation-units-extents.html * http://www.oracle.com/technetwork/products/clustering/overview/extendedracversion11-435972.pdf Oracle Doku * https://docs.oracle.com/cd/E11882_01/server.112/e18951/asmfs_util001.htm#OSTMG91000 VOT File Problem: * Oracle RAC and Oracle RAC One Node on Extended Distance (Stretched) Clusters => http://www.oracle.com/technetwork/products/clustering/overview/extendedracversion11-435972.pdf * Using standard NFS to support a third voting file for extended cluster configuration => http://www.oracle.com/technetwork/products/clusterware/overview/grid-infra-thirdvoteonnfs-131158.pdf * http://oracleinaction.com/voting-disk/ Hilfscript: * http://www.gokhanatil.com/2014/04/a-short-script-to-list-mappings-of-asm-disks-to-physical-devices.html ASM Disk Größen Problem: * http://afatkulin.blogspot.de/2015/07/ora-15410-disks-in-disk-group-do-not.html Recovery von RAC und ASM * The ASM Priority Rebalance feature - An Example (Doc ID 1968607.1) * http://sunilthetechfreak.com/2015/07/21/how-to-restore-ocr-after-complete-loss-of-single-ocr-diskgroup/