Über unsMediaKontaktImpressum
Frank Haney 11. Februar 2015

Oracle – Hochverfügbarkeit in der Standard Edition

Standby-Datenbanken mit Oracle Database realisieren

Vor allem bei neuen Oracle-Implementierungen stellt sich zwangsläufig die Frage, wie hochverfügbar das System sein muß. Eine Antwort ist in der Regel nicht ganz einfach. Natürlich kann und muß man versuchen, maximale Zeiten für eine Wiederherstellung des Systems sowohl nach einem teilweisen als auch nach einem kompletten Ausfall für mehr oder weniger planbare Wartungsmaßnahmen zu definieren. Diese werden dann in einem Service Level Agreement fixiert. Bestimmend sind dabei die Anforderungen des Geschäftsbetriebs, die einen entsprechenden Hard- und Software-Einsatz erzwingen.

Allerdings gibt es zwei limitierende Sachverhalte: Zum einen ist nicht alles, was wünschenswert erscheint, auch finanzierbar. Redundante Hardware und entsprechende Software-Lizenzen verursachen erhebliche Kosten. Zum anderen müssen auch das Know-how und die personellen Ressourcen vorhanden sein, um die implementierte komplexe Infrastruktur zu betreiben. Hochverfügbare Systeme werden ja geschaffen, um längere Zeiträume störungsfrei zu laufen.

Wenn aber dann doch etwas Unvorhergesehenes und Ungeplantes passiert, ist oft ein erheblicher Erfahrungsschatz erforderlich, um das Problem zu verstehen und adäquat zu reagieren. Der folgende Beitrag hat mit beiden limitierenden Faktoren zu tun. Was kann für die Hochverfügbarkeit eines Oracle-Datenbanksystems getan werden, das die Oracle Standard Edition (im folgenden SE) benutzt und von nicht ausreichend spezialisiertem Personal betreut wird?

Da entsteht die Frage, welche Hochverfügbarkeitslösungen von Oracle in der SE nutzbar und in der gegebenen Situation sinnvoll sind, um sich gegen die verschiedenen Fehler möglichst gut abzusichern. Bei genauerer Betrachtung erkennt man, dass nahezu die komplette entsprechende Funktionalität an die Enterprise Edition (EE) gebunden ist, so z. B. Streams, Data Guard, Flashback Database, oder gar zusätzlich zu dieser lizenziert werden muss. Im Einzelnen soll das hier nicht dargestellt werden, weil es zu weit vom Thema wegführen würde. Konkret geht es darum, mit den Mitteln der SE wenigstens ansatzweise das zu realisieren, was Oracle die Maximum Availability Architecture (MAA) nennt. Das bedeutet, sich durch Schaffung entsprechender Redundanz gegen Ausfall eines Servers genauso abzusichern wie gegen den Verlust der ganzen Datenbank.

Wie kann das nun mit Mitteln der SE erreicht werden?

Serverausfall: Durch Redundanz wird sichergestellt, dass die Arbeit mit der Datenbank beim Ausfall eines Servers unterbrechungsfrei weitergehen kann. Bei Oracle ist die Basis dafür der Einsatz der Grid Infrastructure, die als Automatic Storage Management (ASM) die Arbeit mehrerer Instanzen auf der gleichen Datenbank ermöglicht und als Clusterware diese Instanzen in einem Konstrukt zusammenfasst. Bekannt ist dieses Feature als Real Application Cluster (RAC). Normalerweise ist das eine zusätzliche kostenpflichtige Option der EE. In der SE (nicht in der SE One) kann man RAC ohne (!) zusätzliche Lizenzkosten verwenden, solange man für das Cluster als Ganzes die Lizenzbedingungen der SE einhält. Da die SE im Unterschied zur EE auf Socket-Basis lizenziert wird, ist mit den modernen Multicore-Prozessoren RAC in der SE eine kostengünstige Hochverfügbarkeitslösung. Ein Zweiknoten-Cluster mit zwei Sockets je Server ist eine derzeit durchaus beliebte Implementierung, falls keine genuinen Features der EE benötigt werden.

