1. Der erste Kontakt.

Transkript

1 Umzug eines Real Application Clusters - Die Clients sollen nichts merken. Andreas Karlin Senior Consultant

2 Oracle Real Application Cluster ist bei vielen Firmen ein fester Bestandteil ihrer Infrastruktur. RAC bietet in erster Linie horizontale Skalierbarkeit, ist eine Konsolidierung die erste Wahl und bietet zusätzlich eine Verfügbarkeit auf Service- Ebene. Die genannten Eigenschaften machen die Technologie jedoch komplex und nicht alltägliche Aufgaben sind ohne Experten schwer durchführbar. Zu solchen Aufgaben gehört beispielsweise der Umzug von alter Serverhardware auf die neuesten Maschinen. Was muss hierbei beachtet werden? Und wie reagieren die Clients auf einen solchen Umzug? Dieser Artikel beschreibt ein solches Vorgehen von der Konzeptionierung bis zur Durchführung. 1. Der erste Kontakt. Ein Kunde kontaktierte uns, da eine Real Application Cluster Datenbankumgebung, nicht die gewünschte Stabilität im Rahmen des Produktionsbetriebes erbrachte. Darüber hinaus waren die eingesetzten Maschinen veraltet und der Hersteller-Support ist bereits seit längerem abgelaufen. Der Wunsch des Auftraggebers war einfach: Das vorhandene System durch neue Maschinen austauschen und dadurch auch die Stabilität des gesamten Systems zu erhöhen. Bei dieser Datenbankinfrastruktur handelte es sich um eine Data Warehouse Umgebung mit durchschnittlich 1500 gleichzeitigen Sessions. Das Datenvolumen der Datenbank lag bei ca. 2,2 Terrabyte. Die RAC-Umgebung bestand damals aus zwei Knoten. Als Betriebssystem wurde Oracle Enterprise Linux 5.7 eingesetzt. Die Oracle Clusterware- und Datenbanksoftware hatte die Version Die Hardware wurde im Jahre 2008 angeschafft. Info-Tel Datum Seite 2 / 18

3 2. Die Analyse und das Konzept Wir schlugen dem Kunden vor, das RAC in seiner aktuellen Konfiguration zu analysieren. Resultierend aus dieser Ist-Analyse, sollen Empfehlungen gegeben werden, welche im Rahmen des Umzuges auf die neuen Maschinen umgesetzt werden sollen. Es folgen die wichtigsten Empfehlungen von Trivadis: Modernisierung der Hardware (alte Maschinen) Umsetzen der Best Practices von Trivadis Einsatz von Trivadis BasEnv für schnellere Administration Lösch- und Bereinigungs-Mechanismus der Logdateien (Purge Files von Trivadis) Zusätzliches Backup der Clusterinformationen In Rahmen eines Umzugskonzeptes, wurden diverse Fragen geklärt und die Anforderungen seitens des Auftraggebers festgehalten. Die wichtigsten Fragen und Anforderungen des Auftraggebers: Wie lange dauert der Umzug? Wie aufwändig ist die Vorbereitung? Wie hoch ist das Risiko des Umzugs? Wie lange dauert die Downtime? Ein Fallback auf die alte Umgebung muss möglich sein! Die Server müssen gegen neue Hardware getauscht werden! Auf Clientebene darf keine Re-Konfiguration erforderlich sein! Unter Einbeziehung der Fragen und Anforderungen des Auftraggebers, sowie den Empfehlungen von Trivadis, wurden im Rahmen des Konzeptes zwei Umzugsvarianten erarbeitet und beschrieben. Abschliessend wurde eine Empfehlung für eine Umzugsvariante seitens Trivadis ausgegeben. Info-Tel Datum Seite 3 / 18

