Logo Oracle Deutschland   DBA Community  -  Mai 2011
Neue Anwendungsmöglichkeiten für Standby Datenbanken: Active Data Guard für mehr Performance
von Ralf Durben, ORACLE Deutschland B.V. & Co. KG

Standby Datenbanken werden normalerweise im Zusammenhang mit Hochverfügbarkeit und Disaster Recovery gesehen: Im Falle eines gravierenden Fehlers auf der Seite der Produktionsdatenbank soll die Standby-Datenbank die Arbeit möglichst schnell übernehmen. Das Konzept von Standby-Datenbanken kann aber viel mehr und Oracle hat sich mit diesem Thema in zwei ausgesprochen interessanten Funktionsbereichen beschäftigt. In diesem Tipp wird einer dieser Funktionsbereiche beleuchtet, der vor allem auch bei Performance Problemen eine interessante Lösung darstellen kann: Die Active Standby-Datenbank, auch Active Data Guard genannt.

In einem früheren Tipp wurde ein seit Oracle Datenbank 11g verfügbarer Funktionsbereich beschrieben: Die Snapshot Standby Datenbank

Vielleicht gibt es noch einige Leser, die mit Standby-Datenbanken noch nicht vertraut sind. Für diese Leser gibt es in dem früheren Tipp eine Einführung.

Dieser Tipp gibt Antworten zu folgenden Fragen:



Was ist eine Active Standby Datenbank?

Eine Active Standby Datenbank ist eine nur-lesend geöffnete Standby Datenbank, die gleichzeitig per Redo Log Apply (also Recovery) aktualisiert wird. Diese Standby Datenbank wird also ständig mit den neuesten Datenänderungen, die in der Primärdatenbank stattgefunden haben, versorgt, während lesend auf diesen Datenbestand zugegriffen werden kann. Damit kann also die Last durch Lese-Transaktionen von der Primär-Datenbank zur Standby-Datenbank verlagert werden. Da für eine Primär-Datenbank bis zu 20 Standby-Datenbanken erstellt und jeweils auch als RAC betrieben werden können, kann durch die Active Standby Datenbank also praktisch unendlich große Lese-Performance erreicht werden.

Durch kleine Tricks ist es aber auch möglich eine Active Standby Datenbank für Schreibtransaktionen zu nutzen. Dieses wird weiter unten genau anhand eines Beispiels beschrieben.

An dieser Stelle ein wichtiger Lizenzhinweis: Die Active Standby Datenbank ist eine Option der Oracle Datenbank Enterprise Edition, muss also separat lizenziert werden und zwar sowohl für die Primär- als auch für die Active Standby Datenbank.

Wozu können Active Datenbank eingesetzt werden?

Die Active Standby Datenbank ist ja eine Kopie der Primär-Datenbank, die ständig aktualisiert wird. Auch wenn der Datenbestand nicht sekundenaktuell ist, gibt es folgende Anwendungsmöglichkeiten
  • Online Kataloge
    In Online-Katalogen wird eine lesende Datenrecherche durchgeführt. Dieses kann zum Beispiel Ersatzteile, Produkte, Auktionen oder andere beliebige Vorgänge betreffen. In einem Online-Katalog müssen die angezeigten Daten in den meisten Fällen nicht sekundengenau sein. Der genaue Warenbestand eines Produkts wird zum Beispiel erst dann relevant, wenn es zu einem Bestellvorgang kommt. Die Suche in einem Online-Katalog, die bei einer großen Anzahl von Benutzern durchaus eine große Leselast für das operationale Datenbanksystem bedeuten würde, kann also sehr gut auf eine Active Standby Datenbank ausgelagert werden.

  • Auftragsverfolgung
    Das bekannteste Beispiel für ein Online-Auftragsverfolgungssystem ist die Nachverfolgung eines Pakets, welches von einem Paketdienst transportiert wird. über eine Webseite können sowohl Absender als auch Empfänger nachsehen, wo sich das Paket gerade befindet, bzw. was mit dem Paket gerade geschieht. Auch hier gilt: Es ist keine sekundengenaue Anzeige des Status erforderlich und die Anwendung (also die Nachverfolgung) ist nur lesend tätig. Demnach kann auch hier die gesamte Nachverfolgung auf eine Active Standby Datenbank ausgelagert werden.

  • Online Shops
    Online Shops (also Verkaufsplattformen im Internet) arbeiten nicht nur lesend mit den Daten, da ja Aufträge erstellt werden sollen. Aber wenn man sich die Nutzung einer derartigen Verkaufsplattform mal ansieht, besteht eine Transaktion doch zumeist aus dem Lesen von Daten, nämlich der Suche nach dem richtigen Produkt. Der Leseanteil in einer solchen Transaktion ist also, verglichen mit dem Schreibanteil, recht hoch. Und je populärer der Online Shop ist, desto größer ist die Last, die durch das Lesen erzeugt wird. Diese Last auf dem operationalen System läßt sich durch den Einsatz von Active Standby Datenbanken sehr gut auslagern. Mit dieser Maßnahme kann der Online-Shop auch praktisch beliebig groß skaliert werden, denn Sie können ja bis zu 20 Standby Datenbanken verwenden, die ihrerseits wieder als RAC betrieben werden können.
    Bei der Nutzung von Active Standby Datenbank ist der, wenn auch geringere, Schreibanteil gesondert zu betrachten, schließlich soll die Anwendung ja mit einer nur lesend geöffneten Datenbank arbeiten, inder ein Schreiben eigentlich nicht erlaubt ist. Durch einen kleinen Trick ist dieses aber dennoch möglich, siehe auch weiter unten.

  • Automatisches Blockrepair
    Die Active Standby Datenbank ist eine lesend geöffnete Kopie der Primärdatenbank und normalerweise auch recht aktuell bzgl. der verfügbaren Daten. Oracle macht sich dieses automatisch zunutze, um die Datenbankadministration im Bereich korrupter Datenblöcke zu erleichtern. Korrupte Datenblöcke sollten recht selten auftreten, zumeist sind sie das Ergebnis von Fehlern in den Bereichen Storage, Controller und Netzwerk. Wenn ein korrupter Datenblock entsteht ist dieses nicht schlimm, da durch ein Recovery (in der Enterprise Edition ist hier das Blockrecovery zu empfehlen) dieser Fehler behoben werden kann.

    Wenn ein Benutzer über die Anwendung zufälligerweise auf einen korrupten Oracle Block zugreift, bekommt er eine Fehlermeldung (ORA-01578), die auch in der Alert.log-Datei gespeichert wird. Diese Fehlermeldung zeigt auch an, welcher Block genau korrupt ist. Wenn dieser aufgetretene Fehler der Datenadministration mitgeteilt wird, kann diese nun den Block reparieren.

    Mit dem Einsatz einer Active Standby Datenbank versucht Oracle den Fehler automatisch zu beheben: Wenn der Benutzer auf einen korrupten Datenblock zugreift prüft Oracle, ob dieser Block in der Active Standby Datenbank verwendbar (also nicht korrupt) ist. Ist dieses der Fall (und das sollte immer dann sein, wenn die Korruption nicht durch die Datenbank selbst erfolgt ist - also so gut wie immer im Fall von Blockkorruptionen), wird dieser Block aus der Active Standby Datenbank in die Primärdatenbank kopiert (also wie ein Blockbackup) und anschließend ein Blockrecovery durchgeführt. Der Benutzer bekommt also keine Fehlermeldung, sondern die gewünschten Daten und der korrupte Oracle Block ist repariert. Die Datenadministration schaut bei diesem Vorgang nur zu, denn der Reparaturvorgang wird in der alert.log-Datei gespeichert.

    Das automatische Block Repair funktioniert auch umgekehrt: Wenn in der Active Standby Datenbank ein Oracle Block korrupt ist, wird dieser automatisch unter Verwendung dieses Blocks aus der Primärdatenbank repariert.

Und natürlich bietet sich die Active Standby Datenbank auch da an, wo eine Snapshot Standby Datenbank als lesend genutzte Datenquelle anwendbar ist (siehe Tipp zu Snapshot Standby Datenbank):
  • Erstellen von Backups
    Das Erstellen von Backups ist immer mit einem Overhead der zu sichernden Datenbank verbunden, wenn auch mal mehr oder weniger.
    • Ein Offline Backup bedeutet Downtime
    • Ein Online Backup erstellt auf Betriebssystemebene erzeugt erhöhtes Redo Log Volumen durch den Backup Modus
    • Ein Online Backup erstellt auf Storageebene (z.B. Snapshot-Techniken) erzeugt erhöhtes Redo Log Volumen durch den Backup Modus, wenn auch hier in einem viel geringerem Rahmen
    • Ein Online Backup erstellt mit RMAN beinhaltet Leselast für die Datenbank
    Wenn das Backup aber von einer identischen Kopie der Produktivdatenbank, also der Standby Datenbank erstellt wird, wäre dieser Overhead nicht relevant, da die Produktivdatenbank davon in keiner Weise betroffen ist. Eine lesend geöffnete Standby Datenbank bietet sich hier an.

  • Auslesen von Daten für ETL-Prozesse
    Wenn Sie ein Data Warehouse betreiben, müssen in regelmäßigen Abständen Daten aus der operationalen Datenbank ausgelesen, zum Data Warehouse transportiert und dort, nach einer eventuellen Transformation, eingelesen werden. Wie beim Erstellen von Backups bedeutet das Auslesen, in welcher Form auch immer, ein Overhead für die operationale Datenbank und die Anwendungen, die dort laufen.
    Auch hier könnte das Auslesen von Daten statt von der operationalen von der lesend geöffneten Standby Datenbank erfolgen.

  • Reporting
    Viele DBAs kennen es: Zu bestimmten, immer wiederkehrenden Zeitpunkten greifen komplexe Reports auf die operationale Datenbank zu und erzeugen eine sehr hohe Leselast.
    Da eine Standby Datenbank eine Kopie der Produktivdatenbank ist, könnten die Reports auch auf die Standby Datenbank zugreifen und so die Produktivdatenbank "verschonen". Auch für diese Anwendung kann eine lesend geöffnete Standby Datenbank verwendet werden.

Welche Voraussetzungen sind für eine Active Standby Datenbank erforderlich?

Sie benötigen
  • Eine Produktivdatenbank mit
    • Oracle Datenbank Enterprise Edition
    • Archivelog Modus, also dem Erstellen von Archive Redo Log Dateien

  • Eine physikalische Standby Datenbank, erstellt mit Data Guard
    Das Erstellen einer Data Guard Standby Datenbank mit Kommandos wird in diesem Tipp beschrieben: Standby Datenbank in "5 Minuten". Alternativ läßt sich eine Data Guard Umgebung auch sehr schnell mit Grid Control erstellen. Ein Wizard führt den Benutzer durch alle erforderlichen Eingaben und startet einen Job, der letztlich die Erstellung durchführt. Bitte beachten Sie dabei, dass das Erstellen einer Data Guard Umgebung mit Grid Control im Rahmen des Provisioning Packs lizenzpflichtig ist, während die Administration bestehender Data Guard Umgebungen durch die Basisfunktionalität von Grid Control abgedeckt wird.


Wie wird eine Standby Datenbank zur Active Standby Datenbank?

In dem folgenden Beispiel wurde die physikalische Standby Datenbank schon angelegt. Sie befindet sich im normalen Standby-Betriebszustand, also im MOUNT-Stadium mit Redo Log Apply. Im Beispiel soll das Umschalten in SQL*Plus gezeigt werden. Gleichzeitig wird der Zustand der Data Guard Konfiguration in DGMGRL gezeigt. 
$ dgmgrl
DGMGRL for Linux: Version 11.2.0.1.0 - Production

Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.

DGMGRL> connect sys/password@OE
Connected.

DGMGRL> show configuration

Configuration - OE

  Protection Mode: MaxAvailability
  Databases:
    OE  - Primary database
    OE1 - Physical standby database
    OE2 - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS
DGMGRL> show database "OE2"

Database - OE2

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       (unknown)
  Real Time Query: OFF
  Instance(s):
    OE2

Database Status:
SUCCESS
Jetzt wird die Standby Datenbank konvertiert mit 
SQL> ALTER DATABASE OPEN;

Database altered.

SQL> SELECT STATUS FROM v$instance;

STATUS
------------
OPEN
Die Datenbank ist jetzt geöffnet. Diese einfache Syntax gilt für Oracle Database 11g Release 2 und höher und auch nur, wenn die Data Guard Umgebung mit dem Data Guard Broker betrieben wird. In Oracle Database 11g Release 1, oder wenn kein Data Guard Broker zum Einsatz kommt, sieht es etwas anders aus: 
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

SQL> SELECT STATUS FROM v$instance;

STATUS
------------
OPEN
Die Aktivierung mit Grid Control wird weiter unten beschrieben.

Der Zustand der Datenbank "OE2" sich jetzt geändert: 
DGMGRL> show database "OE2"

Database - OE2

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       (unknown)
  Real Time Query: ON
  Instance(s):
    OE2

Database Status:
SUCCESS
Datenbankintern wird das Feature der Active Standby Datenbank auch "Real Time Query" bezeichnet. Wie Sie also oben sehen ist dieser Modus jetzt eingeschaltet (im Vergleich zu oben, wo Real Time Query OFF war). Dieses können Sie in der Datenbank auch direkt abfragen mit 
SQL> SELECT open_mode FROM V$DATABASE;

--------------------
OPEN_MODE
READ ONLY WITH APPLY
Es sind jetzt normale Leseoperationen möglich: 
SQL> select * from scott.dept;

    DEPTNO DNAME          LOC
---------- -------------- -------------
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON


Was muss jetzt getan werden, um das automatische Blockrepair einzuschalten?

Die Antwort ist ganz einfach: Nichts!

Das automatische Blockrepair ist durch die Existenz einer Active Standby Datenbank automatisch eingeschaltet. Voraussetzung ist nur, dass die Data Guard Umgebung mit dem Data Guard Broker betrieben wird. Dieses wird aber auch grundsätzlich empfohlen!

Wie können Schreib-Transaktionen auf eine Active Standby Datenbank angewendet werden?

Hinweis an die Reviewer: Dieses ist eine modifizierte Einbettung eines Tipps, den ich schon seit letztem Jahr auf meiner privaten Webseite habe. Wenn dieser Tipp hier zu lang erscheint, koennte hier auch einfach nur eine Verlinkung erfolgen. Ich waere fuer Eure Meinung dankbar.


Anwendungen, wie zum Beispiel Online Shops, greifen nicht nur lesend auf die Datenbank zu, sollen aber auch eine Active Standby Datenbank nutzen können. Teilweise werden temporäre Daten geschrieben oder eben Buchungen getätigt. Und das ist in einer READ ONLY Datenbank nun einmal nicht möglich - zumindest nicht direkt. Es gibt nämlich einen Weg durch Verwendung von Datenbank-Links.

Die Idee ist recht simpel: Die Anwendung schickt das Kommando zur Datenänderung an die Active Standby Datenbank. Die Datenänderung wird jedoch umgeleitet und findet in der Primärdatenbank statt. über den Log-Tranfer vom Standby-Mechanismus gelangt die Datenänderung mit einer kurzen Verzögerung zur Standby Datenbank:

Wichtig ist, dass die Datenbank-Links in der Primärdatenbank erstellt werden müssen, denn in der Active Standby Datenbank, die ja READ ONLY geöffnet ist, funktioniert das nicht. Zusätzlich zum Datenbank-Link wird ein Synonym erstellt, dass für die Anwendung ein Platzhalter ist, um die Datenänderung umzuleiten.

Das folgende Beispiel macht es deutlich:

1. Schritt: Erstellen eines TNS-Alias in der tnsnames.ora

Der Datenbank-Link, der auf die Primärdatenbank verweisen soll, verwendet einen TNS-Alias. Dazu erstellen Sie (falls noch keine existiert) im Verzeichnis "$ORACLE_HOME/network/admin" eine Datei namens "tnsnames.ora". Die Datei muss sowohl auf Primär- als auch auf Standbyseite existieren. Der Inhalt sollte ungefähr so aussehen: 
OE =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = OE)
    )
  )
Im obigen Beispiel hat die Instanz der Primärdatenbank den Namen "OE" und ist unter diesem Namen als Service erreichbar.

2. Schritt: Datenbank-Link erstellen

Erstellen Sie einen Datenbank-Link zur Primärdatenbank. Dieses Kommando muss in der Primärdatenbank ausgeführt werden! 
CREATE PUBLIC DATABASE LINK oe.de.oracle.com CONNECT TO scott IDENTIFIED BY tiger USING 'OE';
In diesem Beispiel wurde als Zielschema das Beispielschema SCOTT gewählt.

3. Schritt: Synonym erstellen

Jetzt muss noch das Synonym erstellt werden. Auch dieses Kommando muss in der Primärdatenbank laufen. 
CREATE SYNONYM emp_dml for emp@oe.de.oracle.com;
Dieses Synonym soll eine Datenänderung für die Tabelle EMP auf der Active Standby Datenbank ermöglichen.

Test

Jetzt zeigt der folgende Test das Ergebnis: Ein direktes Update auf die Tabelle EMP ergibt den Fehler 
SQL> update emp set sal=sal+1;
update emp set sal=sal+1;
       *
ERROR at line 1:
ORA-16000: database open for read-only access
Ein Update auf das Synonym EMP_DML ergibt folgendes Ergebnis: 
SQL> update emp_dml set sal=sal+1;

14 rows updated.
Mit dem oben beschriebenen kleinen Kunstgriff lassen sich also durchaus Datenänderungen in der READ ONLY Datenbank durchführen. Weitere Details dazu gibt es auch in dem Whitepaper "Oracle Active Data Guard Oracle Data Guard 11g Release 1".

Wie wird Active Standby Datenbank deaktiviert, also wieder zur normalen Standby Datenbank?

Sie können die Active Standby Datenbank auch wieder in eine normale Standby Datenbank zurückverwandeln, indem Sie die Datenbank herunterfahren und dann in das Stadium MOUNT hochfahren: 
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  313860096 bytes
Fixed Size                  1336232 bytes
Variable Size             247467096 bytes
Database Buffers           58720256 bytes
Redo Buffers                6336512 bytes
Database mounted.
In DGMRGL wird dann der Status der Datenbank so angezeigt: 
DGMGRL> show database "OE2"

Database - OE2

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       (unknown)
  Real Time Query: OFF
  Instance(s):
    OE2

Database Status:
SUCCESS
Die Datenbank ist jetzt wieder eine normale physikalische Standby Datenbank. Die Deaktivierung mit Grid Control wird weiter unten beschrieben.

Wie wird eine Standby Datenbank zur Active Standby Datenbank mit Grid Control?

Navigieren Sie zum Data Guard überblick einer Primärdatenbank. Wählen Sie eine der Standby Datenbanken aus. Die Spalte "Real Time Query" zeigt an, ob diese Datenbank schon eine Active Standby Datenbank ist (ENABLED), oder nicht (DISABLED). Klicken Sie für die ausgewählte Datenbank auf den Link "Disabled".
Im folgenden Screen aktivieren Sie die Checkbox "Enable Real-time Query"
,klicken auf "Apply"
und Grid Control aktiviert die Active Standby Datenbank


Wie wird eine Active Standby Datenbank zur Standby Datenbank mit Grid Control?

Navigieren Sie zum Data Guard überblick einer Primärdatenbank. Wählen Sie eine der Standby Datenbanken aus. Die Spalte "Real Time Query" zeigt an, ob diese Datenbank schon eine Active Standby Datenbank ist (ENABLED), oder nicht (DISABLED). Klicken Sie für die ausgewählte Datenbank auf den Link "Enabled".
Im folgenden Screen deaktivieren Sie die Checkbox "Enable Real-time Query"
,klicken auf "Apply"
und Grid Control deaktiviert die Active Standby Datenbank.

Fazit

Mit der Active Standby Datenbank eröffnen sich viele neue und interessante Einsatzmöglichkeiten von Standby Datenbanken. Sie können damit die Lese-Last durch Reporting, ETL-Prozesse, Erstellen von Backups, Online Kataloge und Online Shops oder Autragsverfolgungssysteme aus der Produktivdatenbank herausnehmen und dadurch die Performance der Produktivdatenbank steigern bzw. stabilisieren. Das automatische Blockrepair reduziert die Anzahl von Fehlern aufgrund von korrupten Oracle Blöcken drastisch und damit auch den Aufwand für die Datenbankadministratoren. Der Einsatz von Data Guard ist also nicht mehr nur für Hochverfügbarkeitsanforderungen interessant.

Lizenzhinweis: Die Active Standby Datenbank ist eine Option der Oracle Datenbank Enterprise Edition, muss also separat lizenziert werden und zwar sowohl für die Primär- als auch für die Active Standby Datenbank.

Zurück zur Community-Seite