Erschienen in der Zeitschrift der Deutschen ORACLE Anwendergruppe "DOAG News", Ausgabe Q4/2003

Die Standby-Datenbank:
Data Guard aus Kundensicht (Teil III)

Die vorangegangenen Artikel dieser Reihe beschäftigten sich ausführlich mit dem Aufbau und Betrieb einer physikalischen Standby-Datenbank, bis einschließlich Oracle 9i. In dieser Ausgabe wollen wir uns nun den Aufbau einer logischen Standby-Datenbank anschauen. Auch hier werden alle Schritte zunächst mit SQL*Plus, also ohne GUI, durchgeführt.

Bevor wir die logische Standby-Datenbank aufbauen, wollen wir uns zunächst anschauen, wo es innerhalb der Architektur Gemeinsamkeiten bzw. Unterschiede zur physikalischen Standby-Datenbank gibt.

Transport der Redo Informationen

Der Transport der Redo Informationen unterscheidet sich bei einer logischen Standby-Datenbank nicht grundsätzlich von dem bei einer physikalischen Standby-Datenbank. Auch können sowohl der ARCH oder der LGWR Prozess genutzt werden. Allerdings gibt es innerhalb der logischen Standby-Datenbank keine Standby RedoLog Dateien. Der LGWR schreibt direkt in archivierte RedoLog Dateien, und zwar in das Verzeichnis, das über den Parameter standby_archive_dest angegeben wird.

Unterbrechungen der Übertragung werden auch bei der logischen Standby-Datenbank automatisch erkannt und die fehlenden RedoLog Dateien werden automatisch nachgezogen. Bei der logischen Standby-Datenbank braucht dazu jedoch kein FAL Server angegeben zu werden.

Einpflegen der Informationen in die Datenbank

Der Unterschied zwischen den beiden Standby Systemen liegt in der Art und Weise, wie die Informationen des Redo Stroms in die Datenbank eingepflegt werden. Bei der physikalischen Standby-Datenbank wird ein Recovery der Datenbank vorgenommen. Währenddessen steht die Datenbank den Benutzern nicht zur Verfügung.

Das Einpflegen der Informationen aus dem Redo Strom in die logische Standby-Datenbank geschieht jedoch auf einem ganz anderen Weg: Mit Hilfe des LogMiners werden die SQL Statements der Produktionsdatenbank rekonstruiert. Anschließend werden die Statements über eine sogenannte SQL Apply-Engine in der logischen Standby-Datenbank nachgefahren. Die logische Standby-Datenbank ist dabei die ganze Zeit geöffnet und steht den Benutzern zur Verfügung. Da bei der logischen Standby-Datenbank SQL Statements ausgeführt werden, werden selbstverständlich auch Redo Informationen erzeugt.

Keine 1:1 Kopie

Die Verwendung des LogMiners und der SQL Apply-Engine bringt jedoch eine Einschränkung in den unterstützten Datentypen mit sich.

Unterstützt werden:

• CHAR, NCHAR, VARCHAR2, VARCHAR
• NUMBER
• DATE, TIMESTAMP
• INTERVAL
• RAW
• CLOB, BLOB

Nicht unterstützt werden derzeit NCLOB, LONG (RAW), BFILE, ROWID sowie durch den Benutzer definierte Datentypen.

Aus diesen Gründen ist die logische Standby-Datenbank, im Gegensatz zur physikalischen Standby-Datenbank, keine 1:1 Kopie der Produktionsdatenbank und kann somit auch nicht zu Backup Zwecken genutzt werden.

Aufbau einer logischen Standby-Datenbank

Nach dieser Einführung wollen wir jetzt eine logische Standby-Datenbank aufbauen. Das grundsätzliche Vorgehen wird in Abbildung 1 dargestellt.

Abb. 1: Installation einer logischen Standby-Datenbank.

