Hochverfügbarkeit ist eine so geläufige Forderung an Datenbanken, dass die meisten Hersteller einfach administrierbare Tools zum Schutz vor Ausfällen mitliefern. Eine dieser Techniken, die Oracle für diesen Zweck in petto hat, heißt Data Guard.

Ob Onlineshop oder Finanzbuchhaltung, Wetterdienst oder Aktienhandel, Nachrichtenagentur oder Genforschungslabor – immer arbeiten im Hintergrund Datenbanken, ohne die alle Räder stillstehen würden. Weil die meisten Prozesse heute auf solche Datenablagen angewiesen sind und deren Ausfall oft mit empfindlichen finanziellen Verlusten verbunden wäre, gehören die Techniken für Hochverfügbarkeit in diesem Bereich zum Standard.

Dauerbetrieb garantiert

Entsprechend hat auch Oracle, eine der meistbenutzten kommerziellen Datenbanken, gleich mehrere High-Availability-Konzepte realisiert: Bis Version 8i gab es den Oracle Parallel Server (OPS). Heute kann der Nutzer auf Standby-Datenbanken, ab Version 9i tragen sie den Namen Data Guard, zurückgreifen oder den Real Application Cluster (RAC) einsetzen oder Oracles Flashback-Technologie verwenden.

Der Real Application Cluster, der wahrscheinlich bekannteste Ansatz, besteht aus mehreren Serverknoten, die gemeinsam auf ein Speichersystem zugreifen (Shared Storage). Dessen Hardware muss unbedingt ausreichend redundant ausgelegt sein, weil ihr Ausfall das Aus für den gesamten Cluster bedeuten würde. Das Hinscheiden eines Serverknotens dagegen kann ein Cluster-Kollege, der die ausgefallenen Dienste einfach übernimmt, fast ohne Zeitverlust kompensieren.

Hardware-Ausfälle jeder Art, also inklusive eines Aus der Speichersysteme, vermag dagegen der Data Guard aufzufangen. Freilich hat das einen Preis, denn hinter diesem Konzept steht ein Zwillingssystem aus einer Produktionsdatenbank und bis zu neun Kopien (Standby-Systemen). Der Data Guard eignet sich aufgrund seines Konzepts und wegen des überschaubaren Administrationsaufwands sowie der geringen Softwarekosten besonders für kleinere und mittelgroße Anwendungen. Abbildung 1 verdeutlicht seine Funktionsweise.

Abbildung 1: So funktioniert Data Guard: Die Redo-Logs übertragen die Änderungen an den gespeicherten Daten vom primären System auf die Kopie.

Während sich beim RAC – bedingt durch den Shared Storage – der Server und die Speichersysteme am selben Ort befinden müssen, lassen sich beim Data Guard die primären und alle sekundären Datenbanken räumlich getrennt installieren. Befände sich die primäre Datenbank in Berlin, dürfte ein Standby-System etwa in Wien laufen. Damit ließe sich dann sogar die höchste Stufe der Absicherung – ein Desaster Tolerant System – erreichen, das selbst dann ohne merklichen Zeitverlust weiterarbeitet, wenn eine Seite durch Brand oder einen Elementarschaden (Überschwemmung, Erdbeben) total zerstört würde [1].

Erwünschte Nebeneffekte

Auch die planmäßige Maintenance vereinfacht der Data Guard erheblich. So können die Administratoren problemlos auf einer Seite Wartungsarbeiten erledigen, die zwingend eine Downtime des Systems erfordern. In dieser Zeit arbeitet der Partner alle Anfragen ab, der sich nach einem abschließenden Switchback wieder in seine ursprüngliche Rolle als Standby-System fügt.

Darüber hinaus braucht das Standby-System nicht nur im Dienst der Hochverfügbarkeit zu stehen [3]. Es kann beispielsweise auch das primäre System beim Erstellen Ressourcen-fressender Reports entlasten oder langwierige Statistiken berechnen.

Ungleiche Kopien

Der Data Guard kennt zwei Arten von Standby-Datenbanken: die physische und die logische Kopie, man spricht auch von Redo-Apply beziehungsweise SQL-Apply. Der Unterschied zwischen den beiden Arten ist erheblich: Die physische Standby-Datenbank ist eine exakte Kopie der Primary-Datenbank. Die logische Standby-Datenbank, die mit Hilfe von SQL-Kommandos synchronisiert wird, führt dagegen nur Veränderungen an Tabelleninhalten mit, beachtet aber keine Strukturänderungen (zum Beispiel kein »Alter Table…«). Das rührt daher, dass der Kopierprozess keine Konstrukte der DDL (Data Definition Language) oder der DML (Data Manipulation Language) verwenden kann. Ein Select-Statement auf die View »DBA_LOGSTDBY_UNSUPPORTED« auf dem primären System listet alle nicht unterstützten Objekte auf (siehe auch Tabelle 1).

