Gunther Oracle APEX und Datenbank Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
=====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.

<fc #800000>**Tip:**</fc>
  * 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! 

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

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
<code bash>
--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';

</code>





== 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.

<code bash>
/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
</code>


  
  * 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!
<code bash>
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

</code>


----

==== 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:<code bash>
#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 
</code>
  * ISCSI iqn anpassen und Pool Name anpassen: <code bash> 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

</code>
  * mit Targetcli Konfiguration löschen und neu anlegen<code bash> 
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
</code>
  * Platten neu partioniern, sollen ja als neue Platten erkannt werden! Alles in einem rutsch mit einem Script:<code bash>
#!/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
</code>
  * 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)<code bash>vi  /etc/hosts
10.10.10.182 storage02.pipperr.local storage02
</code>
  * Testen<code bash>
# 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

</code>
  * Klappt alles, automatisch anmelden setzen <code bash>
iscsiadm -m node -T iqn.2016-09.pipperr.local:server -p storage02 --op update -n node.startup -v automatic
</code>
  * booten und testen ob die Platten automatisch dann da sind <code bash> lsblk --scsi </code> 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 <code bash>  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
</code> 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! <code bash>targetcli
cd /iscsi/iqn.2016-09.pipperr.local:server/tpg1/luns
ls
..
 o- lun8 ................. [block/rac02-votc01 (/dev/racstore02/votc01_02)]
..

</code> 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:<code bash>
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"
..
</code> 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.

<code sql>

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;

</code>

umziehen
<code bash>
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]
 
</code>
=> Nun haben wir definitiv immer wenigstes noch 2 vom Storage 1 übrig

=> Storage 2 wird jetzt gestoppt

=> Logmeldung 

<code bash>
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
</code>
Für HIGH REDUNDANCY müssen aber 3 erhalten bleiben => <fc #800000>es funktioniert nicht!</fc>

 
Storage wieder hochfahren
neu einlesen ( in einer Umgebung auf jeden Knoten ein  iscsiadm -m session --rescan und ein oracleasm scandisks) 
 
<code bash>
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;
</code>


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

=== Test VOT Platte mit NORMAL REDUNDANCY === 

Wie ist die Konfiguration:
<code bash>
[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
</code>

  * =>> 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:

<code bash>


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.
</code>

Abfragen:
<code bash>

/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).
</code>

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

<code bash>
/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]

</code>
 
=> 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 <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:
<code sql>
#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';
</code>

Am knoten 2 anmelden als sysasm:
<code sql>
sqlplus / as sysasm

alter diskgroup DBFAST mount;
</code>


----



==== 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.

<code sql>
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.

</code>


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

<code bash>
/opt/12.1.0.2/grid/bin/crsctl query css votedisk

#es werden nur die drei alten Platten angezeigt ...
</code>

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!

<note warning>Schlecht, ohne 3 Storage Location bisher keine zufriedenstellende Lösung gefunden!</note>

=> 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:
<code sql>
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 .....
</code>

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.

<code sql>
#Auf ASM instance 2
SYS@+ASM2-racdb02>alter diskgroup DBFAST dismount;

#Auf ASM instance 1
SYS@+ASM1-racdb01>drop diskgroup DBFAST;

Diskgroup dropped.

</code>

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

-- 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;
       
</code>

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:
<code bash>
# 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).

</code>


VOT zumziehen:

<code bash>
# 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).

</code>


Die OCR Files umziehen:
<code bash>
# 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

</code>

Nun auch gleich falls nicht schon gesehen die OCR Files spiegeln!
<code bash>

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

# Testen
$GRID_HOME/bin/ocrcheck

</code>



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"
<code sql>
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;

</code>

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:

<code sql>
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!

</code>

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 ===


<code sql>

alter diskgroup DBFAST online disks in failgroup storage2 ;

</code>

----








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

Zuerst wurde eine Diskgroup ACFS normal angelegt.

