Site Logo

IzzySoft


Das inoffizielle Android-HandbuchDas inoffizielle Android-Handbuch
Für 16,99 € bei Amazon kaufen
Das inoffizielle Android-SystemhandbuchDas inoffizielle Android-Systemhandbuch
Für 6,99 € bei Amazon kaufen
Die besten Android-Apps: Android-Systemtools. Fotografie & Freizeit. Büro-Tools, Schule und StudiumDie besten Android-Apps: Android-Systemtools. Fotografie & Freizeit. Büro-Tools, Schule und Studium
Für 2,94 € bei Amazon kaufen
Stand: 2024-03-28 04:07
Preis & Verfügbarkeit können sich geändert haben.

Erstellen einer DataGuard Broker Konfiguration mit DGMGRL

Obwohl Grid Control ein grafisches Interface für weit mehr als nur die Konfiguration einer hochverfügbaren Datenbank anbietet, stellt dessen Installation doch in manchen Fällen einen ziemlichen Overkill dar. Und sicher gibt es auch noch weitere Gründe, warum in diesem oder jenem Fall ein Kommandozeilen-Tool vorzuziehen ist. Daher soll hier beschrieben werden, wie eine DataGuard Configuration mit dem Kommandozeilen-Tool DGMGRL durchgeführt wird.

Inhalt

Voraussetzungen

Um die genannte Konfiguration erfolgreich durchführen zu können, muss sowohl die primäre als auch die Standby-Datenbank SPFILE gestartet sein. Sollte noch kein SPFILE existieren, so kann dies folgendermaßen konfiguriert werden:

CREATE SPFILE FROM PFILE;
SHUTDOWN IMMEDIATE
STARTUP [MOUNT]

Wie zu sehen ist, reicht die Erstellung eines SPFILEs allein nicht aus – es ist ein Neustart der Datenbank notwendig, damit es auch verwendet wird. Das Keyword "MOUNT" steht hier in eckigen Klammern: Es betrifft lediglich die Standby Datenbank, welche ja zum Zwecke der Recovery nicht geöffnet sein darf.

Vorbereitungen

Um einen sauberen Start zu gewährleisten, müssen alle eventuellen Spuren etwaiger voriger Konfigurations-Versuche beseitigt werden:

  1. Sicherstellen, dass der Listener einen expliziten und speziellen Eintrag für die Datenbanken enthält (siehe unten)
  2. Zurücksetzen der Archive-Log Destination auf der STANDBY Datenbank:
    ALTER SYSTEM SET log_archive_dest_1='';
  3. Stoppen des DG Broker Prozesses (DMON) auf der primären und der Standby Datenbank:
    ALTER SYSTEM SET dg_broker_start=FALSE SCOPE=spfile SID='*';
  4. Entfernen etwaiger DG Broker Konfigurationsdateien aus den Verzeichnissen $ORACLE_BASE/admin/<db_unique_name> und $ORACLE_HOME/dbs, und zwar die Dateien dr1<db_unique_name>.dat sowie dr2<db_unique_name>.dat – wiederum auf allen beteiligten Datenbanken
  5. Starten des DG Broker Prozesses (DMON) - wiederum auf allen beteiligten Datenbanken:
    ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=spfile SID='*';
    Sicherstellen dass er auch läuft – über die Ausgabe von SHOW PARAMETER DG

Erstellen der DataGuard-Konfiguration

Jetzt ist es an der Zeit, das CLI (Command Line Interface) des Brokers zu starten. Dies geschieht auf der Maschine der primären Datenbank – wobei zuvor sicherzustellen ist, dass die $ORACLE_SID auch auf die primäre Datenbank verweist. In der Shell geben wir daher den Befehl dgmgrl ein, und werden von einem entsprechenden Prompt begrüßt: DGMGRL> hat den Shell-Prompt ersetzt.

Nun stellen wir noch die Verbindung zur Datenbank her: CONNECT sys/syspassword. Über ein CONNECT / würde sich DGMGRL zwar nicht beschweren – die Folge wären aber später u. U. einige ORA-01031, da er die Authentifizierung über das Betriebssystem nicht richtig beherrscht. Also besser gleich den richtigen Account (einen, der über SYSDBA-Rechte verfügt) angeben. Der Suffix AS SYSDBA muss dabei weggelassen werden (er führt nur zu einer Fehlermeldung) – offensichtlich verbindet sich DGMGRL automatisch als SYSDBA, sofern das angegebene Konto über die nötigen Rechte verfügt.