Datenbankverlust: RAC alleine taugt nicht als Absicherung vor Datenverlust. Natürlich wird man immer auch eine adäquate Backup-Strategie implementieren. Allerdings lässt sich damit keine Hochverfügbarkeit gewährleisten, weil bei einem Verlust von Daten, z. B. durch eine fehlende oder beschädigte Datendatei, diese aus dem Backup wiederhergestellt und dann mit den Log-Dateien nachgezogen werden müssen. Für diese Zeit steht die Datenbank in der Regel nicht für Nutzeraktionen zur Verfügung. Die Lösung des Problems ist ein Replikat der Datenbank, zu dem bei einem Fehler des Originals umgeschaltet wird. Auf diese Weise lässt sich auch Vorkehrung für den Katastrophenfall treffen. Oracle hat dafür eine ganze Reihe von Möglichkeiten, die alle eines gemeinsam haben: sie sind nur in der EE verfügbar. Das gilt auch für die naheliegende Variante Data Guard als Physical Standby. Die Frage ist nun, ob man diese Funktionalität mit Mitteln der SE nachbauen kann. Das impliziert das Problem, eine Standby-Datenbank an einem entfernten Ort als Replikat der originalen Datenbank einzurichten und manuell mit dem Original zu synchronisieren. Wie das geht und in welchem Umfang sich dabei Data Guard-Funktionalität gewinnen lässt, soll der Hauptgegenstand des Beitrags sein. Zunächst aber ein paar Bemerkungen zu RAC.

RAC in der Standard Edition

Hier gibt es wenig Spezifisches. Die Grid Infrastructure (Clusterware + ASM) kennt keine Unterscheidung von SE und EE und wird ganz normal installiert.
Bei der RAC-Datenbank müssen die Grenzen der SE für das ganze Cluster eingehalten werden. Daneben gelten für die zusatzkostenfreie Nutzung der RAC-Option folgende Einschränkungen:

  • Als Shared Storage darf nur ASM verwendet werden, kein anderes Cluster File System oder RAW (Das gilt auch für OCFS bzw. OCFS2!)
  • Alle Datenbankdateien, die ASM speichern kann, müssen auch in ASM gespeichert werden (Die Liste ist lang! Es gibt zwei für mein Thema wichtige Ausnahmen, auf die ich später noch zurückkomme)
  • Alle nicht-Datenbankdateien von Oracle müssen in ACFS oder einem lokalen File System gespeichert werden
  • Es darf kein anderes Cluster Management außer der Oracle Clusterware verwendet werden

Weitere Einschränkungen bezüglich für das RAC sinnvoller Funktionalität ergeben sich aus allgemein in der SE fehlenden Features wie paralleles Backup und Recovery, Parallel Query/DML etc.

Einschränkungen einer manuellen Standby Database gegenüber Data Guard

Worauf muss man verzichten, wenn man eine Standby-Lösung mit den Mitteln der SE quasi nachbaut? Die beiden gravierendsten Einschränkungen gegenüber der EE sind:

  • Keine Archivierung über das Netzwerk an ein Remote-Ziel (Das Attribut SERVICE bei der Konfiguration von Archivierungszielen ist in der SE ungültig)
  • Kein Managed Recovery (Neue Archive Logs werden auf der Standby-Seite nicht automatisch erkannt und angewendet)

Damit zusammenhängend und darüber hinaus gibt es weitere Funktionalität von Data Guard, die in der SE nicht zur Verfügung steht. Hier eine unvollständige Liste:

  • Keine Duplizierung der Standby-DB von der aktiven Primär-DB
  • Keine Real Time Apply der Logs wegen fehlender Standby Redo Logs
  • Kein Graceful Switchover für z. B. Wartungen
  • Fehlender Data Guard Broker und damit verbundene Funktionen wie z. B. Fast Start Failover
  • Keine selbständige Erkennung und Behebung von Log Gaps
  • Keine Propagierung von physischen Änderungen an der Primär-DB zur Standby-Seite (neue Tablespaces oder Datendateien)

Ein weiteres Problem tritt auf, wenn die Primärseite ein RAC ist, wo es ja die weiter oben genannten Einschränkungen gibt. Wie erzeugt und pflegt man eine Standby-DB, wenn alle relevanten Dateien der Primärseite im ASM liegen müssen? Natürlich gibt es Möglichkeiten, Dateien aus dem ASM herauszuholen und zur Standby-Seite zu kopieren, z. B. FTP oder DBMS_FILE_TRANSFER. Das ist aber umständlich und verkompliziert die Abläufe. Zum Glück kommt Oracle uns hier bei den Lizenzbedingungen für RAC in der SE entgegen und erlaubt folgende Ausnahmen:

  • RMAN-Backups in das lokale File System, mit denen man eine Standby-DB überhaupt erst implementieren kann
  • Ein lokales Archivierungsziel außerhalb von ASM, das zum manuellen Nachziehen der Standby-DB genutzt werden kann

