Die Standby-Datenbank

579869046
Die Standby-Datenbank: Data Guard aus Kundensicht (Teil IV)
Autor: Andreas Kother, ORDIX AG
In der letzten Ausgabe der DOAG News haben wir mit SQL*Plus eine logische Standby
Datenbank aufgebaut. In diesem Artikel schauen wir uns an, wie der Switchover funktioniert
und was sich mit dem Data Guard Broker vereinfachen lässt. Darüber hinaus setzen wir das
Package dbms_logstdby ein, um den Betrieb der logischen Standby Datenbank zu optimieren.
Switchover mit SQL*Plus
Der Switchover einer physikalischen Datenbank bedingt das Herunterfahren und Neustarten der
beteiligten Datenbanken. Der Switchover bei einer logischen Standby Datenbank erfolgt zur Laufzeit
der beteiligten Systeme. Um den Switchover jedoch durchführen zu können, sind zusätzlich zu den in
Teil III vollzogenen Schritten noch ein paar Kleinigkeiten zu erledigen.
Datenbank-Links anlegen
Zunächst müssen wir sowohl auf der Produktions- als auch auf der logischen Standby Datenbank
jeweils einen Datenbank-Link auf das andere System anlegen.
Auf dem Standby System:
CREATE DATABASE LINK prod CONNECT TO ak IDENTIFIED BY otto
USING 'ora1';
Auf dem Produktionssystem:
CREATE DATABASE LINK stdby CONNECT TO ak IDENTIFIED BY otto
USING 'log1';
Diese Links werden beim Switchover benötigt, um Informationen zwischen den Datenbanken
auszutauschen.
Der eigentliche Switchover lässt sich in drei Phasen unterteilen: Vorbereitung, Durchführung und
Kontrolle.
Vorbereitung
Während der Vorbereitung überprüfen wir mit Hilfe der Views V$ARCHIVED_LOG und
V$ARCHIVE_DEST_STATUS, ob es beim Transport der Log Dateien zu Problemen gekommen ist.
Sollte es beim Switchover zu Problemen kommen, so ist es hilfreich, auf der Produktionsdatenbank
die Sequenz Nummer der aktuellen RedoLog Datei zu kennen (V$LOG) und auf dem Standby System
die Sequenz Nummer derjenigen Log Datei, aus der gerade Transaktionen nachgefahren werden
(DBA_LOGSTDBY_LOG, DBA_LOGSTDBY_PROGRESS). Weiterhin sind alle aktiven Sessions an
der Produktionsdatenbank zu beenden.
Durchführung
Der eigentliche Switchover besteht aus drei Schritten:
Schritt 1:
Auf dem Produktionssystem wird der Switchover mit folgendem Kommando eingeleitet:
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
Schritt 2:
Anschließend sorgen wir mit ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=DEFER; dafür,
dass das Archivieren auf die bisherige Standby Datenbank beendet wird.
Auf dem Standby System sollte die Abfrage
SELECT ‘FOUND’ FROM DBA_LOGSTDBY_EVENTS
WHERE EVENT_TIME = ( SELECT MAX(EVENT_TIME) FROM DBA_LOGSTDBY_EVENTS )
Seite 1 von 5
579869046
AND STATUS_CODE = 16128;
das Ergebnis FOUND zurückgeben. Alternativ können wir ORA-16128 auch in der letzten Zeile der
alert Datei der Standby Datenbank finden.
Schritt 3:
Vor dem Switchover schalten wir mit einem ALTER SYSTEM Kommando die Archivierung auf die
neue Standby Datenbank ein.
Mit dem Kommando
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL PRIMARY;
wird die bisherige Standby Datenbank zur Produktionsdatenbank.
Abgeschlossen wird der Vorgang durch das Kommando
ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY stdby;
Kontrolle
Mittels der View V$ARCHIVE_DEST und V$ARCHIVE_DEST_STATUS kontrollieren wir, ob die
Archivierung der neuen Produktionsdatenbank wie vorgesehen läuft. Weiterhin benutzen wir wieder
die Views DBA_LOGSTDBY_LOG und DBA_LOGSTDBY_PROGRESS, um uns vom Fortschritt des
Log Apply auf dem neuen Standby System zu überzeugen.
Interessante Prozeduren im Package dbms_logstdby
Das Package dbms_logstdby bietet eine Anzahl interessanter Prozeduren für verschiedene Zwecke
an. So lassen sich beispielsweise mit der Prozedur dbms_logstdby.skip Filter definieren, so dass DDLund/oder DML Kommandos für bestimmte Tabellen in der logischen Standby Datenbank nicht
ausgeführt werden. Darüber hinaus lassen sich auch Kommandos wie create oder alter tablespace
herausfiltern.
Ist auf dem Produktionssystem das Attribut DELAY bei dem Parameter LOG_ARCHIVE_DEST_n
gesetzt, so können wir das mit der Prozedur dbms_logstdby.apply_unset übersteuern.
Eine weitere interessante Prozedur ist dbms_logstdby.apply_set mit dem Parameter
transaction_consistency. Hierbei gilt es, drei Fälle zu unterscheiden, die sich einerseits auf die
Verarbeitungsgeschwindigkeit und andererseits auf die Konsistenz auswirken.
Full Consistency:
Hierbei werden die Transaktionen in der Reihenfolge der sogenannten commit SCN ausgeführt.
Read Only:
Die Transaktionen werden im Normalfall unsortiert ausgeführt. In regelmäßigen Abständen wird die
richtige Reihenfolge jedoch wiederhergestellt. Dies bringt gegenüber dem ersten Fall einen
Geschwindigkeitsvorteil.
None:
Hierbei werden alle Transaktionen unsortiert ausgeführt. Daraus resultiert die beste
Verarbeitungsgeschwindigkeit. Dies kann jedoch schon mal zu inkonsistenten Ergebnissen bei
Leseoperationen führen.
Der Standardwert ist Full Consistency. Zwar arbeitet die Standby Datenbank die Transaktionen dabei
am langsamsten ab, jedoch erhalten wir bei lesenden Zugriffen auf die Datenbank immer konsistente
Ergebnisse. Beim Parameter Read Only erhalten wir immer Lesekonsistenz bezüglich der letzten
bekannten, konsistenten SCN.
Der Data Guard Broker
Abschließend wollen wir uns nun mit dem Data Guard Broker beschäftigen. Da wir bereits einen
erfolgreichen Switchover vollzogen haben, sind fast alle Voraussetzungen zum Einsatz des Brokers
erfüllt. Was noch zu tun bleibt, ist Folgendes:
1. Der Initialisierungsparameter DG_BROKER_START muss auf TRUE gesetzt werden. Dies führt
zum Start des DMON Prozesses beim startup der Datenbanken.
Seite 2 von 5
579869046
2. Die Datenbanken müssen zwingend mit spfile betrieben werden, damit der Broker eventuell
erforderliche Änderungen an den Initialisierungsparametern vornehmen kann.
3. Der Data Guard Broker meldet sich als sysdba an. Damit das auch remote funktioniert, sind die
beteiligten Datenbanken mit einer Passwortdatei zu versehen.
Anlegen einer Konfiguration
Ziel ist es nun, mit dem dgmgrl eine Konfiguration, bestehend aus unserer Produktionsdatenbank und
der logischen Standby Datenbank, anzulegen und anschließend einen Switchover durchzuführen.
Zunächst verbinden wir uns nach dem Start des dgmgrl mit der aktuellen Produktionsdatenbank:
DGMGRL> connect sys/change_on_install
Connected.
Anschließend legen wir eine Konfiguration an:
DGMGRL> create configuration 'ak' as
> primary site is 'log'
> resource is 'log_db'
> hostname is 'fiesta'
> instance name is 'log1'
> service name is 'log1'
> site is maintained as logical;
Configuration "ak" added with primary site "log"
Database resource "log_db" added.
Dieser Konfiguration fügen wir die aktuelle Standby Datenbank hinzu:
DGMGRL> create site 'prod'
> resource is 'prod_db'
> hostname is 'fiesta'
> instance name is 'ora1'
> service name is 'ora1'
> site is maintained as logical;
Site "prod" added to configuration.
Database resource "prod_db" added.
Danach geben wir mit enable configuration; die Konfiguration frei.
Mit show configuration verbose können wir uns den aktuellen Zustand unserer Konfiguration
anzeigen lassen:
DGMGRL> show configuration verbose;
Configuration
Name:
'ak'
Enabled:
'yes'
Default state:
'ONLINE'
Intended state:
'ONLINE'
Protection Mode: 'MaxPerformance'
Number of sites: 2
Sites:
Primary Site: log
Standby Site: prod
Current status for "ak":
Enabled.
Durchführen des Switchovers
Bevor wir nun den Switchover mit dem dgmgrl durchführen, sollten wir uns mit show resource
verbose 'log_db'; und show resource verbose 'prod_db'; den jeweiligen Status der
beteiligten Datenbanken anzeigen lassen. Die Ausgabe der beiden Kommados sollte in den letzten
Zeilen etwa wie folgt aussehen:
.
.
Seite 3 von 5
579869046
.
Properties for 'STANDBY' state:
DEFAULT_STATE
= 'LOGICAL-APPLY-ON'
EXPLICIT_DISABLE = 'no'
REQUIRED
= 'yes'
Current status for "log_db":
SUCCESS
Der abschließende Switchover sieht folgendermaßen aus:
DGMGRL> switchover to 'prod';
Performing switchover NOW. Please wait...
Switchover succeeded. New primary is "prod"
Die Vorteile des Data Guard Managers
Doch nicht nur der Switchover geht einfacher vonstatten, auch beim Startup der logischen Standby
Datenbank brauchen wir uns nicht mehr manuell um das Neustarten des Log Apply zu kümmern. Dies
geschieht ebenfalls automatisch. Mit dem Data Guard Manager, welcher in den Enterprise Manager
integriert ist, läuft es letztendlich ähnlich ab, wobei der Switchover mit dem Switchover Wizard
durchgeführt wird. Das funktioniert natürlich auch für physikalische Standby Datenbanken.
Fazit
Zu Begin unserer Artikelreihe haben wir eine Liste mit Forderungen formuliert, die hier noch einmal
kurz wiederholt werden sollen:
1. Backup Konzept
2. Hochverfügbarkeitslösung
3. Möglichkeit eines externen Reportings
4. Delay
5. Switchover
zu 1. Das Offline Backup über eine physikalische Standby-Datenbank ist seit Oracle 7.3 möglich. Eine
logische Standby Datenbank ist für ein solches Konzept ungeeignet.
zu 2. Für den K-Fall ist eine physikalische Standby Datenbank auf jeden Fall eine gute Lösung, zumal
sich seit Oracle 9i die Gefahr des Datenverlusts verringert hat. Enthält die Produktionsdatenbank nur
unterstützte Datentypen, kann hierfür auch eine logische Standby Datenbank genutzt werden.
zu 3. Mit einer physikalischen Standby Datenbank sind Reporting und gleichzeitiges Nachfahren von
Transaktionen nicht möglich. Hier gibt es nur die Möglichkeit, entweder zu recovern oder die
Datenbank im Read-Only Modus zu öffnen. Eine logische Standby Datenbank bietet aufgrund der
anderen „Recovery“ Methode jedoch die Möglichkeit, beides gleichzeitig zu tun.
zu 4. Mit Oracle 8.1.7 gab es dafür eine skriptbasierte Lösung. Mit Oracle 9i ist ein zeitverzögertes
Nachfahren der RedoLog Dateien ohne zusätzliche Skripte möglich.
zu 5. Der Switchover ist mit Oracle 9i möglich. Bei einer physikalischen Standby Datenbank ist ein
Switchover ohne Einschränkungen bezüglich der unterstützten Datentypen möglich. Bei der logischen
Standby Datenbank werden noch nicht alle Datentypen unterstützt, was aber eher eine Schwäche des
LogMiners aufzeigt. Mit dem Data Guard Broker besteht der Switchover letztlich nur noch aus einem
Kommando.
Darüber hinaus gibt es mit Oracle 9i auch Lösungen für andere Fallstricke beim Betrieb einer Standby
Datenbank. Mit dem Standby File Management werden auf dem Produktionssystem erzeugte Dateien
automatisch der Standby Datenbank hinzugefügt. Darüber hinaus setzt das Recovery nach
Netzausfällen automatisch wieder auf.
Welcher Standby Datenbank Typ soll jetzt eingesetzt werden?
Die Frage ist nicht ganz leicht zu beantworten, da sowohl einiges für die physikalische Standby
Datenbank als auch einiges für die logische Standby Datenbank spricht. Aber es gibt
Ausschlusskriterien, an denen wir uns orientieren können.
Seite 4 von 5
579869046
Soll die Datenbank auch für Backup Zwecke genutzt werden, kommt nur die physikalische Standby
Datenbank in Frage. Wird die Standby Datenbank als Reporting System genutzt, spricht das für die
logische Standby Datenbank, da dort die Daten immer aktuell sind. Sollen die Datenbanken nicht die
Rollen tauschen, lassen sich auch zusätzliche Tabellen und Indizes anlegen, oder auch Daten
ausblenden.
Beim Thema Hochverfügbarkeit muss die Zielsetzung beachtet werden. Für Hochverfügbarkeit im
Sinne eines Katastrophenfalls gibt es vermutlich derzeit nichts besseres als eine Standby Datenbank.
Betrachtet man Hochverfügbarkeit aber als Thema, bei dem es gilt, die Ausfallzeiten von
Applikationen möglichst gering zu halten, spricht vieles für eine Oracle-RAC-Lösung mit zusätzlicher
Plattenspiegelung.
Vielleicht sind ja mit Oracle 10g die Einschränkungen des LogMiners beseitigt, denn dann würde bis
auf den Punkt „Backup“ alles für die logische Standby Datenbank sprechen.
Für Fragen, Anregungen und weitere Informationen steht Ihnen der Autor jederzeit gerne unter der u.
g. Kontaktadresse zur Verfügung.
Kontakt:
Andreas Kother
([email protected])
ORDIX AG
Westernmauer 12-16
D-33098 Paderborn
Seite 5 von 5