Auch im langen Leben eines Oracle Real Application Clusters (RAC) - in unserem Fall eines Oracle RAC 11.2.0.2 basierend auf Oracle Clusterware 11.2.0.2 mit ASM - kann es Situationen geben, an denen sich das RAC von altbewährtem trennen muss. In unserem Fall ist es das in die Jahre gekommene zentrale SAN Storage; dieses soll nun duch ein neues SAN ersetzt werden.
Hinweis: Das Oracle RAC 11.2 in dieser Beschreibung wurde unter Oracle Linux 5.5 installiert. Oracle ASM (Automatic Storage Management) wurde als Speicherort für alle Datenbank- und Backupdateien als auch für die OCR und Voting Disks verwendet.
UPDATE: Mittlerweile gibt es hierzu ein einfacheres Vorgehen, bei dem alle Daten in einem Befehl online auf ein neues Storage migriert werden können. Weitere Informationen in folgendem MOS Dokument: 
Exact Steps To Migrate ASM Diskgroups To Another SAN/Disk-Array/DAS/etc Without Downtime. (Doc ID 837308.1)
Durch den Einsatz von Oracle ASM als zentrale Komponente für alle Datenbankdateien, Archivelogs und diskbasierten Backups war es uns ein leichtes, alle eben genannten Dateien im laufenden Betrieb (keine RAC-Datenbank benötigte eine Downtime) und ohne spürbare Beeinträchtigung der Anwender auf das neue SAN umzuziehen.
Hierfür wurden einfach die beiden vorhandenen Diskgruppen DATA und FRA (bei Exadata auch schon mal RECO genannt) um neue Disks, die ausschliesslich vom neuen SAN (im Weiteren als SAN2 gekennzeichnet) stammten, erweitert und nach einem erfolgreichen Rebalance der Diskgruppen die Disks des alten SAN (im Weiteren SAN1 genannt) aus den Diskgruppen entfernt.
Tipp: Ab Clusterware 11.2 muss man sich für Änderungen an Diskgruppen als "SYS AS SYSASM" verbinden.
a) Diskgroup Redundancy EXTERNAL und Verwendung von ASMLIB-Disks
[grid@s-sl-rac10a:~]>export ORACLE_SID=+ASM1
[grid@s-sl-rac10a:~]>sqlplus / as sysasm
sys@+ASM1> ALTER DISKGROUP data ADD DISK 'ORCL:ASM_SAN2_DISK3',
'ORCL:ASM_SAN2_DISK4';
sys@+ASM1> ALTER DISKGROUP fra ADD DISK 'ORCL:ASM_SAN2_DISK5',
'ORCL:ASM_SAN2_DISK6';
b) Diskgroup Redundancy EXTERNAL und Verwendung von Multipath-Devices
[grid@s-sl-rac10a:~]>export ORACLE_SID=+ASM1
[grid@s-sl-rac10a:~]>sqlplus / as sysasm
sys@+ASM1> ALTER DISKGROUP data ADD DISK '/dev/mapper/asm_san2_disk3',
'/dev/mapper/asm_san2_disk4';
sys@+ASM1> ALTER DISKGROUP fra ADD DISK '/dev/mapper/asm_san2_disk5',
'/dev/mapper/asm_san2_disk6';
Tipp: Hier werden nicht mehr die physikalischen Dateinamen verwendet, sondern die ASM-intern vergebenen Namen.
a) Verwendung von ASMLIB-Disks
sys@+ASM1> ALTER DISKGROUP data DROP DISK ASM_SAN1_DISK2, ASM_SAN1_DISK3;
sys@+ASM1> ALTER DISKGROUP fra DROP DISK ASM_SAN1_DISK4, ASM_SAN1_DISK5;
b) Verwendung von Multipath-Devices
sys@+ASM1> ALTER DISKGROUP data DROP DISK DATA_0000, DATA_0001;
sys@+ASM1> ALTER DISKGROUP fra DROP DISK FRA_0000, FRA_0001;
Wie steht es aber nun mit den zentralen Dateien, die die Clusterware selbst verwendet: der OCR und Voting Disks? Geht das auch online oder benötigt man hierfür dann leider doch noch eine - oft schwierig zu organisierende - Downtime?
Zum Glück haben wir aber bereits die Version 11.2 im Einsatz. Und da geht auch dieser Schritt komplett ohne Downtime einer Datenbank oder eines Clusterknotens.
Im Unterschied zu den oben skizzierten Schritten für normale Diskgruppen wird jedoch eine neue Diskgruppe mit entsprechender Redundanz benötigt. Wir legen deshalb eine neue Diskgruppe mit dem Namen OCRVOTE2 und EXTERNAL REDUNDANCY an.
Tipp: Ohne das Attribute 'COMPATIBLE.ASM' = '11.2' würden Sie beim Erstellen der neuen OCR oder Voting Disks den folgenden Oracle Fehler in der ASM-Alertdatei erhalten:
ORA-15221: ASM operation requires compatible.asm of 11.2.0.0.0 or higher
a) Diskgroup Redundancy EXTERNAL und Verwendung von ASMLIB-Disks
sys@+ASM1> CREATE DISKGROUP ocrvote2 EXTERNAL REDUNDANCY
DISK 'ORCL:OCRVOTE_SAN2_DISK1'
ATTRIBUTE 'COMPATIBLE.ASM' = '11.2';
b) Diskgroup Redundancy EXTERNAL und Verwendung von Multipath-Devices
sys@+ASM1> CREATE DISKGROUP ocrvote2 EXTERNAL REDUNDANCY
DISK '/dev/mapper/ocrvote_san2_disk1'
ATTRIBUTE 'COMPATIBLE.ASM' = '11.2';
sys@+ASM1> CREATE DISKGROUP ocrvote2 EXTERNAL REDUNDANCY DISK '/dev/mapper/ocrvote_san2_disk1' ATTRIBUTE 'COMPATIBLE.ASM' = '11.2';&nb
Als erstes müssen Sie die aktuelle Diskgruppe für die OCR Dateien identifizieren.
Dies geschieht mit dem Befehl ocrcheck.
[grid@s-sl-rac10a:~]>ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3528
Available space (kbytes) : 258592
ID : 1859458837
Device/File Name : +ocrvote
Device/File integrity check succeeded
Device/File not configured
Device/File not configured
Device/File not configured
Device/File not configured
Cluster registry integrity check succeeded
Logical corruption check bypassed due to non-privileged user
Hier ist zu erkennen, dass es derzeit nur eine einzige OCR-Datei gibt, die auf der Diskgruppe OCRVOTE liegt.
Im ersten Schritt müssen wir nun eine weitere OCR-Datei erzeugen, und zwar in der neuen Diskgruppe OCRVOTE2. Damit wird eine Spiegeldatei der ersten OCR-Datei erzeugt, der von der Clusterware gepflegt und verwaltet wird (CRSD-Prozess). In der Datei /etc/oracle/ocr.loc ist nun auch ein Eintrag für die neue OCR-Datei zu finden.
Das Ganze muss als Benutzer root durchgeführt werden.
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/ocrconfig -add +OCRVOTE2
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3528
Available space (kbytes) : 258592
ID : 1859458837
Device/File Name : +ocrvote
Device/File integrity check succeeded
Device/File Name : +OCRVOTE2
Device/File integrity check succeeded
Device/File not configured
Device/File not configured
Device/File not configured
Cluster registry integrity check succeeded
Logical corruption check succeeded
Abschließend muss nun noch die alte OCR-Datei in der Diskgruppe OCRVOTE entfernt werden (auch dies geschieht wieder als root).
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/ocrconfig -delete +OCRVOTE
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3528
Available space (kbytes) : 258592
ID : 1859458837
Device/File Name : +OCRVOTE2
Device/File integrity check succeeded
Device/File not configured
Device/File not configured
Device/File not configured
Device/File not configured
Cluster registry integrity check succeeded
Logical corruption check succeeded
Die OCR liegt nun im neuen SAN. Alles online möglich.
Zuerst sollte wieder identifiziert werden, auf welcher Diskgruppe die Voting Disks liegen. Dies ist mit dem Befehl crsctl möglich.
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE 5c6237d9f6104fd9bfe64c13a10c55dc (ORCL:OCRVOTE_SAN1_DISK1) [OCRVOTE]
Located 1 voting disk(s).
Hier ist zu sehen, dass die Voting Disks in der Diskgruppe OCRVOTE beziehungsweise genaugenommen auf der ASMLIB-Disk OCRVOTE_SAN1_DISK1 liegen.
Das Verschieben der Voting Disks von OCRVOTE auf OCRVOTE2 erfolgt bei Verwendung von ASM in einem einzigen Schritt: nicht über ADD und anschließendem DELETE, sondern über ein einfaches REPLACE.
Der Befehl dazu lautet crsctl replace votedisk (ausführen als root).
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl replace votedisk +OCRVOTE2
Successful addition of voting disk 3363150a88bc4fb3bfd8614c9e8c2d8b.
Successful deletion of voting disk 5c6237d9f6104fd9bfe64c13a10c55dc.
Successfully replaced voting disk group with +OCRVOTE2.
CRS-4266: Voting file(s) successfully replaced
Noch ein schneller Blick, ob es auch wirklich funktioniert hat.
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE 3363150a88bc4fb3bfd8614c9e8c2d8b (ORCL:OCRVOTE_SAN2_DISK1) [OCRVOTE2]
Located 1 voting disk(s).
Sieht doch gut aus!
Nun, da sowohl die Voting Disks als auch die OCR Dateien nicht mehr auf der Diskgruppe OCRVOTE liegen, könnte man glauben, die alte Diskgruppe kann nun gelöscht werden.
Aber ist gibt noch einen weiteren kleinen "geheimen" Passagier auf dieser Diskgruppe: das SPFILE der ASM-Instanzen.
Wenn man im Zuge des SAN-Wechsels auch für das ASM-SPFILE die neue Diskgruppe OCRVOTE2 nutzen will, kommt man nicht um einen Neustart der Clusterware auf den einzelnen Knoten herum - wobei dies natürlich im Rolling-Verfahren geschehen kann, um eine komplette Downtime der Datenbanken zu verhindern.
Dies würde am einfachsten über den spcopy Befehl in asmcmd gehen.
[grid@s-sl-rac10a:~/bin]>asmcmd
ASMCMD> spget
+OCRVOTE/s-sl-rac10/asmparameterfile/registry.253.789133423
ASMCMD> lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED NORMAL N 512 4096 1048576 20092 15312 1198 7057 0 N DATA/
MOUNTED NORMAL N 512 4096 1048576 20092 11897 2053 4922 0 N FRA/
MOUNTED EXTERN N 512 4096 1048576 1023 658 0 658 0 N OCRVOTE/
MOUNTED EXTERN N 512 4096 1048576 1023 628 0 628 0 Y OCRVOTE2/
ASMCMD> spcopy -u +OCRVOTE/s-sl-rac10/asmparameterfile/registry.253.789133423 +OCRVOTE2/spfileASM.ora
ASMCMD>
Danach müssen Sie nur noch als root den HA Stack jedes Knoten, nacheinander neu starten und verifizieren das die ASM Instanz mit dem neuen SPFILE gestartet ist.
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 's-sl-rac10a'
CRS-2673: Attempting to stop 'ora.crsd' on 's-sl-rac10a'
CRS-2790: Herunterfahren der von Cluster Ready Services verwalteten Ressourcen auf 's-sl-rac10a' wird gestartet
........
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 's-sl-rac10a' has completed
CRS-4133: Oracle High Availability Services has been stopped.
[root@s-sl-rac10a ~]#
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl start crs
CRS-4123: Oracle High Availability Services has been started.
[grid@s-sl-rac10a:~]>asmcmd
ASMCMD> spget
+OCRVOTE2/spfileASM.ora
ASMCMD>
Es ist jedoch möglich, auch diesen Schritt komplett online zu machen. Oracle erkennt dies auch als legitimen Weg an (geklärt per MOS).
Das Ganze würde dann folgendermaßen ablaufen:
Da die Diskgruppe OCRVOTE ja ansich eigentlich eine ganz normale ASM Diskgruppe ist (ohne Quorum-Disks zu beinhalten), könnte man sie ja auch wie eine solche behandeln. Und einfach durch das Hinzufügen und Entfernen von Disks aus SAN2 resp. SAN1 - wie oben bereits beschrieben - dafür sorgen, dass die Diskgruppe am Ende nur noch auf Disks des neuen SAN liegt.
sys@+ASM1> ALTER DISKGROUP ocrvote ADD DISK 'ORCL:ASM_SAN2_DISK2';
sys@+ASM1> ALTER DISKGROUP ocrvote DROP DISK OCRVOTE_SAN1_DISK1;
Oder entsprechend bei Verwendung von Multipath-Disks:
sys@+ASM1> ALTER DISKGROUP ocrvote ADD DISK '/dev/mapper/asm_san2_disk2',
sys@+ASM1> ALTER DISKGROUP ocrvote DROP OCRVOTE_0001;
Jetzt endlich sollten die Disks des alten SAN (SAN1) nicht mehr in Benutzung sein.
Hinweis:
Bevor sie nun aber das alte SAN in aller Euphorie einfach abschalten, sollten Sie sich doch noch einmal vergewissern, ob es nicht doch noch weitere Diskgruppen oder Devices gibt, die das SAN verwenden.
Wir helfen Ihnen natürlich gerne auch persönlich weiter: Besuchen Sie einfach unsere 
Schulung zum Thema Oracle RAC 11.2 oder wenden Sie sich vertrauensvoll an unsere Consulting-Abteilung.
In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den
Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.