4 3. Wir entscheiden uns für Umzugsvariante Der Auftraggeber begutachtete das Analysedokument und entschied sich für die von Trivadis empfohlene Umzugsvariante. Die präferierte Variante sah vor, ein zweites Cluster zu installieren. Dem neuen RAC wird der bereits durch das alte RAC benutzte SAN-Bereich präsentiert. Der präsentierte SAN Bereich wird via ASM dem neuen RAC zur Verfügung gestellt. Anschließend wird die Datenbank und alle wichtigen Ressourcen in das neue RAC eingebunden. Abschließend werden die Knoten des alten RAC s deaktiviert. Die verworfene Vorgehensweise sah vor, die neuen Maschinen direkt in das vorhandene RAC aufzunehmen. Nach der Hinzunahme der neuen Maschinen hätten die alten Maschinen entfernt werden können. Allerdings wären viele Optimierungen nicht umsetzbar gewesen. Zu diesen Optimierungen gehörte z.b. die Optimierung des Datenbankdatei-Layouts. Darüber hinaus hätten keine Funktionstests durchgeführt werden können, da es sich um ein Produktionssystem handelte. Ein AddNode und DeleteNode wird in der Praxis selten durchgeführt. Soweit so gut, könnte man denken! Die gewählte Vorgehensweise hatte jedoch einen Nachteil! Bei einer frischen Installation eines Real Application Clusters, wird eine eigene Netzwerkkonfiguration bestehend aus eigener SCAN-Adresse und den zugehörigen IP s erstellt. Die Clients hätten also für die neue SCAN-Adresse um konfiguriert werden müssen. Das wäre jedoch für den Auftraggeber nicht akzeptabel gewesen. Anbei ein paar Sätze zu SCAN: Der Single Client Access Name (Abkürzung SCAN), ist ein Single-Point of Connect für das Real Application Cluster. Unabhängig von den Clients (JDBC oder Full Client) kann eine Verbindung zu der SCAN durchgeführt werden. Die SCAN ist unabhängig von der Anzahl der Knoten. Die SCAN löst round-robin auf drei IP s auf. Ähnlich wie bei einem Loadbalancer, werden die Connects auf die SCAN-IP s verteilt. Jede der drei IP s ist auf einen Listener gebunden. Diese Listener geben dann Connects weiter an die jeweilige Datenbank. Die SCAN wird während der Installation des RAC s verpflichtend erstellt. SCAN funktioniert mit Clients ab der Version Nach einigen Diskussionen wurde entschieden, die Netzwerkkonfiguration des alten Clusters auf das neue RAC umzuziehen. Somit müssen die Konfigurationen der Clients nicht angefasst werden. Nach dem Umzug ist lediglich ein starten der Applikationen erforderlich. info@trivadis.com. Info-Tel Datum Seite 4 / 18

5 4. Vorbereitung 4.1 Installation des neuen Clusters Die Installation wurde nach Wünschen des Auftraggebers und mit den Trivadis Best Practices installiert. Es wurde das Tool Trivadis BasEnv installiert und ein purgen der Logfiles konfiguriert. Ein Backup der Clusterinformationen wurde implementiert. Die Grid Infrastructure Clustersoftware, wurde auf den aktuellsten Stand gepatcht. Die Datenbanksoftware wurde identisch zum alten RAC gepatcht um Komplikationen mit dem Warehousebuilder zu vermeiden. Für die Installation wurde eine neue SCAN mit eigenen IP s genutzt. Diese wird im Laufe des Umzuges durch die vorhandene Konfiguration des alten RAC s ersetzt. Da eine RAC Installation nicht Bestandteil des Artikels ist, wird auf eine detailliertere Beschreibung verzichtet. 4.2 Testen des neuen Clusters Vor dem Umzug des Real Application Clusters, werden definierte Funktionstests durchgeführt. Die Tests, als auch die Ergebnisse, werden protokolliert. Erst wenn die Tests erfolgreich sind, sollte das Cluster an den Betrieb übergeben werden. Dieser Punkt wird in vielen Projekten vernachlässigt. Trivadis empfiehlt ausgiebig Zeit für diese Funktionstests einzuplanen. 4.3 Diverse Kleinigkeiten nicht vergessen Vor dem Beginn des eigentlichen Umzugs gilt es zu prüfen, ob die SCAN des alten RAC s auch von den Maschinen des neuen RAC s auflösbar sind. Die Disks, welche im ASM des alten RAC s genutzt werden, müssen von den neuen Knoten sichtbar sein. Die initialen PFiles und die Passwortdateien im Verzeichnis $ORACLE_HOME/dbs müssen zuvor auf die neuen Maschinen kopiert werden. info@trivadis.com. Info-Tel Datum Seite 5 / 18