Im Gegensatz zur physikalischen Standby-Datenbank wird hier keine Standby-Controldatei benötigt, sondern eine normale Backup-Controldatei. Doch jetzt die Schritte im Einzelnen:

1. Schritt auf der Produktionsdatenbank

Nach dem Entschluss, eine logische Standby-Datenbank aufzubauen, sollten wir als erstes das Skript ?/rdbms/admin/catlsby.sql laufen lassen, da es nicht von catalog bzw. catproc aufgerufen wird. Dieses Skript füllt die DataDictionary Views, die beim Betrieb einer logischen Standby-Datenbank sinnvoll sind, mit Leben. Die Namen dieser Views beginnen mit DBA_LOGSTDBY.

Zur Ermittlung eventuell vorhandener, nicht unterstützter Datentypen und Objekte wird das Kommando select * from dba_logstdby_unsupported abgesetzt. Hier werden Eigner, Tabellennamen, Spaltenamen und Datentypen zurückgegeben. Jede hier angegebene Tabelle wird beim Log Apply auf der Standby-Datenbank automatisch ausgenommen.

Anschließend untersuchen wir mit der Abfrage der View dba_logstdby_not_unique, ob unsere Datenbank Tabellen ohne Primary Key oder Not-Null Constraints besitzt. Gibt es solche Tabellen in unserer Datenbank, sollten wir für diese einen Primary Key definieren.

2. Schritt auf der Produktionsdatenbank

Als nächstes überprüfen wir, ob die Produktionsdatenbank im ArchiveLog Modus läuft. Läuft die Datenbank nicht in diesem Modus, schalten wir ihn in der Mount-Phase ein.

Eine logische Standby-Datenbank kann ausschließlich Daten mit supplemental logging verarbeiten. Normalerweise kommen aber im Redo Strom supplemental und nonsupplemental log Daten vor. Daher ist auf jeden Fall mit dem Kommando ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS; die Funktion "supplemental logging" einzuschalten.

Für jede vorher angelegte physikalische Standby-Datenbank unserer Konfiguration ist dieses Kommando ebenfalls abzusetzen, damit der Switchover sauber funktioniert. Danach müssen die beiden Spalten SUPPLEMENTAL_LOG_DATA_PK und SUPPLEMENTAL_LOG_DATA_UI der View v$database jeweils den Wert Y zurückgeben.

Der init<SID>.ora Parameter log_parallelism steht standardmäßig auf 1. Sollte dieser Parameter bei der Produktionsdatenbank einen Wert > 1 haben, ist er auf den Standard zurückzusetzen.

3. Schritt auf der Produktionsdatenbank

Der folgende Schritt ist nur erforderlich, wenn ein Switchover stattfinden soll. Eine logische Standby-Datenbank benötigt eine Reihe von Tabellen, die in den Schemata der user sys und system definiert sind.

Einige dieser Tabellen können sehr schnell sehr groß werden, daher sollten sie in einen separaten Tablespace gelegt werden. Wir legen also einen neuen Tablespace mit beispielsweise dem Namen logminer an. Anschließend wenden wir die Prozedur DBMS_LOGMNR_D.SET_TABLESPACE an.

EXECUTE DBMS_LOGMNR_D.SET_TABLESPACE(’logminer’);

Weitere Anpassungen

Damit sind die vorbereitenden Schritte auf der Produktionsdatenbank abgeschlossen. Wir machen jetzt ein offline Backup der Datenbank und mounten diese anschließend, um eine Backup-Controldatei zu erzeugen. Außerdem ermitteln wir die aktuelle Checkpoint Change Nummer und können danach die Datenbank wieder öffnen. (Es geht auch mit einem online Backup.)

Die wichtigste Änderung der init<SID>.ora auf dem Standby System ist, den Parameter STANDBY_ARCHIVE_DEST hinzuzufügen. Eventuell sind noch die Pfade zu den Controldateien und der ARCHIVE_LOG_DEST_n Parameter anzupassen. Weiterhin ist die Passwortdatei auf das neue System zu kopieren.