Das hier diskutierte Beispiel verwendet eine physische Standby-Datenbank (Redo-Apply). Der Ausdruck bezieht sich auf die von jeder Datenbank geführten so genannten Online Redo-Logs, die alle Aktionen dokumentieren. Der Log-Writer-Prozess (LGWR) schreibt die Log-Einträge zyklisch in Dateien, die der Archiver-Prozess (»arc0«) archiviert, sofern der »ARCHIVELOG«-Mode der Datenbank aktiviert ist. Aus ihnen lässt sich im Fehlerfall der Zustand der Datenbank zu einem bestimmten Zeitpunkt wiederherstellen. Der auf diesen Logs beruhende Datenabgleich zwischen primärem und Standby-System findet in zwei Schritten statt: Im ersten übermittelt das primäre System seine Redo-Daten an den Partner, im zweiten Schritt wendet der die darin aufgezeichneten Änderungen auf seinen Datenbestand an. Das Standby-System führt dabei permanent die gleichen Operationen aus wie eine Datenbank, die nach einem Crash den letzten Zustand anhand ihrer Logs recovert. Das Ergebnis sind identische Datenbestände auf beiden Seiten.

Schneller oder sicherer

Je nach Konfiguration fällt dieser Recovery-Mechanismus mit Blick auf größere Datensicherheit restriktiver oder mit dem Ziel höherer Verfügbarkeit weniger restriktiv aus. Muss Datenverlust um jeden Preis vermieden werden, ist der Maximum Protection Mode das Mittel der Wahl. In diesem Modus loggt das Primary-System seine Aktivitäten immer zugleich in seinem eigenen Redo-Log und dem der Standby-Datenbank und vergewissert sich, dass mindestens eine der Standby-Datenbanken auch wirklich alle Redo-Daten bekommen hat. Ohne eine solche Bestätigung stellt die primäre Datenbank ihren Betrieb ein.

Damit ein Ausfall des Standby-Systems unter diesen Umständen nicht etwa genau jene Folgen hat, vor denen es eigentlich schützen soll, sind hier mindestens zwei Standby-Datenbanken Bedingung. Die Attribute »SYNC«, »LGWR« und »AFFIRM« in dem Parameter »LOG_ARCHIVE_DEST_n« aktivieren diesen Schutzmechanismus auf dem Standby-System. Die Tabelle 3 listet weitere wichtige Attribute.

In einer alternativen Konfiguration, dem Maximum Availability Mode, hat die Verfügbarkeit eine höhere Priorität. Eine Datenbanktransaktion wird in diesem Modus so lange nicht committet, bis Data Guard sie auf irgendeiner Standby-Datenbank ins Online Redo-Log schreiben konnte. Das kann zu Verzögerungen führen, hat aber beim Ausfall der Standby-Systeme keinen Stillstand zur Folge. Ist kein Standby-System mehr verfügbar, agiert die primäre Datenbank im Maximum Performance Mode, bis der Fehler behoben und die Datendifferenz von Hand korrigiert ist.

Die Grundeinstellung des Data Guard ist der Maximum Performance Mode, bei dem Geschwindigkeit höchste Priorität genießt. Die Redo-Daten kann die Standby-Datenbank dabei asynchron übergeben, wobei die Primary-Datenbank das Log zunächst archiviert und es später dem Standby-System überspielt.

Früher oder später

Aus den Beschreibungen der Modi folgt als wichtigste Konsequenz für die Konfiguration des Standby-Systems, dass die Übergabe der Redo-Daten an die Standby-Datenbank zu zwei unterschiedlichen Zeitpunkten passieren kann: Entweder übernimmt der »arc0«-Prozess der primären Datenbank diese Aufgabe und sendet die archivierten Redo-Logs an die sekundäre Datenbank. In diesem Fall braucht das Standby-System nicht unbedingt ein eigenes Redo-Log zu führen. Die ankommenden Daten werden durch den MRP (Managed Recovery Process) verarbeitet (Abbildung 2).

Abbildung 2: Übergabe der Redo-Logs durch den Archivierungsprozess. Die Standby-Datenbank braucht nicht unbedingt eigene Logs.