6 4.4 Stoppen des alten Clusters Die Clusterware wird auf beiden Knoten gestoppt. Zusätzlich wird der Autostart der Clusterware deaktiviert, um einen versehentlichen Wiederanlauf auszuschliessen. Die Arbeiten werden auf beiden Knoten des Clusters durchgeführt. #### Stoppen des Clusters auf Knoten 1 als root [root@dwhp01 ~]# /u01/grid/ /bin/crsctl stop crs CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'dwhp01' CRS-2673: Attempting to stop 'ora.crsd' on 'dwhp01' CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'dwhp01' Ausgabe gekürzt CRS-2673: Attempting to stop 'ora.gpnpd' on 'dwhp01' CRS-2677: Stop of 'ora.gpnpd' on 'dwhp01' succeeded CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'dwhp01' has completed CRS-4133: Oracle High Availability Services has been stopped. #### Deaktivierung des Autostart des Clusters als root [root@dwhp01 ~]# /u01/grid/ /bin/crsctl disable crs CRS-4621: Oracle High Availability Services autostart is disabled. Abbildung 1: Stoppen des Clusters auf Knoten 1 #### Stoppen des Clusters auf Knoten 2 als root [root@dwhp02 ~]# /u01/grid/ /bin/crsctl stop crs CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'dwhp02' CRS-2673: Attempting to stop 'ora.crsd' on 'dwhp02' CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'dwhp02' Ausgabe gekürzt CRS-2677: Stop of 'ora.gpnpd' on 'dwhp02' succeeded CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'dwhp02' has completed CRS-4133: Oracle High Availability Services has been stopped. #### Deaktivierung des Autostart des Clusters als root [root@dwhp02 ~]# /u01/grid/ /bin/crsctl disable crs CRS-4621: Oracle High Availability Services autostart is disabled. Abbildung 2: Stoppen des Clusters auf Knoten 2 info@trivadis.com. Info-Tel Datum Seite 6 / 18

7 5. Umsetzung Die Umsetzung des Umzugs unterteilt sich in folgende Arbeitsschritte: Abfrage des Status zu Beginn Umzug der SCAN- und Listenerkonfiguration Umhängen der Diskgruppen Mounten des ACFS Dateisystems via ASMCA Anlegen der Datenbankressourcen und Instanzen Starten der Datenbank und Anlegen der Services Abfrage des Status nach Umzug Reboot der Maschinen 5.1 Abfrage des Status zu Beginn Bevor der eigentliche Umzug beginnt, ist es sinnvoll einen Status des Zielsystems zu bekommen. #### Statusabfrage der Ressourcen [GI] crsstat HA Resource Target State Node(s) ora.listener.lsnr ON ON dwhp03 dwhp04 ora.listener_scan1.lsnr ON ON dwhp03 ora.listener_scan2.lsnr ON ON dwhp03 ora.listener_scan3.lsnr ON ON dwhp03 ora.u100.dg ON ON dwhp03 dwhp04 ora.asm ON ON dwhp03 dwhp04 ora.cvu ON ON dwhp03 ora.dwhp03.vip ON ON dwhp03 ora.dwhp04.vip ON ON dwhp04 ora.gsd OFF OFF ora.net1.network ON ON dwhp03 dwhp04 ora.oc4j ON ON dwhp04 ora.ons ON ON dwhp03 dwhp04 ora.registry.acfs ON ON dwhp03 dwhp04 ora.scan1.vip ON ON dwhp03 ora.scan2.vip ON ON dwhp03 ora.scan3.vip ON ON dwhp03 Abbildung 3: Statusabfrage vor dem Umzug alle Ressourcen gestartet Der Befehl crsstat ist Bestandteil des Tools Trivadis BasEnv und zeigt eine aggregierte Zusammenfassung des Befehls crsctl status resource t. Wie der Status zeigt, ist der Netzwerkstack online. Die ASM Instanzen, sowie die darin vorhandene Cluster-Diskgruppe mit den Voting Disks, ASM SPFile und Cluster Registry sind gestartet. Info-Tel Datum Seite 7 / 18

