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: Die Snapshot Standby-Datenbank.

In einem späteren Tipp wird der zweite neue Funktionsbereich beschrieben: Die Active Standby Datenbank

Vielleicht gibt es noch einige Leser, die mit Standby-Datenbanken noch nicht vertraut sind. Für diese Leser beginnt dieser Tipp erst einmal mit einer kleinen Konzeptbeschreibung. Wer mit dem Konzept von Standby-Datenbanken schon vertraut ist, kann den ersten Teil überspringen und hier klicken.

Konzept von Standby-Datenbanken

• Wenn der Produktivrechner komplett ausfällt, sind auch Redo Log Informationen verloren (zumindest Online Redo Log)
  Dieses läßt sich dadurch lösen, dass die Online Redo Log Dateien auf einem Shared Storage gespeichert sind. Im Fehlerfall kann der Standby-Rechner auf den Shared Storage zugreifen. Dieses war früher die Lösung der Wahl, jedoch kann die Datenbank mittlerweile die Online Redo Log Dateien direkt auf den Standby-Rechner spiegeln, sodass diese sofort auf dem Standby-Rechner vorliegen.
  -> Data Guard automatisiert den gesamten Transportprozess von Redo Log Informationen in verschiedenen Betriebsvarianten, auch mit der Sicherstellung der Verfügbarkeit aller Redo Log Informationen auf der Standby-Seite.


• Wenn alle auf dem Standby-Rechner vorhandenen Archive Log Dateien per Recovery eingespielt sind, bricht das Recover-Kommando ab
  Ist das Recovery also schneller als der "Nachschub" an Archive Log Dateien beendet die Datenbank das Recovery. Nachdem weitere Archive Log Dateien eingetroffen sind, muss das Kommando wieder neu gestartet werden.
  -> Data Guard automatisiert den gesamten Recoveryprozess auf der Standby-Seite.


• Ein Ausfall der Produktivdatenbank wird nicht automatisch erkannt
  Sollte die Produktivdatenbank ausfallen, muss dieses zunächst erkannt werden. Anschließend muss die Standby-Datenbank aktiviert und die Anwendungen bzw. Endbenutzer zur neuen Produktivdatenbank verbunden werden.
  -> Data Guard automatisiert den gesamten Fail-Over Vorgang.

Wozu könnten Standby Datenbank noch eingesetzt werden?

• 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. Dazu müsste die Standby Datenbank aber lesend geöffnet sein.


• 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 Standby Datenbank erfolgen, wenn diese lesend geöffnet wäre.


• 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 müsste die Standby Datenbank lesend geöffnet sein.


• Testsysteme
  Das regelmäßige Erstellen von Test- und Entwicklungssystemen, die als Kopie einer Produktivdatenbank aufgebaut werden sollen, ist mit Standby-Techniken recht schnell durchgeführt. Die bestehende Standby-Datenbank muss dazu lesend und schreibend geöffnet werden.


• Datenanonymisierung
  Eine große Sicherheitslücke ergibt sich immer dann, wenn Produktivdaten auf Test- und Entwicklungssystemen zum Einsatz kommen, die nicht so gut gesichert sind, wie die Produktivsysteme. Das ist typischerweise immer dann der Fall wenn mehrere Testsysteme, also dezentral, verwendet werden. Zu einem sicheren IT-Betrieb gehört in diesem Fall eine Anonymisierung zur Produktion von Testdaten, deren Verlust keinen Schaden bedeuten würde. Da in einem Produktivsystem die Daten nicht verändert werden sollten, beginnt ein Anonymisierungsprozess immer mit dem Kopieren der zu anonymisierenden Daten aus einem Produktivsystem hin in ein Arbeitssystem, in dem dann die Daten verändert werden.
  Da eine Standby Datenbank eine Kopie der Produktivdatenbank ist, wäre bei Nutzung einer Standby Datenbank der erste Kopiervorgang nicht mehr notwendig. Da die Daten in der Standby-Datenbank aber durch den Anonymisierungsvorgang verändert werden, müsste im Gegensatz zu den obigen Anwendungsmöglichkeiten die Standby Datenbank lesend und schreibend geöffnet werden.

Was ist eine Snapshot Standby Datenbank?

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

• 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.
  • Eingeschaltetem (also aktiviertem) Flashback Database
    Sie schalten Flashback Database ein mit

    ALTER DATABASE FLASHBACK ON;
    

    und setzen die maximale Rücksetzdauer passend zur Dauer der Aktionen mit der Snapshot Standby Datenbank mit

    ALTER SYSTEM SET db_flashback_retention_target=1440;
    

    Der Wert wird in Minuten angegeben. Im Beispiel sind es also 1440 Minuten, was 24 Stunden entspricht.

Wie wird eine Standby Datenbank zur Snapshot Standby Datenbank und umgekehrt?

In SQL*Plus:
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

In Data Guard Manager Command Line Utility DGMGRL:
DGMGRL> CONVERT DATABASE stby TO SNAPSHOT STANDBY;

In Grid Control:
Auswählen der Standby Datenbank und klick auf den Button "Convert"

In SQL*Plus (Achtung: Datenbank muss im MOUNT-Stadium sein):
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

In Data Guard Manager Command Line Utility DGMGRL:
DGMGRL> CONVERT DATABASE stby TO PHYSICAL STANDBY;

In Grid Control:
Auswählen der Standby Datenbank und klick auf den Button "Convert"

Beispiel

$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Thu Mar 17 11:03:49 2011

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


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning and Real Application Testing options

SQL> SELECT STATUS FROM v$instance;

STATUS
------------
MOUNTED

$ 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

SQL> SELECT STATUS FROM v$instance;

STATUS
------------
MOUNTED

DGMGRL> CONVERT DATABASE "OE2" TO SNAPSHOT STANDBY;
Converting database "OE2" to a Snapshot Standby database, please wait...
Database "OE2" converted successfully

SQL> SELECT STATUS FROM v$instance;

STATUS
------------
OPEN

DGMGRL> show configuration

Configuration - OE

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

Fast-Start Failover: DISABLED

SQL> SELECT scn,name,time FROM v$restore_point;

       SCN NAME                                          TIME
---------- --------------------------------------------- -------------------------------
  32357405 SNAPSHOT_STANDBY_REQUIRED_03/17/2011 11:44:37 17-MAR-11 11.44.37.000000000 AM

SQL> select * from scott.dept;

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

SQL> delete from scott.dept;

4 rows deleted.

SQL> commit;

Commit complete.

DGMGRL> CONVERT DATABASE "OE2" TO PHYSICAL STANDBY;
Converting database "OE2" to a Physical Standby database, please wait...
Operation requires shutdown of instance "OE2" on database "OE2"
Shutting down instance "OE2"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "OE2" on database "OE2"
Starting instance "OE2"...
ORACLE instance started.
Database mounted.
Continuing to convert database "OE2" ...
Operation requires shutdown of instance "OE2" on database "OE2"
Shutting down instance "OE2"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "OE2" on database "OE2"
Starting instance "OE2"...
ORACLE instance started.
Database mounted.
Database "OE2" converted successfully

Fazit

Zurück zur Community-Seite