Abbildung 3: Übergabe der Logs durch den Logwriter-Prozess. Hier muss das Standby-System über eigene Redo-Logs verfügen.

In der zweiten Variante schreibt der Log-Writer-Prozess (LGWR) die Daten bereits vorher nicht nur in die Redo-Logs der Primary-Datenbank, sondern zugleich auch in die der sekundären Datenbank. Deshalb braucht in diesem Fall die Standby-Seite unbedingt eigene Redo-Logs. Sie werden zuerst mit einem eigenen »arc0«-Prozess archiviert und dienen anschließend wie gehabt als Informationsquelle über jene Änderungen an Daten, die auf dem sekundären System nachzuvollziehen sind.

Für diese Variante gibt es seit Oracle 10g zusätzlich das Real-Time-Apply-Feature. Ist es aktiv, holt der Recovery-Manager die Daten nicht aus den archivierten Logdateien, sondern verarbeitet sie direkt, sobald sie eintreffen. Das minimiert zeitlich bedingte Datenunterschiede.

Zehn Schritte zum Ziel

Ein Standby-System lässt sich in den folgenden zehn Schritten konfigurieren. Eine wichtige Voraussetzung dafür ist, dass die Datenbank im »ARCHIVELOG«-Mode läuft. Der Befehl »archive log list« verrät, ob dies der Fall ist. Falls nicht, setzt man den Parameter »LOG_ARCHIVE_START« im Initialisierungsfile »init.ora« auf »true« und rebootet anschließend die Datenbank, wie Listing 1 demonstriert.

01 SQL> shutdown
02 SQL> startup mount
03 Total System Global Area  188743680 bytes
04 Fixed Size                   778036 bytes
05 Variable Size             162537676 bytes
06 Database Buffers           25165824 bytes
07 Redo Buffers                 262144 bytes
08 Database mounted.
09 SQL> alter database archivelog;
10 Database altered.
11 SQL> alter database open;

Eine weitere wichtige Voraussetzung ist die korrekte Belegung der Parameter »DB_NAME« und »DB_UNIQUE_NAME«. »DB_NAME« sollte auf allen Datenbanken (primäre und Standby-Datenbank) den gleichen Wert haben. Ganz im Gegensatz dazu muss »DB_UNIQUE_NAME« jeweils verschiedene Namen enthalten. Wichtig ist außerdem, dass der Wert von »REMOTE_LOGIN_PASSWORDFILE« auf »EXCLUSIVE« oder »SHARED« gesetzt ist. Alle weiteren Parameter zeigt Tabelle 2.

Oracle geht normalerweise davon aus, dass die Verzeichnisstrukturen beider Server identisch sind. Wenn das nicht der Fall ist, stehen die Parameter »LOG_FILE_NAME_CONVERT« und »DB_FILENAME_CONVERT« zur Verfügung, um Oracle auf die Verschiedenheiten aufmerksam zu machen.

In dem folgenden Beispiel konfiguriert der Admin einige Parameter in der »initSID.ora«, und zwar auf beiden Systemen, erzeugt danach ein neues Control-File für die Standby-Datenbank am Primary-System, erweitert zum Schluss die Konfiguration des Oracle Net Service für die neue Umgebung und nimmt sie in Betrieb.

1. Der erste Schritt erstellt ein Backup der zukünftigen Primary-Datenbank. Das kann entweder durch User Managed Backup oder durch Oracles RMAN geschehen [2].

2. Der zweite Schritt passt die notwendigen Parameter im Initialization-File der Primary-Datenbank an (Listing 2). Tabelle 2 erläutert alle beteiligten Parameter. Falls die Verzeichnisstrukturen nicht identisch sind, sind die bereits erwähnten Parameter dafür wie in Listing 3 zu konfigurieren. An erster Stelle steht der Pfad der Logdateien und Daten-Files der Primary- gefolgt vom entsprechenden Pfad der Standby-Datenbank.

01 LOG_ARCHIVE_CONFIG='DG_CONFIG=(wien,berlin)'
02 LOG_ARCHIVE_DEST_1=
03    'LOCATION=/data/arch/
04    VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
05    DB_UNIQUE_NAME=wien'
06 LOG_ARCHIVE_DEST_2=
07    'SERVICE=berlin REOPEN=60 MAX_FAILURE=3 LGWR SYNC
08    VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
09    DB_UNIQUE_NAME=berlin'
10 FAL_SERVER=wien
11 FAL_CLIENT=berlin
12 STANDBY_FILE_MANAGEMENT='AUTO'
13 LOG_ARCHIVE_DEST_STATE_1='ENABLE'
14 LOG_ARCHIVE_DEST_STATE_2='ENABLE'

