Auch bei Single Host Installationen erfreut sich die Grid Infrastructure unter Unix und Linux mittlerweile bester Beliebtheit, löst sie doch elegant die Problematik der Verwaltung der für die Oracle Datenbank relevanten Ressourcen wie ASM, Listener, Instanzen und Services. Leider wird das Umbenennen des Hostname des Serversystems durch die Grid Infrastructure nicht unterstützt. Die Grid Infrastructure sieht also keinen Mechanismus vor, deine Konfiguration bei der Umbenennung des Serversystems zu übernehmen.
Nach dem Duplizieren und dem damit einhergehenden Umbenennen einer virtuellen Maschine schlägt der Start der Grid Infrastructure somit in Folge fehl. Das Sichern oder Exportieren der lokalen Oracle Registry führt leider nicht zum Erfolg. Abhilfe schafft hier nur, die Grid Infrastructure Konfiguration zu entfernen und von neuem durchzuführen. Leider muss dabei auch jede einzelne Ressource wieder manuell zur Konfiguration hinzugefügt werden. Dies gilt sowohl für die Version 11gR2 als auch 12c (inklusive 12.1.0.2).
Im Folgenden wird das Vorgehen exemplarisch demonstriert. Dabei wird angenommen, dass die Umgebungsvariable GI_HOME auf das Software-Home der Installation der Grid-Infrastructure zeigt, also z.B. /u01/app/12.1.0/grid_1. Die Umgebungsvariable ORACLE_HOME zeigt analog auf das Home der Installation der Oracle Datenbank Software, also z.B. /u01/app/oracle/product/12.1.0/dbhome_1
Zunächst muss die aktuelle Konfiguration der Grid Infrastructure entfernt werden. Dies erfolgt als Betriebssystemnutzer root mit dem Kommando:
$GI_HOME/crs/install/roothas.pl -deconfig -force
Anschließend wird die Konfiguration als root neu erstellt:
$GI_HOME/crs/install/roothas.pl
Die weiteren Schritte sind durchweg durch die Betriebssystem Nutzer durchzuführen, denen die Grid-Infrastructure- bzw. Oracle Datenbank Software-Installation gehört.
Im Gegensatz zur Erstkonfiguration muss zunächst das Autostart Attribute des CSSD manuell gesetzt und der CSSD gestartet werden. Anschließend bietet es sich an, die Grid Infrastructure komplett neu zu starten, damit wird die Autostart-Funktionalität gleich geprüft:
$GI_HOME/bin/crsctl status resource -t | grep cssd
ora.cssd 1 OFFLINE OFFLINE
$GI_HOME/bin/crsctl modify resource "ora.cssd" -init \
-attr "AUTO_START=1"
$GI_HOME/bin/crsctl stop has
[...]
$GI_HOME/bin/crsctl start has
[...]
$GI_HOME/bin/crsctl status resource -t | grep cssd
ora.cssd 1 ONLINE ONLINE srv-hal
Im Folgenden wird das Vorgehen exemplarisch demonstriert. Dabei wird angenommen, dass die Umgebungsvariable GI_HOME auf das Software-Home der Installation der Grid-Infrastructure zeigt, also z.B. /u01/app/12.1.0/grid_1. Die Umgebungsvariable ORACLE_HOME zeigt analog auf das Home der Installation der Oracle Datenbank Software, also z.B. /u01/app/oracle/product/12.1.0/dbhome_1
Zunächst muss die aktuelle Konfiguration der Grid Infrastructure entfernt werden. Dies erfolgt als Betriebssystemnutzer root mit dem Kommando:
$GI_HOME/bin/crsctl modify resource "ora.cssd" -init \
-attr "AUTO_START=1" -unsupported
Anschließend kann die ASM Instanz als Ressource hinzugefügt werden:
$GI_HOME/bin/srvctl add asm
Im nächsten Schritt muss die ASM Konfiguration um den Verweis auf das SPFile ergänzt werden. Sollte sich das Parameterfile der ASM in einer ASM Diskgroup befinden, muss diese gemountet und der Pfad im GPNP Profile gespeichert werden.
Um der ASM Kandidaten für potentielle ASM Disks präsentieren zu können, muss zunächst der ASM Diskgroup Discovery String gesetzt werden:
$GI_HOME/bin/srvctl modify asm -diskstring '/dev/sdd*'
Anschließend kann die Diskgroup, welche das SPFile beherbergt, gemounted werden:
$GI_HOME/bin/sqlplus / as sysasm
SQL> startup
ORA-00099: warning: no parameter file specified for ASM instance
ASM instance started
[...]
ORA-15110: no diskgroups mounted
SQL> alter diskgroup DG_INFRA mount;
Diskgroup altered.
SQL> exit
Da die ASM Instanz ohne Parameterfile gestartet wird, greifen die Defaultwerte der Parameter. Dies stellt aber kein Problem dar. Jetzt kann der Pfad zum SPFile ermittelt und im GPNP Profile hinterlegt werden:
$GI_HOME/bin/asmcmd ls DG_INFRA/ASM/ASMPARAMETERFILE
REGISTRY.253.912355857
$GI_HOME/bin/asmcmd spset \
+DG_INFRA/ASM/ASMPARAMETERFILE/REGISTRY.253.912355857
Anschließend kann die ASM Instanz mit Hilfe der Grid Infrastructure gestartet werden, wobei nunmehr das SPFile Verwendung findet:
$GI_HOME/bin/srvctl stop asm -f
$GI_HOME/bin/srvctl start asm
$GI_HOME/bin/sqlplus / as sysasm
SQL> show parameter spfile
NAME TYPE VALUE
---------------- ----------- ------------------------------
spfile string +DG_INFRA/ASM/
ASMPARAMETERFILE/
registry.253.912355857
Da mit der Verwendung des SPFile auch der Parameter asm_diskgroups wieder greift, werden sämtliche vor der Umbenennung aktiven ASM Diskgroups gemounted und sogleich als Ressource in der Grid Infrastructure eingebunden:
$GI_HOME/bin/crsctl status recource -t | egrep '^ora\..*\.dg'
ora.DG_INFRA.dg
ora.DG_SANDBOX_ARCH.dg
ora.DG_SANDBOX_DATA.dg
ora.DG_SANDBOX_REDO.dg
Somit müssen nunmehr nur noch die Datenbanken, Services und etwaige dritte Ressourcen eingebunden werden. Die Abhängigkeiten der Datenbank-Ressourcen von den ASM-Diskgroups werden dabei automatisch beim erstmaligen Starten der Datenbank erfasst und in der Grid Infrastructure hinterlegt. Dies wird an folgendem Beispiel deutlich:
$ORACLE_HOME/bin/srvctl add database -db sandbox \
-oraclehome $ORACLE_HOME
$ORACLE_HOME/bin/srvctl config database \
-db sandbox|grep Disk\ Groups
Disk Groups:
$ORACLE_HOME/bin/srvctl start database -d sandbox
$ORACLE_HOME/bin/srvctl config database \
-db sandbox|grep Disk\ Groups
Disk Groups: DG_SANDBOX_DATA,DG_SANDBOX_ARCH,DG_SANDBOX_REDO
Die Grid Infrastructure sieht keinen Mechanismus vor, ihre Konfiguration bei der Umbenennung des Serversystems zu übernehmen. In solchen Fällen kommt man nicht umhin, die Grid Infrastructure manuell neu zu konfigurieren. Dies gestaltet sich bei den meisten einfacheren Konstellationen mit ein paar wenigen Datenbank-Instanzen mit überschaubarem Aufwand. Bei Konstrukten mit applikationsspezifischen Services, benutzerdefinierten Ressourcen und ähnlichem wäre es jedoch wünschenswert, wenn sich der Vorgang dahingehend vereinfachen würde, dass man die Konfiguration nur reinitialiseren müsste, ohne die komplette Infrastruktur kennen zu müssen.
Share this article