Eine einfachere, Passwort-freie Anmeldung ist natürlich jederzeit auch durch Einrichtung eines Oracle Wallet möglich, siehe Managing the Secure External Password Store for Password Credentials in der Oracle Dokumentation.

Erstellen der Konfiguration

Um eine initiale Konfiguration zu erstellen, benutzen wir den Befehl CREATE CONFIGURATION. Das sieht dann etwa wie folgt aus:

CREATE CONFIGURATION 'sample' AS
  PRIMARY DATABASE IS 'primary_db'
  CONNECT IDENTIFIER IS primary_db.world;

Da dies in vielen Dokumentationen fehlt, sollen die einzelnen Parameter an dieser Stelle kurz erklärt werden:

Wurde die Konfiguration erfolgreich erstellt, lässt sie sich mit SHOW CONFIGURATION anzeigen. Hier sollte man sich weder über die zusätzlich angezeigten Einstellungen (also übernommene Default-Werte) noch über die Tatsache wundern, dass die Ausgabe mit dem Status "DISABLED" endet: Das passt schon so, wir sind ja noch nicht fertig :)

Hinzufügen der Standby-Datenbank(en)

Beim Erstellen der Konfiguration haben wir lediglich die primäre Datenbank angegeben – also müssen wir die Standby-Datenbank(en) ebenfalls noch konfigurieren. Dies geschieht mittels des Befehls ADD DATABASE, und sieht etwa wie folgt aus:

ADD DATABASE 'standby_db' AS
  CONNECT IDENTIFIER IS standby_db.world
  MAINTAINED AS PHYSICAL;

Diesmal gibt es nicht so viel zu erkären, da es sich analog zu obigem Beispiel verhält: standby_db muss wiederum dem db_unique_name (diesmal allerdings dem der Standby-Datenbank) entsprechen, der CONNECT IDENTIFIER auf die Standby-Datenbank verweisen. Zu guter Letzt erklärt sich MAINTAINED AS PHYSICAL eigentlich selbst: Es wird eine physische Standby-Datenbank (im Gegensatz zu einer logischen) verwendet.

Überprüfen der Konfiguration

Jetzt wollen wir vielleicht noch einmal nachschauen, was wir eigentlich konfiguriert haben. Wie bereits oben gezeigt, hilft uns dabei der Befehl SHOW CONFIGURATION – jetzt gibt er ein paar mehr Details aus, da wir ja nun auch die Standby-Datenbank(en) hinzugefügt haben. Um Details zu den Datenbanken zu erfahren, gibt es den Befehl SHOW DATABASE [VERBOSE] <db_unique_name>;. Leicht zu erraten: Das Keyword "VERBOSE" sorgt für reichlich zusätzlichen Output.

Aktivieren der Konfiguration

Die Ausgabe von SHOW CONFIGURATION hat es uns gezeigt: Unsere Konfiguration ist noch immer nicht aktiv. Auch das hat seine Richtigkeit: Dafür müssen wir schon explizit sorgen. Dies tun wir mit dem Befehl ENABLE CONFIGURATION vom DGMGRL> Prompt. Kommt der Prompt jetzt nicht gleich zurück, so ist dies als gutes Omen zu werten: Das Aktivieren der Konfiguration braucht ein wenig. Geht es zu schnell, sollte man argwöhnisch werden.

In beiden Fällen sollte jetzt nochmals SHOW CONFIGURATION aufgerufen werden. Endet die Ausgabe mit einem Oracle-Fehler, nicht gleich erschrecken – sondern etwas genauer lesen: Ist es etwas mit "… in progress", so ist das guuut. Anderes könnte böse sein, und Grund zum Trubelschießen.

Spätestens nach ein paar Minuten sollte ein SHOW CONFIGURATION jedoch mit dem schönen Wort "SUCCESS" abschließen – dann ist alles fertig, herzlichen Glückwunsch!

Fast-Start Failover

Wird Ausfallsicherheit benötigt, empfiehlt sich zusätzlich zu obiger einfacher Konfiguration die Aktivierung von FSFO. Einige dafür wichtige Voraussetzungen beinhalten:

Jetzt sollte sich via dgmgrl FSFO aktivieren lassen:

edit database primary_db set property 'LogXptMode'='SYNC';
edit database standby set property 'LogXptMode'='SYNC';
edit database primary_db set property FastStartFailOverTarget=standby;
edit configuration set protection mode as maxavailability;
edit configuration set property FastStartFailOverAutoReinstate=FALSE;
enable fast_start failover;

Hinweis: FastStartFailOverAutoReinstate habe ich hier auf FALSE gesetzt, um ein eventuelles automatisches SwitchOver und damit verbundenes Aktivieren des Active Data Guard zu vermeiden (dies würde eine Lizenzverletzung implizieren, sofern man nicht über die Active Data Guard Lizenz verfügt). Für einen manuellen Switchover, der diese Problematik ebenfalls umgeht, siehe bitte diesen Artikel.

Troubleshooting

Etwaige Fehlermeldungen sind hier oftmals weder besonders hilfreich noch gar aussagekräftig – zusammengefasst kann man diesen nur entnehmen, das "irgendwo irgend etwas irgendwie schief liegt". Beispiel: Warning: ORA-16607: one or more databases have failed. Nun viel Glück bei der Suche!

ORA-01017 bei ADD DATABASE oder SHOW CONFIGURATION

Problem: Beim Erstellen der Konfiguration, kommt es während des Hinzufügens der Standby Datenbank (oder einem darauf folgenden show configuration) zu einem Error: ORA-01017: invalid username/password; logon denied für die Standby Datenbank. Bei der Problemsuche sind jedoch alle manuellen Logon-Versuche erfolgreich und die Passworte stimmen auf beiden Datenbanken überein.

Ursache: Natürlich müssen die Passworte auf der Primären und der Standby Datenbank übereinstimmen. Das allein genügt Oracle aber anscheinend nicht: Scheinbar müssen die Passwort-Dateien auch „binär-identisch“ sein. Um festzustellen, ob hierin die Ursache des Problems besteht, lässt sich das diff Utility verwenden: diff <pwd_file_primary> <pwd_file_standby> gibt Auskunft darüber, ob die beiden Dateien identisch sind oder es (binäre) Unterschiede gibt (sagt dann allerdings nicht, welche – aber das ist hier ohnehin nebensächlich).

Lösung: Datenbank(en) herunterfahren (mindestens die Standby), und dann die Passwort-Datei ($ORACLE_HOME/dbs/orapw$ORACLE_SID) von der primären zur Standby Datenbank kopieren. Anschließend Datenbank(en) wieder hochfahren, und erneut versuchen. Der ORA-01017 sollte nun weg sein.

ORA-16607 bei SHOW CONFIGURATION

Problem: Nachdem sowohl das Erstellen der Konfiguration als auch das Hinzufügen der Standby Datenbank scheinbar erfolgreich abgeschlossen wurden, endet ein anschließendes SHOW CONFIGURATION nicht mit dem erwarteten SUCCESS – sondern stattdessen mit Warning: ORA-16607: one or more databases have failed. Ein Nachschlagen mit oerr ora 16607 ist wenig hilfreich ("IRGENDWO ist IRGENDWAS verkehrt – bitte Fehler suchen und beheben"), und auch im alert.log und etwaigen Trace-Dateien findet sich kein Hinweis.

Ursache: Mindestens eine der Datenbanken verwendet wahrscheinlich kein SPFILE.

Lösung: Selbst wenn das SPFILE mittels CREATE SPFILE FROM PFILE erstellt wurde (einfache Prüfung: Im Verzeichnis $ORACLE_HOME/dbs muss sich eine Datei namens spfile$ORACLE_SID.ora befinden), reicht das nicht aus: Die Datenbank muss auch mit diesem SPFILE gestartet werden. Also sollte ein SHUTDOWN IMMEDIATE gefolgt von einem STARTUP hier nicht fehlen ;)

ORA-16664 bei SHOW CONFIGURATION

Dieser Fehler (ORA-16664: unable to receive the result from a database) kam mir in einem Fall unter. oerr ora 16664 gibt zwar ein paar „sachdienliche Hinweise“ (DG Broker logs, Netzwork-Konfiguration), aber die Funde waren nicht wirklich schlüssig. In meinem Fall fand sich als Schuldiger der gleiche Kandidat wie auch beim obigen ORA-01017: Jemand hatte auf der primären Instanz offensichtlich das SYS Passwort geändert (hin- und wieder zurück), sodass die Passwort-Dateien auf der primären und der Standby-Datenbank nicht mehr „binär-identisch“ waren. Für eine mögliche Lösung also bitte dort nachschauen.

