News zu Oracle

Hostname-Änderung bei Grid Infrastructure (Oracle Restart)

Auch bei Single Host Installationen erfreut sich die Grid Infrastructure unter Unix und Linux mittler­weile 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 unter­stützt. Die Grid Infrastructure sieht also keinen Mechanismus vor, deine Konfiguration bei der Umbenennung des Serversystems zu übernehmen.

Nach dem Duplizieren und dem damit einher­ge­henden Umbenennen einer virtu­ellen 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 durch­zu­führen. Leider muss dabei auch jede einzelne Ressource wieder manuell zur Konfiguration hinzu­gefü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 exempla­risch demons­triert. 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 durch­zu­fü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 exempla­risch demons­triert. 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 hinzu­gefü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 gespei­chert werden.

Um der ASM Kandidaten für poten­tielle ASM Disks präsen­tieren 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 beher­bergt, 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 einge­bunden werden. Die Abhängigkeiten der Datenbank-Ressourcen von den ASM-Diskgroups werden dabei automa­tisch beim erstma­ligen 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 konfi­gu­rieren. Dies gestaltet sich bei den meisten einfa­cheren Konstellationen mit ein paar wenigen Datenbank-Instanzen mit überschau­barem Aufwand. Bei Konstrukten mit appli­ka­ti­ons­spe­zi­fi­schen Services, benut­zer­de­fi­nierten Ressourcen und ähnlichem wäre es jedoch wünschenswert, wenn sich der Vorgang dahin­gehend verein­fachen würde, dass man die Konfiguration nur reinitia­li­seren müsste, ohne die komplette Infrastruktur kennen zu müssen.

Hier findest du weitere Posts zu den Themen SQL Tuning bzw. Performance Tuning aus unserem News Bereich. 
icon-arrow_right_medium-violet-blue.svg

Share this article

Share on facebook
Facebook 
Share on twitter
Twitter 
Share on linkedin
LinkedIn 
Share on xing
XING 
Share on whatsapp
WhatsApp 
Share on email
Email