Oracle 12c - Das umfassende Handbuch

27.3

Logical Standby-Datenbanken

663

Für einen Failover-Test genügt es, den Primär-Server netzwerkseitig zu trennen.

Damit sind Standby-Datenbank und Observer nicht mehr in der Lage, mit der Pri-

märdatenbank zu kommunizieren, und das Fast Start Failover wird ausgelöst. Eine

andere Möglichkeit bietet das neue Paket DBMS_DG. Damit kann ein Failover

manuell angestoßen werden.

Eine minimale Statistik zur Historie der stattgefundenen Failover-Prozesse stellt

der View V$FS_FAILOVER_STATS zur Verfügung. Weitere Statusinformationen

liefern die Spalten FS_FAILOVER_STATUS und FS_FAILOVER_OBSERVER_-

PRESENT im View V$DATABASE.

27.3 Logical Standby-Datenbanken

Die Logical Standby-Datenbank benutzt die SQL Apply-Architektur für das Anwen-

den der übertragenen Redo Log-Informationen, so wie in Abbildung 27.5 darge-

stellt.

Der Reader-Prozess liest die Redo Log-Informationen aus den Standby oder Archi-

ved Redo Log-Dateien. Danach wandelt der Preparer-Prozess die Redo Log-Informa-

tionen in Logical Change Reords (LCRs) um und speichert diese im LCR Cache des

Shared Pool. Anschließend werden die LCRs durch den Builder-Prozess in Transak-

tionen gruppiert und an den Analyzer übergeben. Dieser Prozess identifiziert die

Abhängigkeiten in den verschiedenen Transaktionen und übergibt sie an den

Coordinator-Prozess. Der Coordinator wiederum ordnet die Transaktionen mehre-

ren Apply-Prozessen zu und stellt sicher, dass beim Einarbeiten der Transaktionen

Auto-reinstate: TRUE

Configurable Failover Conditions

Health Conditions:

Corrupted Controlfile YES

Corrupted Dictionary YES

Inaccessible Logfile NO

Stuck Archiver NO

Datafile Offline YES

Oracle Error Conditions:

(none)

SET SERVEROUTPUT ON

DECLARE

status INTEGER;

BEGIN

status := dbms_dg.initiate_fs_failover('Failover Requested');

dbms_output.put_line(' Actual Status = ORA-' || status);

END;

/

Listing 27.7: Fast Start Failover manuell auslösen

Kapitel 27

Data Guard

664

in die Datenbank die Abhängigkeiten der Transaktionen untereinander berück-

sichtigt werden. Die Apply-Prozesse arbeiten nicht eigenständig, sondern werden

vom Coordinator gesteuert.

Abb. 27.5: Die SQL Apply-Architektur

Für den Einsatz einer Logical Standby-Datenbank muss eine Reihe von Vorausset-

zungen erfüllt sein, die sich wie folgt kategorisieren lassen:

27.3

Logical Standby-Datenbanken

665

쐽 Die betroffenen Datentypen müssen unterstützt werden.

쐽 Die Sätze in der Primärdatenbank müssen eindeutig identifizierbar sein.

Die folgenden Datentypen werden in einer Logical Standby-Datenbank nicht

unterstützt:

쐽 ROWID, UROWID

쐽 BFILE

쐽 VARRAYS und Nested Tables

쐽 XMLType

쐽 Benutzerdefinierte Datentypen

Eine Logical Standby-Datenbank unterscheidet sich physikalisch von der Primär-

datenbank, und die Datensätze besitzen unterschiedliche ROWIDs. Demzufolge

muss für die Einarbeitung ein Weg gefunden werden, die Datensätze eindeutig zu

identifizieren. Das Supplemental Logging-Feature übernimmt diese Aufgabe.

Wenn ein Primary Key oder ein Unique Index an einer Tabelle existiert, werden

die Schlüssel für die eindeutige Identifizierung der Datensätze herangezogen.

Existiert kein solcher Schlüssel an einer Tabelle, dann werden alle Spalten mit

Ausnahme der Typen LONG, LONG RAW und LOB als Schlüssel verwendet.

Mithilfe der SQL-Abfrage in Listing 27.8 können Sie herausfinden, in welchen

Tabellen die Sätze nicht eindeutig identifiziert werden können.

Falls die Applikation sicherstellt, dass die Sätze in einer Tabelle eindeutig sind,

dann können Sie einen RELY CONSTRAINT in der Tabelle anlegen und damit

den zusätzlichen Aufwand der Verwaltung eines Primary Keys vermeiden. Der

RELY CONSTRAINT erhält den Status DISABLED und wird damit nicht von

Hinweis

Prüfen Sie vor dem Einsatz von Logical Standby-Datenbanken, dass die Mehrheit

der Tabellen über einen Primary Key oder Unique Index (NOT NULL) verfügt,

um eine effektive Einarbeitung der Daten zu ermöglichen. Beachten Sie außer-

dem, dass die Aktivierung von Supplemental Logging ohne Schlüssel eine signi-

fikante Erhöhung des Redo Log-Aufkommens auf der Primärdatenbank zur

Folge hat.

SQL> SELECT owner, table_name FROM dba_logstdby_not_unique

2 WHERE (owner, table_name) NOT IN

3 (SELECT DISTINCT owner, table_name FROM dba_logstdby_unsupported);

no rows selected

Listing 27.8: Tabellen ohne Schlüssel finden

Kapitel 27

Data Guard

666

Oracle gepflegt, und es wird angenommen, dass die Sätze in der Tabelle eindeutig

sind.

Die folgenden Schritte beschreiben das Erstellen einer Logical Standby-Daten-

bank.

1. Erstellen Sie eine Physical Standby-Datenbank. Folgen Sie dem Beispiel in

Abschnitt 27.2.

2. Stoppen Sie den Apply-Prozess an der Physical Standby-Datenbank.

3. Bereiten Sie die Primärdatenbank für den Rollentausch vor. Ändern Sie den

Parameter LOG_ARCHIVE_DEST_1, sodass eine Archivierung nur für Online

Redo Log-Dateien und nicht für Standby Redo Log-Dateien erfolgt. Definieren

Sie den Parameter LOG_ARCHIVE_DEST_3. Er wird bei einem Rollentausch

benötigt, wenn die Datenbank die Standby-Rolle übernimmt.

4. Erstellen Sie ein LogMiner Dictionary. Das Dictionary wird benötigt, damit der

LogMiner im SQL Apply-Prozess die Redo-Informationen interpretieren kann.

Mit dem Erstellen des Dictionarys wird automatisch das Supplemental Logging

für Primary Key- und Unique Constraint-Schlüssel eingeschaltet. Sollten Tabel-

len ohne Schlüssel existieren, dann müssen Sie dafür das Supplemental Log-

ging ebenfalls einschalten. Beachten Sie an dieser Stelle den Einfluss auf die

Performance.

SQL> ALTER TABLE test ADD PRIMARY KEY (id) RELY DISABLE;

Table altered.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

SQL> ALTER SYSTEM SET log_archive_dest_1='LOCATION=/opt/oracle/archive/MITP

VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=primary' SCOPE=BOTH;

System altered.

SQL> ALTER SYSTEM SET log_archive_dest_3='LOCATION=/opt/oracle/archive/MITP2

VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=primary'

SCOPE=BOTH;

System altered.

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

PL/SQL procedure successfully completed.

SQL> SELECT supplemental_log_data_min, supplemental_log_data_pk,

supplemental_log_data_ui

2 FROM v$database;

SUPPLEME SUP SUP

-------- --- ---

IMPLICIT YES YES