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:
- Sicherstellen, dass der Listener einen expliziten und speziellen Eintrag für die Datenbanken enthält (siehe unten)
- Zurücksetzen der Archive-Log Destination auf der STANDBY Datenbank:
ALTER SYSTEM SET log_archive_dest_1='';
- Stoppen des DG Broker Prozesses (DMON) auf der primären und der Standby
Datenbank:
ALTER SYSTEM SET dg_broker_start=FALSE SCOPE=spfile SID='*';
- Entfernen etwaiger DG Broker Konfigurationsdateien aus den Verzeichnissen
$ORACLE_BASE/admin/<db_unique_name>
und$ORACLE_HOME/dbs
, und zwar die Dateiendr1<db_unique_name>.dat
sowiedr2<db_unique_name>.dat
– wiederum auf allen beteiligten Datenbanken - 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 vonSHOW 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:
CREATE CONFIGURATION 'sample'
: 'sample' kann ein beliebiger String sein, der mit dieser Konfiguration assoziiert werden soll. Der Wert hat keine (wirkliche) technische Bedeutung, und dient nur der Identifizierung durch den DBA.PRIMARY DATABASE IS 'primary_db'
: 'primary_db' muss hier mit demdb_unique_name
der primären Datenbank übereinstimmen. Dieser kann bei Bedarf in SQL*Plus mit dem BefehlSHOW PARAMETER db_unique_name
ermittelt werden.CONNECT IDENTIFIER IS primary_db.world
: Hier ist der Alias anzugeben, über den die Datenbank z.B. in dertnsnames.ora
konfiguriert wurde. Anders ausgedrückt:tnsping primary_db.world
muss hier ein "OK" liefern.
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:
- Flashback muss sowohl in der primären als auch der Standby Datenbank aktiviert sein. Prüfen lässt sich dies mit
SELECT flashback_on FROM v$database;
Ist es nicht aktiv:ALTER DATABASE FLASHBACK ON;
Auf der Standby-Datenbank muss dafür ggf. die Recovery kurzzeitig angehalten (und anschließend wieder gestartet) werden:
ALTER DATABASE RECOVER MANAGED DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED DATABASE DISCONNECT;
- Beide Datenbanken müssen über ein Password-File (im Modus EXCLUSIVE oder SHARED) verfügen. Diese Password-Files müssen binär-identisch sein (es genügt nicht, dass sich die enthaltenen Passworte gleichen). Ggf. also die Standby stoppen, das Password-File von der Primary kopieren, Standby wieder starten. Siehe ORA-1017 weiter unten.
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:
<db_unique_name>
den unique name der Datenbank reflektiert (SHOW PARAMETER db_unique_name
)<db_domain>
identisch mit der Datenbank-Domain ist (SHOW PARAMETER db_domain
)<ORACLE_SID>
und<ORACLE_HOME>
ebenfalls die entsprechenden Einstellungen der Datenbank wiederspiegeln (wobei die Angabe von<ORACLE_HOME>
optional ist)
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:
- zwei MetaLink Service Requests (privat)
- MetaLink Dokument 260112.1
- MetaLink Dokument 308943.1