ORA-16608 bei SWITCHOVER

Problem: Nachdem SWITCHOVER TO <standby_db> am Prompt des DGMGRL eingegeben wurde, erfolgt statt des erwarteten SwitchOver lediglich die Fehlerausgabe: Error: ORA-16608: one or more databases have warnings

Ursache: Die gleiche wie zuvor – andere Aktion, andere Fehlermeldung ;) Es könnte aber auch daran liegen, dass die Standby Datenbank nicht gemountet ist und/oder sich nicht im MANAGED RECOVERY Modus befindet.

Lösung: Logischerweise auch wieder die gleiche, wie zuvor. Nicht vergessen zu prüfen, ob die Standby Datenbank sich auch im MANAGED RECOVERY modus befindet.

ORA-01031 während des SwitchOver

Problem: Der gestartete SwitchOver wird zwar erfolgreich ausgeführt – aber währenddessen regnet es einige ORA-01031: insufficient privileges.. Anschließend sind die Datenbanken (wahrscheinlich) auch nicht wieder korrekt hochgefahren.

Ursache: Fehlende Privilegien. Mag seltsam klingen – zumal wenn man sich per CONNECT / vermeintlich als Benutzer mit SYSDBA Rechten angemeldet hat. Wichtig: DGMGRL unterstützt keine Betriebssystem- Authentifizierung! Was ihm so peinlich ist, dass er darauf nicht einmal hinweist …

Lösung: Anmeldung explizit mit einem SYSDBA Konto durchführen, also z.B. CONNECT sys/password.

ORA-16675 beim SWITCHOVER

Problem: Es soll ein SwitchOver durchgeführt werden. DGMGRL antwortet jedoch lapidar mit der Meldung: Error: ORA-16775: target standby database in broker operation has potential data loss

Ursache: Die Standby-Datenbank wartet noch auf Recovery-Informationen.

Lösung: Zunächst einmal sicherstellen, dass die Standby Datenbank sich auch im MANAGED RECOVERY Modus befindet. Falls nicht: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; Dieser Befehl lässt sich auch zum Prüfen verwenden – wenn sie schon im betreffenden Modus ist, gibt es einen entsprechenden Fehler. In diesem Falle den gleichen Befehl nochmals mit CANCEL anstelle des DISCONNECT, und dann nochmals mit DISCONNECT. Ein paar Minuten warten, und den SwitchOver erneut versuchen.

ORA-12514 während des SWITCHOVER

Problem: Es soll ein SwitchOver mittels DGMGRL durchgeführt werden. Obwohl der SwitchOver selbst erfolgreich abgeschlossen wurde, werden die Datenbanken anschließend nicht ordnungsgemäß wieder gestartet. Stattdessen findet sich in der Ausgabe des DGMGRL folgende Fehlermeldung:
ORA-12514: TNS:listener does not currently know of service requested in connect

Ursache: Das Problem liegt in der Konfiguration: DGMGRL benötigt einen speziellen Eintrag in der listener.ora.

Lösung: Details hierzu finden sich im Metalink Dokument 308943.1. Es gilt sicherzustellen, dass die Datenbanken in der listener.ora explizit für DGMGRL konfiguriert sind. Dies sieht in etwa wie folgt aus:

SID_LIST_LISTENER = (
  SID_LIST = (
    SID_DESC = ( GLOBAL_DBNAME = <db_unique_name>_DGMGRL.<db_domain> )
               ( SERVICE_NAME  = <db_unique_name>.<db_domain> )
               ( SID_NAME      = <ORACLE_SID> )
               ( ORACLE_HOME   = <ORACLE_HOME> )
  )
)

Hier ist insbesondere darauf zu achten, dass:

Nach entsprechender Anpassung der listener.ora sollte der Listener nunmehr neu gestartet werden (lsnrctl stop && lsnrctl start). Jetzt benötigen die Datenbanken noch ein paar Minuten, um sich bei selbigem erneut zu registrieren. Um sicherzugehen, kann man nun die Konfiguration nochmals überprüfen: lsnrctl status && lsnrctl services.

Quellen

Außer auf meinen eigenen gesammelten Erfahrungen, basiert dieser Artikel auf:

2020-11-18