Mounten der logischen Standby-Datenbank

Jetzt können wir die logische Standby-Datenbank zunächst mounten. Sollten sich die Pfade zu den Datenbank Dateien und RedoLog Dateien geändert haben, so müssen diese jetzt angepasst werden. Die von der physikalischen Standby Datenbank bekannten Parameter DB_FILE_NAME_CONVERT und LOG_FILE_NAME_CONVERT funktionieren bei der logischen Standby-Datenbank nicht.

Da wir in unserem Backup nur die Datenbank Dateien berücksichtigt haben, müssen wir die online RedoLog Dateien mit dem Kommando ALTER DATABASE CLEAR LOGFILE GROUP n; neu anlegen.

Recovern

Danach recovern wir unsere zukünftige logische Standby-Datenbank mit der BACKUP CONTROLFILE Option bis zur vorher gemerkten Checkpoint Change Nummer:

RECOVER DATABASE UNTIL CHANGE <SCN> USING BACKUP CONTROLFILE;

Anschließend müssen wir die Datenbank mit der RESETLOGS Option öffnen. Damit im geöffneten Zustand keine Änderungen an den Daten vorgenommen werden können, setzen wir folgende Kommados ab:

ALTER DATABASE GUARD ALL;
ALTER DATABASE OPEN RESETLOGS;
SHUTDOWN IMMEDIATE;

DBID und Datenbankname

Im nächsten Schritt ändern wir die DBID und den Datenbanknamen unserer logischen Standby-Datenbank. Dazu benutzen wir das Kommadozeilen-Tool nid. Zunächst ist jedoch unsere Datenbank in die Mount Phase zu versetzen. Danach gehen wir zurück auf die Shell Ebene und setzen folgendes Kommando ab:

nid target=sys/change_on_install dbname=log1

Der hier angegebene Datenbankname ist der neue Name der logischen Standby-Datenbank. Unsere Datenbank hat nun eine neue DBID und einen neuen Datenbanknamen. Der neue Name bedingt natürlich auch eine entsprechende Änderung der init<SID>.ora, bzw. der spfile. Außerdem ist die Passwortdatei neu anzulegen.

Auch jetzt öffnen wir die Datenbank wieder mit der RESETLOGS Option und legen ein neues Tempfile für den temporären Tablespace an.

Im Weiteren gehen wir davon aus, dass die Oracle Net Konfiguration steht und die Instanzen sich gegenseitig "sehen" können.

Übertragen der Redo Informationen

Wir können jetzt also mit
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=’SERVICE=log1, LGWR’;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
dafür sorgen, dass die Redo Informationen zum Standby System übertragen werden. Dabei schreibt der LGWR direkt in die vorher in der init<SID>.ora der logischen Standby-Datenbank definierte STANDBY_ARCHIVE_DEST.

Mit dem Kommando ALTER DATABASE REGISTER LOGICAL LOGFILE ‘/oracle/admin/log1/ora1_1_139.arc’ erklären wir der logischen Standby-Datenbank, wo die archivierten RedoLog Dateien liegen, deren Inhalte in die Datenbank eingepflegt werden sollen. Die angegebene Sequenz Nummer ist die der ersten, archivierten RedoLog Datei nach dem offline Backup.

SQL Apply

Damit die logische Standby-Datenbank mit dem SQL Apply beginnen kann, muss zunächst auf der Produktionsdatenbank ein LogMiner Dictionary aufgebaut und auf die logische Standby-Datenbank übertragen werden. Dies geschieht mit dem Aufruf EXECUTE DBMS_LOGSTDBY.BUILD; auf der Produktionsdatenbank. Die LogMiner Dictionary Informationen werden in den Redo Strom eingebettet.

Mit Abfragen auf die V$ARCHIVED_LOG
SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN=’YES’;
SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END=’YES’;
können wir sehen, in welche RedoLog Dateien die Dictionary Informationen hinein gespeichert wurden.

Da die Übertragung der RedoLog Dateien auf das Standby System bereits eingeschaltet ist, befinden sich die Dictionary Informationen auch auf dem Standby System.

Mit dem Kommando ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL; beginnt das SQL Apply. Dieses Kommando ist auf der logischen Standby-Datenbank nur einmal abzusetzen. Soll das Nachfahren der Transaktionen gestoppt werden und anschließend wieder gestartet werden, geschieht dies wie folgt:

ALTER DATABASE STOP LOGICAL STANDBY APPLY;
ALTER DATABASE START LOGICAL STANDBY APPLY;

Da nach einem Neustart der logischen Standby-Datenbank das Nachfahren der Transaktionen nicht automatisch gestartet wird, ist es mit ALTER DATABASE START LOGICAL STANDBY APPLY; nach dem Öffnen der Datenbank manuell zu starten.

Den grundsätzlichen Ablauf zwischen Produktionsdatenbank und logischer Standby-Datenbank zeigt Abbildung 2.

Abb. 2: Ablauf zwischen Produktion und Standby.

Über verschiedene Views lässt sich der Erfolg und Fortschritt des SQL Apply verfolgen (siehe Abbildung 3).

Hier ist zu sehen, bis zu welcher SCN die Transaktionen nachgefahren wurden, und welches die letzte bekannte SCN ist. Hält man beispielsweise das SQL Apply an, so ändert sich zwar die Spalte NEWEST_SCN, nicht aber der Wert der Spalte APPLIED_SCN.

Mit Hilfe der beiden oben genannten Spalten lässt sich über die View DBA_LOGSTDBY_LOG ermitteln, welches die aktuelle RedoLog Datei ist und welche noch nachgefahren werden muss. Außerdem ist hier auch zu sehen, in welchen Dateien die Dictionary-Informationen liegen (siehe Abbildung 4).

In der View DBA_LOGSTDBY_EVENTS werden wichtige Ereignisse wie beispielsweise das Starten oder Anhalten des Log Apply protokolliert. Aber auch ein erfolgreiches DDL Kommando wird protokolliert.

select STATUS from dba_logstdby_events;
ORA-16204: DDL successfully applied

Möchte man wissen, was sich dahinter verbirgt, hilft ein Blick in die alert<SID>.log Datei:

LOGSTDBY event: ORA-16204:
DDL successfully applied
LOGSTDBY stmt: create table ak2 (
s1 number,
s2 varchar2(25),
constraint ak2_pk primary key (s1))

Was ist mit Logical Data Guard nun möglich?

Vergleichen wir noch mal das, was wir jetzt können, mit dem, was im ersten Artikel dieser Reihe an Forderungen aufgestellt wurde.

• Das Offline Backup über die logische Standby-Datenbank ist nicht möglich.
• Eine zeitverzögerte Einspielung (Delay) der RedoLog-Dateien ist ohne großen Aufwand möglich.
• Ein Tausch der Funktionalität zwischen Standby-Datenbank und Original-Datenbank (Switchover) ist möglich.
• Es ist möglich, während des Nachfahrens der SQL Statements lesend auf die logische Standby-Datenbank zuzugreifen. Weiterhin lassen sich an der logischen Standby-Datenbank Änderungen, wie beispielsweise zusätzliche Indizes, vornehmen.

Im nächsten Teil dieser Reihe werden wir uns mit dem Package dbms_logstdby beschäftigen und den Switchover auf die logische Standby-Datenbank durchführen. Darüber hinaus schauen wir uns an, wie wir mit dem DataGuard Broker die Administration vereinfachen.

Für Fragen, Anregungen und weitere Informationen steht Ihnen der Autor jederzeit gerne zur Verfügung.

Andreas Kother (info@ordix.de).