01 LOG_FILE_NAME_CONVERT='/data/oracle/oradata/wien/',
02 '/db/oracle/10/oradata/berlin/'
03 
04 DB_FILE_NAME_CONVERT='/data/oracle/§oradata/wien/',
05 '/db/oracle/10/oradata/berlin/'

3. Der dritte Schritt ist die Erzeugung eines Control-File auf dem Primary-System für die Standby-Datenbank mit dem Kommando »ALTER DATABASE CREATE STANDBY CONTROLFILE AS \’/tmp/stdby.ctl\’;«.

4. Nun geht\’s um die Initialization-Files für die Standby-Seite. Hier wird ebenfalls auf dem Primary-System ein File erzeugt: »CREATE PFILE=\’/tmp/initberlin.ora\’ FROM SPFILE;«.

5. Nachdem der Admin die Daten-Files, das erzeugte Control-File, die Online Redo-Logfiles und das Initialisierungs-File (in diesem Beispiel »initberlin.ora«) auf das Standby-System transferiert hat, erzeugt er die Passwortdatei »orapwd file=orapwstan password=system entiers=10 force=y«.

6. Nun passt er die Initialisierungsdatei »initberlin.ora« an, die am Primary erzeugt wurde und normalerweise in »/dbs/« liegt, wie in Listing 4 zu sehen ist.

01 LOG_ARCHIVE_DEST_1=
02 'LOCATION=/db/arch/
03 VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
04 DB_UNIQUE_NAME=berlin'
05 
06 LOG_ARCHIVE_DEST_2=
07 'SERVICE=wien REOPEN=60 MAX_FAILURE=3 LGWR SYNC
08 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
09 DB_UNIQUE_NAME=wien'

7. Anschließend soll das Primary-System mit der Standby-Seite kommunizieren können. Nachdem der »Net Service Name« sowohl in der Standby- als auch in der Primary-Datenbank konfiguriert worden ist, sollte die Datei »tnsnames.ora« so aussehen, wie Listing 5 beispielhaft zeigt.

01 WIEN  =
02   (DESCRIPTION =
03     (ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521))
04     (CONNECT_DATA =
05       (SERVICE_NAME = wien)
06       (SERVER = DEDICATED)
07     )
08   )
09 
10 BERLIN =
11   (DESCRIPTION =
12     (ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521))
13     (CONNECT_DATA =
14        (SERVICE_NAME = berlin)
15        (SERVER = DEDICATED)
16     )
17   )

8. Mit »STARTUP OPEN READ ONLY;« startet die Standby-Datenbank im Read-only-Modus. Falls das zur Fehlermeldung »ORA-16004: backup database requires recovery« führt, in Verbindung mit »ORA-01152: file 1 was not restored from a sufficiently old backup« und »ORA-01110«, dann hilft ein Standby-Recovery. Dazu braucht das Standby-System die archivierten Redo-Logdateien, die in diesem Fall der Admin erst von Hand von der Primary- auf die Standby-Datenbank kopieren muss. Danach setzt er mit »RECOVER STANDBY DATABASE;« das Recovery in Gang.

9. Der vorletzte Schritt am Standby-System erzeugt die Redo-Logdateien und startet den Redo-Apply-Prozess. Das ist notwendig, weil im vorliegenden Beispiel das »LGWR«-Attribut eingeschaltet ist, das Standby-System also Redo-Logs braucht, die die Gegenseite beschreiben kann:

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('pfad/zu/dem/redol01.log') SIZE 10M;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;.

Die Anweisung »USING CURRENT LOGFILE« wird Oracle veranlassen den Redo-Apply in Echtzeit zu starten. Um den Prozess in den Hintergrund zu schicken und wieder zum SQL-Prompt zu gelangen, müsste der Benutzer »DISCONNECT FROM SESSION« hinzufügen.

10. Schließlich testet man alles mit einen »Switch Logfile«-Kommando auf der Primary-Datenbank. Dieser Befehl sollte die Redo-Logdatei lokal archivieren und eine Kopie davon an das Standby-System senden. Die View »V bietet die Möglichkeit, nachzusehen, ob irgendwelche Fehlermeldungen aufgetreten sind, und ist auch sonst sehr hilfreich bei Problemen: »SELECT status, error FROM V WHERE dest_id = 2;«. Das Feld »error« gibt dann einen Hinweis auf mögliche Stolpersteine. Werden alle Parameter wie in dem Beispiel gesetzt, sollten keine Fehler auftauchen.