8 5.2 Umzug der SCAN- und Listenerkonfiguration Alle SCAN Listener inklusive der SCAN werden gestoppt. Der Status zeigt, dass die SCAN-Listener und die zugehörigen VIP-Ressourcen offline sind. #### Stoppen der frischen SCAN und deren Listener via srvctl als grid [GI] srvctl stop scan_listener [GI] srvctl stop scan #### Statusabfrage der Ressourcen [GI] crsstat HA Resource Target State Node(s) ora.listener.lsnr ON ON dwhp03 dwhp04 ora.listener_scan1.lsnr OFF OFF ora.listener_scan2.lsnr OFF OFF ora.listener_scan3.lsnr OFF OFF ora.u100.dg ON ON dwhp03 dwhp04 ora.asm ON ON dwhp03 dwhp04 ora.cvu ON ON dwhp03 ora.dwhp03.vip ON ON dwhp03 ora.dwhp04.vip ON ON dwhp04 ora.gsd OFF OFF ora.net1.network ON ON dwhp03 dwhp04 ora.oc4j ON ON dwhp04 ora.ons ON ON dwhp03 dwhp04 ora.registry.acfs ON ON dwhp03 dwhp04 ora.scan1.vip OFF OFF ora.scan2.vip OFF OFF ora.scan3.vip OFF OFF Abbildung 4: Statusabfrage SCAN Listener und VIP s gestoppt info@trivadis.com. Info-Tel Datum Seite 8 / 18

9 Bevor die alte SCAN-Adresse in das neue RAC eingebunden wird, wird via nslookup geprüft, ob die SCAN-Adresse über DNS auflösbar ist. Es müssen drei IP s angezeigt werden. Danach wird die SCAN-Adresse auf den alten Namen geändert. Die SCAN-Listener werden aktualisiert und gestartet. Die folgende Prüfung der SCAN-Adresse zeigt, daß tatsächlich drei IP s eingebunden wurden. Die SCAN-Listener konnten erfolgreich gestartet werden. #### nslookup auf die alte SCAN als root [root@dwhp03 ~]# nslookup dwhp-scan.firma.de Server: Address: #53 Name: dwhp-scan.firma.de Address: Name: dwhp-scan.firma.de Address: Name: dwhp-scan.firma.de Address: #### Modifzierung der SCAN via srvctl als root [root@dwhp03 ~]# srvctl modify scan -n dwhp-scan.firma.de #### Update und start der SCAN-Listener via srvctl als grid grid@dwhp03:~/ [GI] srvctl modify scan_listener -u grid@dwhp03:~/ [GI] srvctl start scan_listener #### Prüfung der SCAN via srvctl als grid grid@dwhp03:~/ [GI] srvctl config scan SCAN name: dwhp-scan.firma.de, Network: 1/ / /eth1 SCAN VIP name: scan1, IP: /dwhp-scan.firma.de/ SCAN VIP name: scan2, IP: /dwhp-scan.firma.de/ SCAN VIP name: scan3, IP: /dwhp-scan.firma.de/ #### Prüfung der SCAN-Listener via srvctl als grid grid@dwhp03:~/ [GI] srvctl config scan_listener SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521 SCAN Listener LISTENER_SCAN2 exists. Port: TCP:1521 SCAN Listener LISTENER_SCAN3 exists. Port: TCP:1521 Abbildung 5: nslookup der SCAN und Update auf neue Konfiguration info@trivadis.com. Info-Tel Datum Seite 9 / 18

10 5.3 Umhängen der Diskgruppen Der Netzwerkstack ist erfolgreich umgezogen. Im nächsten Schritt werden die Diskgruppen umgezogen. Die Diskgruppe DG_DATABASE beinhaltet alle Datenbankdateien. DG_RECOVERY beinhaltet die Fast Recovery Area. DG_CLUSTER_FS beherbergt das ACFS mit externen Tabellen. Das Tool asmcmdh wird gestartet. Asmcmdh bietet anders als asmcmd eine editierbare Kommandozeilen-Historie. Das Tool ist Bestandteil von Trivadis BasEnv. Abschließend wird mit dem Befehl lsdg die Diskgruppen angezeigt. Es dürfen keine Disks als Offline angezeigt werden. Die Arbeiten müssen auf beiden Knoten durchgeführt werden. #### Mounten der Diskgruppen via ASMCA als grid [+ASM1] asmcmdh ASMCMD [+] > mount DG_DATABASE ASMCMD [+] > mount DG_CLUSTER_FS ASMCMD [+] > mount DG_RECOVERY #### Anzeigen der Diskgruppen via ASMCA als grid 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 EXTERN N N DG_CLUSTER_FS/ MOUNTED EXTERN N N DG_DATABASE/ MOUNTED EXTERN N N DG_RECOVERY/ MOUNTED HIGH N Y U100/ Abbildung 6: Umhängen der Diskgruppen auf neues Cluster info@trivadis.com. Info-Tel Datum Seite 10 / 18

11 Der Status der Ressourcen zeigt, daß die SCAN-Listener und die zugehörigen VIP- Ressourcen mit der alten Konfiguration online sind. Die umgezogenen Diskgruppen sind als Ressource eingebunden und auf beiden Knoten online. #### Statusabfrage der Ressourcen [+ASM2] crsstat HA Resource Target State Node(s) ora.dg_cluster_fs.dg ON ON dwhp03 dwhp04 ora.dg_database.dg ON ON dwhp03 dwhp04 ora.dg_recovery.dg ON ON dwhp03 dwhp04 ora.listener.lsnr ON ON dwhp03 dwhp04 ora.listener_scan1.lsnr ON ON dwhp03 ora.listener_scan2.lsnr ON ON dwhp04 ora.listener_scan3.lsnr ON ON dwhp03 ora.u100.dg ON ON dwhp03 dwhp04 ora.asm ON ON dwhp03 dwhp04 ora.cvu ON ON dwhp03 ora.dwhp03.vip ON ON dwhp03 ora.dwhp04.vip ON ON dwhp04 ora.gsd OFF OFF ora.net1.network ON ON dwhp03 dwhp04 ora.oc4j ON ON dwhp04 ora.ons ON ON dwhp03 dwhp04 ora.registry.acfs ON ON dwhp03 dwhp04 ora.scan1.vip ON ON dwhp03 ora.scan2.vip ON ON dwhp04 ora.scan3.vip ON ON dwhp03 Abbildung 7: Zwischenstand Cluster Resourcen Info-Tel Datum Seite 11 / 18

12 5.4 Mounten des ACFS Dateisystems via ASMCA Damit das ACFS Dateisystem sichtbar wird, wird es auf den neuen Knoten aktiviert. Anschließend wird es in der ACFS Registry registriert und abschließend gemountet. Der ASMCA wird gestartet. Danach auf den Reiter Volumes klicken. Abbildung 8: ASMCA ACFS Volumes 1 Die Rechte Maustaste auf Volume und auf Enable on all Cluster Nodes klicken. Abbildung 9: ASMCA ACFS Volumes 2 Nach der Aktivierung auf den Reiter ASM Cluster File Systems klicken. Abbildung 10: ASM Cluster File Systems info@trivadis.com. Info-Tel Datum Seite 12 / 18

13 Die Rechte Maustaste auf Mount Point und auf Register Mount Point klicken. Danach den Mount Point angeben und auf OK klicken. Abbildung 11: Registrieren des ACFS Mount Points ASMCA meldet die erfolgreiche Registrierung des Mount Points. In diesem Fenster einfach auf OK klicken. Abbildung 12: Registrieren des ACFS Mount Points - erfolgreich info@trivadis.com. Info-Tel Datum Seite 13 / 18

