News zu Oracle

Hostname-Änderung bei Grid In­fra­struc­tu­re (Oracle Restart)

Auch bei Single Host In­stal­la­tio­nen erfreut sich die Grid In­fra­struc­tu­re unter Unix und Linux mitt­ler­wei­le bester Be­liebt­heit, löst sie doch elegant die Pro­ble­ma­tik der Ver­wal­tung der für die Oracle Datenbank re­le­van­ten Res­sour­cen wie ASM, Listener, Instanzen und Services. Leider wird das Um­be­nen­nen des Hostname des Ser­ver­sys­tems durch die Grid In­fra­struc­tu­re nicht un­ter­stützt. Die Grid In­fra­struc­tu­re sieht also keinen Me­cha­nis­mus vor, deine Kon­fi­gu­ra­ti­on bei der Um­be­nen­nung des Ser­ver­sys­tems zu übernehmen.

Nach dem Du­pli­zie­ren und dem damit ein­her­ge­hen­den Um­be­nen­nen einer vir­tu­el­len Maschine schlägt der Start der Grid In­fra­struc­tu­re somit in Folge fehl. Das Sichern oder Ex­por­tie­ren der lokalen Oracle Registry führt leider nicht zum Erfolg. Abhilfe schafft hier nur, die Grid In­fra­struc­tu­re Kon­fi­gu­ra­ti­on zu entfernen und von neuem durch­zu­füh­ren. Leider muss dabei auch jede einzelne Ressource wieder manuell zur Kon­fi­gu­ra­ti­on hin­zu­ge­fügt werden. Dies gilt sowohl für die Version 11gR2 als auch 12c (inklusive 12.1.0.2).

Re­kon­fi­gu­rie­ren der Grid Infrastructure

Im Folgenden wird das Vorgehen ex­em­pla­risch de­mons­triert. Dabei wird an­ge­nom­men, dass die Um­ge­bungs­va­ria­ble GI_HOME auf das Software-Home der In­stal­la­ti­on der Grid-In­fra­struc­tu­re zeigt, also z.B. /u01/app/12.1.0/grid_1. Die Um­ge­bungs­va­ria­ble ORACLE_HOME zeigt analog auf das Home der In­stal­la­ti­on der Oracle Datenbank Software, also z.B. /u01/app/oracle/product/12.1.0/dbhome_1

Zunächst muss die aktuelle Kon­fi­gu­ra­ti­on der Grid In­fra­struc­tu­re entfernt werden. Dies erfolgt als Be­triebs­sys­tem­nut­zer root mit dem Kommando:

$GI_HOME/crs/install/roothas.pl -deconfig -force

An­schlie­ßend wird die Kon­fi­gu­ra­ti­on als root neu erstellt:

$GI_HOME/crs/install/roothas.pl

Die weiteren Schritte sind durchweg durch die Be­triebs­sys­tem Nutzer durch­zu­füh­ren, denen die Grid-In­fra­struc­tu­re- bzw. Oracle Datenbank Software-In­stal­la­ti­on gehört.

Im Gegensatz zur Erst­kon­fi­gu­ra­ti­on muss zunächst das Autostart Attribute des CSSD manuell gesetzt und der CSSD gestartet werden. An­schlie­ßend bietet es sich an, die Grid In­fra­struc­tu­re komplett neu zu starten, damit wird die Autostart-Funk­tio­na­li­tä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 ex­em­pla­risch de­mons­triert. Dabei wird an­ge­nom­men, dass die Um­ge­bungs­va­ria­ble GI_HOME auf das Software-Home der In­stal­la­ti­on der Grid-In­fra­struc­tu­re zeigt, also z.B. /u01/app/12.1.0/grid_1. Die Um­ge­bungs­va­ria­ble ORACLE_HOME zeigt analog auf das Home der In­stal­la­ti­on der Oracle Datenbank Software, also z.B. /u01/app/oracle/product/12.1.0/dbhome_1

Zunächst muss die aktuelle Kon­fi­gu­ra­ti­on der Grid In­fra­struc­tu­re entfernt werden. Dies erfolgt als Be­triebs­sys­tem­nut­zer root mit dem Kommando:

$GI_HOME/bin/crsctl modify resource "ora.cssd" -init \
-attr "AUTO_START=1" -unsupported

An­schlie­ßend kann die ASM Instanz als Ressource hin­zu­ge­fügt werden:

$GI_HOME/bin/srvctl add asm

Im nächsten Schritt muss die ASM Kon­fi­gu­ra­ti­on um den Verweis auf das SPFile ergänzt werden. Sollte sich das Pa­ra­me­ter­file der ASM in einer ASM Diskgroup befinden, muss diese gemountet und der Pfad im GPNP Profile ge­spei­chert werden.

Um der ASM Kan­di­da­ten für po­ten­ti­el­le ASM Disks prä­sen­tie­ren zu können, muss zunächst der ASM Diskgroup Discovery String gesetzt werden:

$GI_HOME/bin/srvctl modify asm -diskstring '/dev/sdd*'

An­schlie­ßend kann die Diskgroup, welche das SPFile be­her­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 Pa­ra­me­ter­file gestartet wird, greifen die De­fault­wer­te der Parameter. Dies stellt aber kein Problem dar. Jetzt kann der Pfad zum SPFile ermittelt und im GPNP Profile hin­ter­legt 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

An­schlie­ßend kann die ASM Instanz mit Hilfe der Grid In­fra­struc­tu­re gestartet werden, wobei nunmehr das SPFile Ver­wen­dung 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 Ver­wen­dung des SPFile auch der Parameter asm_diskgroups wieder greift, werden sämtliche vor der Um­be­nen­nung aktiven ASM Diskgroups gemounted und sogleich als Ressource in der Grid In­fra­struc­tu­re 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 Da­ten­ban­ken, Services und etwaige dritte Res­sour­cen ein­ge­bun­den werden. Die Ab­hän­gig­kei­ten der Datenbank-Res­sour­cen von den ASM-Diskgroups werden dabei au­to­ma­tisch beim erst­ma­li­gen Starten der Datenbank erfasst und in der Grid In­fra­struc­tu­re hin­ter­legt. 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 In­fra­struc­tu­re sieht keinen Me­cha­nis­mus vor, ihre Kon­fi­gu­ra­ti­on bei der Um­be­nen­nung des Ser­ver­sys­tems zu über­neh­men. In solchen Fällen kommt man nicht umhin, die Grid In­fra­struc­tu­re manuell neu zu kon­fi­gu­rie­ren. Dies gestaltet sich bei den meisten ein­fa­che­ren Kon­stel­la­tio­nen mit ein paar wenigen Datenbank-Instanzen mit über­schau­ba­rem Aufwand. Bei Kon­struk­ten mit ap­pli­ka­ti­ons­spe­zi­fi­schen Services, be­nut­zer­de­fi­nier­ten Res­sour­cen und ähnlichem wäre es jedoch wün­schens­wert, wenn sich der Vorgang da­hin­ge­hend ver­ein­fa­chen würde, dass man die Kon­fi­gu­ra­ti­on nur re­initia­li­se­ren müsste, ohne die komplette In­fra­struk­tur kennen zu müssen.

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

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email