Sekundant

Wer das Standby-System nicht allein passiv auf den Fehlerfall warten lassen, sondern zwischendurch für Hilfsarbeiten einspannen will, der muss es zuerst in den Read-only-Modus versetzen. Zuerst muss man dazu den Redo-Apply-Prozess mit »ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;« stoppen, danach die Standby-Datenbank im Nur-Lese-Modus starten: »STARTUP OPEN READ ONLY;«. Nach dem Ende der Unterstützungsleistungen für das Primärsystem, spielt der Datenbankadministrator die dort in der Zwischenzeit angefallenen Logdaten wieder in die Standby-Datenbank ein.

Nie mehr Nachtarbeit

Wartungsarbeiten werden häufig auf die Nachtstunden oder Wochenenden gelegt, weil Auszeiten nicht selten unvermeidlich sind. Mit dem Switchover-Feature von Data Guard lässt sich das weitgehend vermeiden. Switchover ist ein Mechanismus, der jederzeit den Rollentausch ermöglicht.

Wichtig beim Switchover ist der Wert des Feldes »SWITCHOVER_STATUS« in »V. Er darf nicht den Wert »NOT ALLOWED« haben. Außerdem darf kein User mehr eingeloggt sein. Die Sessions anderer User kann der Admin entweder manuell oder durch den Switchover-Befehl beenden:

ALTER DATABASE COMMIT TO SWITCHOVER TO U PHYSCAL STANDBY WITH SESSION SHUTDOWN;

Beim nächsten Start wird die Primary-DB als Standby-System tätig: »SHUTDOWN IMMEDIATE; STARTUP MOUNT;«. Anschließend teilt auf Standby-Seite der Befehl »ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;« Oracle mit, dass nach dem Restart die Standby-DB als Primärsystem fungieren soll. Falls die sekundäre Datenbank im Maximum Protection Mode läuft, sollte der Admin sie vor Beginn des Switchover-Prozesses mit dem Befehl »ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;« in den Maximum-Performance-Modus setzen.

Mind the Gap

Ein Failover bezeichnet im Gegensatz zum Switchover den Rollenwechsel nach einem unvorhergesehenen Ausfall. Dann kann eine Lücke (Gap) zwischen beiden Systemen entstehen, falls nicht der Maximum Protection Mode eingeschaltet war. Kommt es zu einer solchen Diskrepanz, was die View »V zeigt, dann gilt es, diese Unterschiede wieder auszugleichen.

Dazu transferiert der Admin die Logdateien zwischen der niedrigsten und der höchsten in der View angegebenen Sequenznummer vom primären händisch auf das Standby-System und registriert sie dort mit »ALTER DATABASE REGISTER LOGFILE Filename;«. Danach beendet er den Recovery-Prozess auf der sekundären Datenbank mit

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

und erklärt die Standby-Datenbank mit folgendem Befehl zur neuen primären Datenbank:

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

Informationen über die Aktivitäten des Data Guard werden im Alert Log und in den dynamischen Views eingetragen. Im Alert Log finden sich unter anderem alle Fehlermeldungen von Prozessen, die für Data Guard arbeiten, etwa »LGWR«, »ARC0« oder »RFS«. Die Abfrage

SELECT PROCESS, STATUS, THREAD#, SEQUENCE#,U 
BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;

liefert unter anderem Informationen über die Aktivität des Log-Apply-Prozesses auf der Standby-Seite. Um die Synchronisationsstufe auf der sekundären Datenbank zu erfragen, eignet sich:

SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# FROM V$ARCHIVE_DEST_STATUS;

Die Abfrage »SELECT RECOVERY_MODE FROM V WHERE DEST_ID=2 ;« stellt fest, ob das Real-Time-Feature in der Standby-Datenbank aktiviert ist. Andere Views, etwa »V, die alle empfangenen archivierten Redo-Files listet, oder »V, »V, »V, und »V liefern ebenfalls wertvolle Informationen.

Seit Version 9i sind Konfiguration, Kontrolle, Switchover und Failover auch über eine grafische Oberfläche zu bedienen, den Data Guard Broker, der Bestandteil des Enterprise Managers ist.

Fazit

Der Data Guard ist eine ausgereiftes Produkt, das eine hohe Verfügbarkeit für Oracle-Datenbanken garantiert und sich als Bestandteil von Oracle 10g mit überschaubarer Administration im Unterschied zu manch anderer High-Availability-Lösung auch für kleinere und mittlere Betriebe eignet. (jcb)