14 Abschließend erfolgt die Meldung des ASMCA, dass das ADVM Volume erfolgreich an den Mount Point /dwh/daten auf allen Knoten gemountet wurde. Der ASMCA kann mit dem Button Exit geschlossen werden. Abbildung 13: Übersicht - Registrierung des ACFS Mount Points 5.5 Anlegen der Datenbankressourcen & Instanzen Nach dem letzten Arbeitsschritt konnten wir das gesharte Clusterdateisystem-Laufwerk erfolgreich einbinden. Nun fehlt noch die Datenbank, welche als Ressource in die Cluster Registry eingetragen werden muss. Die Datenbankressource wird mit diversen Parametern eingebunden. Danach müssen die einzelnen Instanzen registriert werden. #### Registrieren der DB Ressource via srvctl als oracle oracle@dwhp03:~/ [DB] srvctl add database -d DWHP -o /u01/app/oracle/product/ /db_1 -c RAC -p +DG_DATABASE/dwhp/spfiledwhp.ora -r PRIMARY -n DWHP -y AUTOMATIC -a "DG_DATABASE,DG_RECOVERY" -m firma.de #### Registrieren der DB Instanzen via srvctl als oracle oracle@dwhp03:~/ [DB] srvctl add instance -d DWHP -i DWHP1 -n dwhp03 oracle@dwhp03:~/ [DB] srvctl add instance -d DWHP -i DWHP2 -n dwhp04 Abbildung 14: Erstellen der Datenbankressource inkl. Instanzen Der Status der Ressourcen zeigt nun, dass die SCAN-Listener und die zugehörigen VIP- Ressourcen mit der alten Konfiguration online sind. Die umgezogenen Diskgruppen sind als Ressource eingebunden und auf beiden Knoten online. Die Datenbank ist registriert aber noch offline. info@trivadis.com. Info-Tel Datum Seite 14 / 18

15 #### Statusabfrage der Ressourcen [DB] crsstat HA Resource Target State Node(s) ora.dg_cluster_fs.dg ON ON dwhp03 dwhp04 ora.dg_database.dg ON ON dwhp03 dwhp04 ora.dg_recovery.dg ON ON dwhp03 dwhp04 ora.listener.lsnr ON ON dwhp03 dwhp04 ora.listener_scan1.lsnr ON ON dwhp03 ora.listener_scan2.lsnr ON ON dwhp04 ora.listener_scan3.lsnr ON ON dwhp03 ora.u100.dg ON ON dwhp03 dwhp04 ora.asm ON ON dwhp03 dwhp04 ora.cvu ON ON dwhp03 ora.dwhp.db OFF OFF ora.dwhp03.vip ON ON dwhp03 ora.dwhp04.vip ON ON dwhp04 ora.gsd OFF OFF ora.net1.network ON ON dwhp03 dwhp04 ora.oc4j ON ON dwhp04 ora.ons ON ON dwhp03 dwhp04 ora.registry.acfs ON ON dwhp03 dwhp04 ora.scan1.vip ON ON dwhp03 ora.scan2.vip ON ON dwhp04 ora.scan3.vip ON ON dwhp03 Abbildung 15: Zwischenstand der Cluster Resourcen Info-Tel Datum Seite 15 / 18

16 5.6 Starten der Datenbank und anlegen der Services Die Datenbank ist endlich als Clusterressource angelegt. Jetzt fehlen noch die SQLNet- Services. Zuerst muss die Datenbank gestartet werden. Danach wird die Konfiguration und deren Status geprüft. Abschließend werden die Services angelegt und gestartet. #### Starten der DB Ressource via srvctl als oracle [DB] srvctl start database -d dwhp #### Auslesen der Konfiguration der DB Ressource via srvctl als oracle [DB] srvctl config database -d dwhp Database unique name: DWHP Database name: DWHP Oracle home: /u01/app/oracle/product/ /db_1 Oracle user: oracle Spfile: +DG_DATABASE/dwhp/spfiledwhp.ora Domain: firma.de Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: DWHP Database instances: DWHP1,DWHP2 Disk Groups: DG_DATABASE,DG_RECOVERY Mount point paths: Services: Type: RAC Database is administrator managed #### Status der DB Ressource via srvctl als oracle [DB] srvctl status database -d dwhp Instance DWHP1 is running on node dwhp03 Instance DWHP2 is running on node dwhp04 #### Anlegen der DB Services via srvctl als oracle [DB] srvctl add service -d dwhp -s srv_dwhp1 -r DWHP1 -P NONE -y AUTOMATIC - e NONE -m NONE -j LONG oracle@dwhp03:~/ [DB] srvctl add service -d dwhp -s srv_dwhp2 -r DWHP2 -P NONE -y AUTOMATIC - e NONE -m NONE -j LONG #### Starten der DB Services via srvctl als oracle oracle@dwhp03:~/ [DB] srvctl start service -d dwhp Abbildung 16: Starten der Datenbank und Erstellen des Services info@trivadis.com. Info-Tel Datum Seite 16 / 18