<code sql>
sqlplus / as sysasm

create diskgroup ACFS normal redundancy 
      failgroup storage1 disk '/dev/oracleasm/disks/ACFS01' 
      failgroup storage2 disk '/dev/oracleasm/disks/ACFS01_S2'
/
</code>


Am knoten 2 anmelden als sysasm:
<code sql>
sqlplus / as sysasm

alter diskgroup acfs mount;
</code>

Nach ein paar Tagen hat sich herausgestellt, dass die ACFS Volume zu klein ist, daher einfach neue Platten zu den Fail groups hinzugefügt:
<code sql>
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.
</code>

<fc #800000>Problem: ORA-15410: Disks in disk group ACFS do not have equal size.</fc>


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:
<code sql>

-- 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;

</code>


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.

<code bash>
acfsutil size +40G /opt/oracle/diag_acfs
acfsutil size: new file system size: 300647710720 (286720MB)

acfsutil info fs

</code>


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

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

<code sql>

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;

</code>

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.

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

==== 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: 
<code sql>
-- 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 ;

</code>

===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:
<code>
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"
</code>

Pürfen ob die Platten in Betriebsystem noch sichtbar ist und neu scannen:
<code bash>
oracleasm scandisks
oracleasm listdisks | grep OCR
</code>

Nach dem Einlesen versuchen erneut zu mounten:
<code sql>
alter diskgroup VOT mount;
</code>
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:
<code sql>
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;

</code>

Falls nicht:
<code sql>
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

</code>



Ablauf bei rdbms.compatible auf  10g, über den Pfad der Platte diese mit Force wiederaufnehmen:
<code sql>
-- 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;

</code>


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

<code bash>
# als Root
/opt/12.1.0.2/grid/bin/crsctl query css votedisk

</code>

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:
<code bash>
$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
..
</code>

<note>Solange sich ein VOT File auf einer Disk befinden kann diese NICHT gelöscht werden!</note>
Problem:
<code sql>
-- 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;

</code>
Leason learned, will man die VOT Platten umbauen, zuvor die Vot Files umziehen!


Bei Problemen mit diesen Platten auch an die OCR denken!
<code bash>

#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
</code>

==== 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:
<code bash>
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

</code>

----



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

<fc #800000>Fehler im CRS Log: "2016-09-05 09:07:27.709 [OHASD(5695)]CRS-2878: Failed to restart resource 'ora.storage'"</fc>

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!
<code bash>

# als Root
#prüfen ob alle Platten vom System auch erkannt werden
oracleasm listdisks

#falls VOT platten fehlen
#Neu einlesen
oracleasm scandisks

</code>


Kontrolle und restart crsd:
<code bash>

# 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


</code>

Testen ob Cluster Dienste vorhanden sind:
<code bash>
crsctl stat res -t -init
…

ora.crsd
      1        ONLINE  OFFLINE                               STABLE
…
ora.storage
      1        ONLINE  OFFLINE                               STABLE

</code>

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:
<code bash>

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

</code>

Ressourcen neu starten:

<code bash>

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
</code>

Status vom Cluster prüfen:
<code bash>
crs_stat -t -v
</code>

----

==== CRS-1714: Unable to discover any voting files ====


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

Fehler, VOT Files nicht das::

<code> 
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
</code>

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

Testen als Root auf beiden Knoten! :

<code bash>

# 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

</code>


Nun das Cluster prüfen:

<code bash>


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

</code>


----



==== 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 <fc #800000>"ORA-00600: internal error code, arguments: [kfdvfGetCurrent_baddsk]"</fc> 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:

<code bash>

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

</code>

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:
<code bash>
..
NOTE: waiting for instance recovery of group 3
NOTE: waiting for instance recovery of group 3
..
</code>

Vot Gruppe 3 testen:
<code bash>
 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]


</code>

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:
<code bash>
#!/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
</code>


----


==== 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/