DBVisit Single Instance Standby für RAC

03 Aug

Vor einigen Monaten hatte ich den spannenden Task bekommen für einen Kunden eine Single Instance
Standby aufzubauen zu dem bestehenden Real Application Cluster. Zugegebenermaßen war ich Anfangs
etwas skeptisch, ob das auch wirklich einwandfrei funktionieren würde, hinzu kommt noch, das bei
dem Cluster ein ASM Filesystem im Einsatz ist und die Single Instance Standby ein klassisches
Filesystem haben sollte.
Bis auf ein paar kleine Stolpersteinchen hat DBVisit das absolute Gegenteil bewiesen. Die
Installation an sich verlief recht unkompliziert. Wenn man zuvor schon ein mal mit DBVisit
gearbeitet hat, wird man merken, das sich die Installation und Konfiguration nicht drastisch
zu einer normalen DBVisit Installation mit einer Single Instance Primary unterscheidet.
Die RAC-spezifischen Einstellungen sollten jedoch für einen DBA, der mit Real Application Clusters
gearbeitet hat kein Hindernis darstellen.

Worauf man besonders achten sollte ist, das sowohl die RAC Nodes, als auch der Standby Server so
eingerichtet sind, das der Standard-Hostname der Private-Hostname ist. Dies ist essenziell,
da DBVisit den Hostnamen des Servers abfragt, um zu wissen ob eine Primary-Funktion (Übertragung
der Archive Logs) oder eine Standby-Funktion (Anwenden der Archive Logs) durchgeführt werden soll.
Es spart erstens Zeit wenn DBVisit über das interne Netz geht, statt über das Internet und zweitens
schont es auch die Bandbreite. Wenn man also im CLI das Kommando “hostname” absetzt, sollte immer
der interne Hostname ausgegeben werden.
Achtung! Man kann hier nur mit Hostnamen arbeiten und nicht mit IP-Adressen, da DBVisit lediglich
den Hostnamen abfragt!

Bei einer Single Instance Standby mit klassischem Filesystem sollte man zusätzlich darauf achten
das man das SPFile anpasst. Die Pfade zu den Controlfiles, Archive Logs, Redo Logs etc. müssen
hierzu angepasst werden. Abhängig von der Leistungsstärke des Standby Servers müssen unter Umständen
auch SGA-Parameter angepasst werden um den Standby Server nicht zu überlasten. In meinem Fall, war
der Standby Server zwar genauso leistungsstark, wie die beiden Nodes, jedoch bestand bereits eine
Development Datenbank mit einer SGA-Größe von 72GB, daher musste die SGA-Größe der Standby DB drastisch verkleinert werden um den Server nicht zu überlasten.

Weiterhin ist darauf zu achten, das die Archive Log Destination, in der die Archive Logs der beiden Nodes
auf dem Standby Server temporär abgelegt werden, im gleichen Verzeichnis liegen und nicht getrennt in
einzelne Unterverzeichnisse nach Nodes. Man kann zwar unterschiedliche Verzeichnisse auch in den
Konfigurationsfiles (DDC’s) angeben, dennoch wird es nicht funktionieren.
Dies ist gefährlich da DBVisit auch keine direkte Fehlermeldung ausgibt, sondern nur “No new Archive Logs to apply” obwohl ein Archive Log Gap vorhanden ist. Lediglich in den Log Files von DBVisit steht, dass die Archive Logs vom THREAD#1 bzw. THREAD#2 nicht sichtbar sind. Das heißt damit DBVisit die Archive Logs anwenden kann, müssen diese auf der Standby Seite zusammen in einem Verzeichnis liegen um für DBVisit “sichtbar” zu sein.

Man sollte natürlich auch darauf achten, dass man den Dienst “dbvnetd” auf allen Servern auf Autostart setzt, damit im Falle eines Reboots oder Crashs, die Standby gleich wieder die Verbindung zur produktiven Datenbank aufbauen kann. Das Übertragen und Anwenden der Archive Logs sollte man via Crontab Job einrichten im 15 Minuten Takt und zeitversetzt um jeweils 5 Minuten, um parallel laufende Jobs zu verhindern und gegebenenfalls Störungen zu vermeiden.
Hinsichtlich Oracle’s Preisgestaltung in Bezug auf HA-Funktionalitäten für Standard Edition Umgebungen, ist DBVisit eine zuverlässige und kostengünstige Option. Es ist einfach zu bedienen und läuft störungsfrei, somit stellt es eine gute Alternative zu Oracle’s Data Guard dar.
Spezifikation der primären Knoten:

– 4x Intel Xeon @3.30GHz
– 128 GB Memory
– Oracle Grid Infrastructure 12.1.0.2.0
– Oracle Database Standard Edition 11.2.0.4.0
– Oracle Enterprise Linux 6

Instanzen erster Knoten:

– ORACLEPRODDB1 (11.2.0.4.0)
– +ASM1 (12.1.0.2.0)
– -MGMTDB (12.1.0.2.0)

Instanzen zweiter Knoten:

– ORACLEPRODDB2 (11.2.0.4.0)
– +ASM2 (12.1.0.2.0)

Spezifikation Standby Server:

– 4x Intel Xeon @3.30GHz
– 128 GB Memory
– Oracle Database Standard Edition 11.2.0.4.0
– DBVisit Standby 7.0
– Oracle Enterprise Linux 6

Instanzen Standby Server:

– ORACLEDEVDB (11.2.0.4.0)
– ORACLEPRODDB (DBVisit Standby)

Diesen Artikel teilen :Share on Google+Share on LinkedInTweet about this on TwitterShare on Facebook

Tags: , , , , ,