17 5.7 Abfrage des Status nach Umzug Der Status der Ressourcen zeigt, daß die SCAN-Listener und die zugehörigen VIP- Ressourcen mit der alten Konfiguration online sind. Die umgezogenen Diskgruppen sind als Ressource eingebunden und auf beiden Knoten online. Die Datenbank ist registiert und online. Die Datenbankservice sind online und erreichbar. [DB] crsstat HA Resource Target State Node(s) ora.dg_cluster_fs.dg ON ON dwhp03 dwhp04 ora.dg_database.dg ON ON dwhp03 dwhp04 ora.dg_recovery.dg ON ON dwhp03 dwhp04 ora.listener.lsnr ON ON dwhp03 dwhp04 ora.listener_scan1.lsnr ON ON dwhp03 ora.listener_scan2.lsnr ON ON dwhp04 ora.listener_scan3.lsnr ON ON dwhp03 ora.u100.dg ON ON dwhp03 dwhp04 ora.asm ON ON dwhp03 dwhp04 ora.cvu ON ON dwhp03 ora.dwhp.db ON ON dwhp03 dwhp04 ora.dwhp.srv_dwhp1.svc ON ON dwhp03 ora.dwhp.srv_dwhp2.svc ON ON dwhp04 ora.dwhp03.vip ON ON dwhp03 ora.dwhp04.vip ON ON dwhp04 ora.gsd OFF OFF ora.net1.network ON ON dwhp03 dwhp04 ora.oc4j ON ON dwhp04 ora.ons ON ON dwhp03 dwhp04 ora.registry.acfs ON ON dwhp03 dwhp04 ora.scan1.vip ON ON dwhp03 ora.scan2.vip ON ON dwhp04 ora.scan3.vip ON ON dwhp03 Abbildung 17: Status der Cluster Ressourcen der neuen Umgebung nach dem Umzug Der Umzug ist erfolgreich abgeschlossen 5.8 Sicher ist Sicher oder Reboot tut immer gut Nachdem alle Komponenten umgezogen wurden, ist es anzuraten, auf jeder Maschine einen Reboot durchzuführen. Stoppt und starten die Clusterware und die Ressourcen fehlerfrei, kann von einem erfolgreichen Umzug gesprochen werden. Info-Tel Datum Seite 17 / 18

18 6. Fazit Der Umzug konnte problemlos durchgeführt werden. Der Auftraggeber ist zufrieden, da alle Anforderungen umgesetzt werden konnten. Die Kernfrage ist nun: Haben die Clients wirklich nichts gemerkt? Nein, haben sie nicht abgesehen von der eigentlichen Downtime während des Umzugs und einem Wiederanlauf gegen die neue Umgebung. Fairerweise muss man erwähnen, dass der Erfolg des Projektes auch an den eingesetzten Clients lag. Die Clients setzten sich aus Oracle-Thick (Full) Clients in der Version und zusammen. Diese Version ist zu 100% SCAN kompatibel und kann dem RAC- Konstrukt SCAN umgehen. Der Umzug von anderen Clients bzw. älteren Versionen, wäre wesentlich aufwendiger gewesen und hätte im schlimmsten Fall eine andere Vorgehensweise nötig gemacht. Aus den oben genannten Gründen ist es anzuraten, auch die Clients aktuell zu halten und sich mit den Applikationsherstellern abzusprechen. Viel Erfolg beim Einsatz von Trivadis-Know-how wünscht Ihnen Andreas Karlin Trivadis GmbH Industriestrasse 4 Tel: DE Stuttgart Fax: Internet: Mail: andreas.karlin@trivadis.com info@trivadis.com. Info-Tel Datum Seite 18 / 18