News
DBA-Tipp: Hostname-Änderung bei der Grid Infrastructure (Oracle Restart)

Die Information ist ein schnelllebiges Gut. Jeden Tag werden wir mit hunderten Informationen zugemüllt. Deshalb sind wir bestrebt uns auf das Wesentliche zu konzentrieren und nur substantiell nachhaltige Informationen bereitzustellen.

Icon Unternehmen

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

Rekonfigurieren der Grid Infrastructure

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

Beim CSSD handelt es sich um eine interne Ressource der Grid Infrastructure. Oracle rät vom Manipulieren der GI eigenen Ressourcen, zu erkennen an dem Namensprefix 'ora.', explizit ab. Dem wird ab der Grid Infrastructure 12.1.0.2 dahingehend Nachdruck verliehen, als dass obiges Kommando mit einem Syntaxfehler abbricht. Um die Ressource dennoch konfigurieren zu können, muss der Aufruf von crsctl durch den undokumentierten Parameter -unsupported ergänzt werden:

$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

Fazit

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.