Implementierung der manuellen Standby Database

Wenn man die oben genannten Einschränkungen einrechnet, dann unterscheidet sich die Implementierung nicht besonders von Data Guard.
Zunächst einmal muss das Standby-System vorbereitet werden. Viele Schritte sind analog zur Primärseite durchzuführen, z. B. das Anlegen von Benutzern und Gruppen, das Herstellen der SSH-Konnektivität und die Konfiguration des Betriebssystems entsprechend den Oracle-Vorgaben. Da ASM verwendet werden soll, die Standby-Seite aber kein RAC ist, muss die Oracle Grid Infrastructure für einen Standalone Server (Oracle Restart) installiert werden. Daneben sind auch Vorbereitungen auf der Primärseite notwendig. Wichtig dabei ist, sicherzustellen, dass das Logging für alle Operationen (alter database force logging) und die Konfiguration eines zusätzlichen lokalen Archivierungsziels stattfinden.

Dazu kommen das Anlegen einer Parameterdatei für die Standby-Seite, das Kopieren der Passwortdatei zur Standby-Seite und die Aufnahme der Standby-DB in die Namensauflösung aller beteiligten Parteien (Original, Standby, Clients). Die Implementierung der Standby-Datenbank startet mit einem RMAN-Vollbackup des Originals in ein Verzeichnis außerhalb des in ASM befindlichen Fast Recovery Area (FRA). Dieses wird dann z. B. mit scp zur Standby-Seite transferiert.

Jetzt kommt der entscheidende Schritt: das Anlegen der Standby-Datenbank aus dem Backup. Die Standby-Instanz muss dazu mit der erstellten Parameterdatei in den Status NOMOUNT gebracht werden. Dann wird das Original mit dem RMAN (Recovery Manager) repliziert:

rman target sys/ password@primary auxiliary sys/password@standby
RMAN> duplicate database for standby nofilenamecheck dorecover;

Damit ist die Standby-DB angelegt. Im nächsten Schritt geht es darum, sich um ihre Aktualisierung zu kümmern.

Aktualisierung der Standby-Datenbank

Nun muss die Standby-Seite möglichst synchron mit dem Original gehalten werden. Da es in der SE keine Archivierung an ein Remote-Ziel (automatisches Log Shipping) und auch kein Managed Recovery für die Standby-DB gibt, ist das nur in Grenzen möglich. Man muss sich immer der Tatsache bewusst bleiben, dass sich mit einer manuellen Lösung nie der gleiche Schutzstatus wie mit Data Guard erreichen lässt.

Im Internet finden sich mehr oder weniger elaborierte Varianten für diese Aufgabe. Ich bin der Auffassung, dass man es so einfach wie möglich halten sollte. Im gegebenen Projekt wurde folgender Ablauf realisiert:

  • Die aktuellen Online Redo Logs aller Threads der Primärseite werden archiviert
  • Die Archive Logs werden mit rsync zur Standby-Seite kopiert
  • Das Recovery der Standby-DB wird durchgeführt
  • Alte Archive Logs werden auf der Standby-Seite gelöscht. Das Zeitfenster muss entsprechend großzügig gewählt werden

Im Skript (Ausschnitt) sieht das so aus:

Archivierung der aktuellen Log-Dateien der Primärdatenbanken:

$ORACLE_HOME/bin/sqlplus sys/ password@primary as sysdba <<EOF
alter system archive log current;
exit
EOF

Transport zur Standby-Seite:

rsync -e ssh -Pazv node1:/path/*.arc /path/
rsync -e ssh -Pazv node2:/path/*.arc /path/

Recovery der Standby-DB:

$ORACLE_HOME/bin/sqlplus sys/password@standby as sysdba <<EOF
recover automatic standby database;
cancel
exit
EOF

Archivelogs älter als 8 Tage löschen:

find /path -type f -mtime +8 –delete
exit

Dieses Skript wird dann per Cron-Job ausgeführt. Die Frequenz richtet sich nach der Transaktionslast der Primärseite und nach dem Datenverlust, den man gegebenenfalls zu tolerieren bereit ist. Da ist ein Kompromiss notwendig. Das Recovery bringt natürlich regelmäßig eine Fehlermeldung, weil die nächste Log-Sequenz fehlt, die ja auf der Primärseite noch nicht archiviert worden ist.

Noch ein Hinweis: Unter Umständen müssen auch Backupskripte angepasst werden. Denn es wäre kontraproduktiv, wenn auf der Primärseite Archivelogs verschwinden, die noch nicht zur Standby-Seite übertragen sind. Es empfiehlt sich also nicht, zwischen zwei Skriptläufen die Archive Logs mit der Option Delete Input zu sichern.

Test und Überwachung der Funktionalität

Natürlich muss man überprüfen, ob die Archive Logs auch auf der Standby-Seite angewendet werden. Das ist nun nicht so einfach wie bei Data Guard. Dort braucht man nur zu überprüfen, ob für die letzte übertragene Log-Sequenz in der Spalte APPLIED von V$ARCHIVED_LOG YES steht. Das lässt sich im gegebenen Fall nicht anwenden, weil auf der Standby-Seite diese View gar nicht gefüllt wird. Es besteht nur die Möglichkeit, auf der Primärseite eine Änderung an Daten oder Objekten durchzuführen, dann die Standby-Seite zu aktualisieren und danach die Standby-DB Read Only zu öffnen, um zu überprüfen, ob die Änderungen auch angekommen sind. Dann kann man sie wieder schließen und mounten, damit der nächste reguläre Synchronisationszyklus stattfinden kann.

Das ist nun aber ein Verfahren, mit dem man einmalig den Erfolg der Implementierung testet. Es ist weniger geeignet, um kontinuierlich zu überwachen, dass die Standby-Seite nicht zu weit hinter dem Original zurück ist. Im Falle von Data Guard hat man dafür neben verschiedenen Views die Hochverfügbarkeitskonsole des Enterprise Managers. In der SE gibt es diese nicht. Welche Abfrage kann man benutzen, um zuverlässig anzuzeigen, ob die Standby-Seite länger als einen Synchronisationszyklus zurück ist? Einige Views werden nicht befüllt, wie z. B. V$ARCHIVED_LOG, andere beim Synchronisieren nicht inkrementiert, wie z. B. V$LOG. Möglich wäre V$LOG_HISTORY. Ich habe mich für V$DATAFILE_HEADER entschieden, in der CHECKPOINT_SCN und CHECKPOINT_TIME bei jeder Synchronisation fortgeschrieben werden. Folgende Abfrage auf der Standby-Seite löst also das Problem:

SQL> SELECT SYSDATE-MAX(CHECKPOINT_TIME) FROM V$DATAFILE_HEADER;

Diese kann man dann unter Angabe geeigneter Schwellenwerte z. B. in eine Nagios-Überwachung integrieren.

Vorgehensweise bei physischen Änderungen am Original

Hier ist in erster Linie gemeint, was beim Erstellen eines neuen Tablespace oder dem Hinzufügen einer neuen Datendatei zu einem vorhandenen zu tun ist. Probleme mit den Pfaden gibt es nicht, da wir uns ja entschlossen haben, auf beiden Seiten ASM mit dem gleichen Disk Group Layout zu verwenden.

Nun gibt es den Parameter STANDBY_FILE_MANAGEMENT, der auf AUTO gestellt werden kann und dann dafür sorgt, dass eine neue Datendatei automatisch auch auf der Standby-Seite angelegt wird. Das funktioniert zwar auch in der SE, man darf es aber leider nicht, weil es genuine Funktionalität von Data Guard und damit der EE ist. Was passiert also, wenn der Parameter auf MANUAL gesetzt wird, bei derartigen Änderungen am Original? Das notwendige Recovery auf der Standby-Seite schlägt fehl mit:

ORA-00283: Recovery Session wegen Fehlern abgebrochen
ORA-01274: Datendatei '…' kann nicht hinzugefugt werden - Datei konnte nicht erstellt werden

Ein neuer Tablespace wird zwar auf der Standby-Seite angelegt, als Datendatei aber nur ein Dummy in $ORACLE_HOME/dbs mit einem kryptischen Namen wie UNNAMED00013 angegeben. Die Lösung ist aber nicht schwer. Man muss die Datei einfach mit richtigem Namen an der richtigen Stelle neu anlegen und das Recovery wiederholen. Den Namen des Dummy besorgt man sich aus der V$DATAFILE.

SQL> alter database create datafile '$ORACLE_HOME/dbs /UNNAMED00013' as '+ORADATA';
SQL> recover automatic standby database;

Einige Änderungen werden dagegen problemlos automatisch an die Standby-Seite weitergereicht:

  • Einstellung der Maximalgröße für eine Datei
  • Änderung der aktuellen Dateigröße mit RESIZE
  • Allokierung neuer Extents bei Nutzung von AUTOEXTEND ON für die Dateien
  • Löschen von Tablespaces

Failover zur Standby-Seite

Wie schon in der Auflistung der Einschränkungen von Standby in der SE festgestellt, gibt es keinen einfachen Rollentausch (Switchover) beider Seiten. Damit ist Standby in der SE weniger geeignet als Hochverfügbarkeitslösung für geplante Auszeiten (Wartungsmaßnahmen). Es bleiben ungeplante Auszeiten, wie ein Crash des Originalsystems oder ein Ausfall des primärseitigen Storage. Das lässt sich auch in der SE durch ein Failover zur Standby-Seite absichern. Dieses nun erfordert nun keine besonders komplexen Operationen:

  • Es sollte ein Versuch unternommen werden, die aktuellen Logdateien der Primärseite zu archivieren
  • Alle noch nicht übertragenen Archive Logs sollten nach Möglichkeit zur Standby-Seite kopiert und dort angewendet werden
  • Die Standby-DB wird aktiviert
  • Danach kann sie READ WRITE geöffnet werden
  • Die Clients müssen auf die Standby-Seite zugreifen

Was ist nun aber zu tun, wenn man nach Behebung des Problems auf die Primärseite zurückschwenken möchte? Auch da sind die Möglichkeiten gegenüber Data Guard begrenzt. Letztlich läuft es darauf hinaus, dass zweimal das hier beschriebene Verfahren angewendet wird:

  • Die ehemalige Primärseite wird als Standby-DB implementiert
  • Dorthin wird ein Failover durchgeführt
  • Um den Ausgangszustand wiederherzustellen, wird die ursprüngliche Standby-DB neu implementiert

Daraus ergibt sich auch, dass man sich genau überlegen wird, ob man den Fehler auf der Primärseite sucht und behebt oder zur Standby-Seite schwenkt.

Die Herstellung des Originalzustandes ist doch recht aufwendig. Natürlich kann man das Failover auch in Skripte packen, die auf ein primärseitiges Event reagieren, z. B. mittels Fast Application Notification (FAN - Bestandteil der Oracle Grid Infrastructure), dem Fast Start Failover von Data Guard nachempfunden. Ob man aber die Kontrolle über das Failover aus der Hand geben sollte, ist nach meiner Ansicht hier noch zweifelhafter als bei Data Guard.

Grundsätzlich ist auch ein Switchover möglich. Dazu müssen beide Seiten synchron und konsistent geschlossen sein. Den Rollentauch erreicht man dann durch Austauchen der Kontrolldateien.

Fazit

Mit einer manuellen Standby-Datenbank kann man kostengünstig das Bedürfnis nach einem möglichen Desaster-Recovery befriedigen. Nicht mehr, aber auch nicht weniger. Man muss sich aber immer der Tatsache bewusst bleiben, dass sich auf diese Weise kein völliger Schutz vor Datenverlust erreichen lässt. Gleichzeitig möchte ich festhalten, dass Implementierung und Pflege zwar nicht beliebig kompliziert, aber auch nicht trivial sind. Wer sich das nicht zutraut, sei auf eine der kommerziellen Lösungen wie z. B. DBVisit [1] verwiesen. Diese machen zwar auch nichts anderes, als die Funktionalität von Data Guard so weit wie möglich mittels Software nachzubauen. Als Zugabe hat man dann noch eine graphische Benutzeroberfläche. Die Einschränkungen der SE gelten natürlich auch hier.

Quellen

[1] DBVisit

Autor

Frank Haney

Dr. Frank Haney ist ein selbständiger Datenbankexperte (Oracle). Sein Spezialgebiet sind Hochverfügbarkeitslösungen wie RAC und Data Guard sowie Performanceuntersuchungen und Monitoring. Er ist Oracle Trainer für Oracle…
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben