Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Data Guard-Bereitstellung validieren
Nachdem Sie den Data Guard-Broker eingerichtet haben, müssen Sie prüfen, ob die Wiederherstellung aus der primären Datenbank kopiert und auf die Standby-Datenbank angewendet wurde. Mit dem folgenden Verfahren können Sie den Data Guard-Status in der primären Datenbank und der Standby-Datenbank prüfen.
Die folgenden Beispiele werden in diesem Leitfaden verwendet:
Eindeutiger Name der Datenbank
Server-Hostnamen
RAC-Instanznamen
Rolle
DBDG_SITE1
site1db1, site1db2
DBDG_SITE11, DBDG_SITE12
Primär
DBDG_SITE2
site2db1, site2db2
DBDG_SITE21, DBDG_SITE22
Standby
Data Guard-Bereitstellung validieren
Melden Sie sich beim ersten Bare-Metal-Lösungsserver an, der die primäre Datenbank hostet, und legen Sie dann die Umgebungsvariable ORACLE_SID fest, damit Sie eine Verbindung zur primären Datenbank herstellen können:
sourceoraenv <<< "DBDG_SITE11"
Starten Sie SQL*Plus und ermitteln Sie dann die neueste Sequenznummer für archivierte Wiederherstellungs-Logs:
Notieren Sie die Ergebnisse, um sie mit der Standby-Datenbank zu vergleichen. Es wird erwartet, dass Sequenznummern in der Standby-Datenbank mit der primären Datenbank übereinstimmen.
Melden Sie sich beim ersten Bare-Metal-Lösungsserver an, der die Standby-Datenbank hostet, und legen Sie dann die Umgebungsvariable ORACLE_SID fest, damit Sie eine Verbindung zur Standby-Datenbank herstellen können:
sourceoraenv <<< "DBDG_SITE21"
Starten Sie SQL*Plus und prüfen Sie, ob die letzte empfangene und angewendete Sequenznummer mit der neuesten Sequenznummer in der primären Datenbank übereinstimmt:
Ein Switchover ist eine Rollenumkehr, bei der die primäre Datenbank zu einer Standby-Datenbank wird und umgekehrt. Während des Switchover-Prozesses werden Datenbankclients von der primären Datenbank getrennt. Je nachdem, wie Ihre Anwendung eine Verbindung zur Datenbank herstellt, kann ein Switchover den Anwendungstraffic beeinträchtigen. Oracle bietet während der Rollenübergänge Optionen zur Aufrechterhaltung der Anwendungskontinuität. Sie können Ihre Bereitschaft zur Notfallwiederherstellung testen, indem Sie mit der folgenden Anleitung einen Datenbank-Switchover ausführen:
Melden Sie sich bei dem Bare-Metal-Lösungsserver an, der die primäre Datenbank hostet.
Starten Sie die Data Guard-Befehlszeileschnittstelle und stellen Sie eine Verbindung zur Standby-Datenbank her:
dgmgrl
CONNECTSYS@DBDG_SITE2
Wenn Sie zur Eingabe eines Passworts aufgefordert werden, geben Sie das Passwort für Ihre SYS-Remote-Anmeldung für die Datenbank ein.
Prüfen Sie, ob die Datenbank für das Switchover bereit ist.
VALIDATE DATABASE DBDG_SITE2;
Sie erhalten eine entsprechende Meldung, wenn die Datenbank für die Umstellung bereit ist.
Wenn Sie die Erfolgsmeldung erhalten haben, führen Sie den Switchover-Befehl aus:
SWITCHOVER TO DBDG_SITE2;
Wenn der Befehl erfolgreich ist, erhalten Sie eine Nachricht, dass DBDG_SITE2 die neue primäre Datenbank in der Konfiguration ist.
Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Datenbankrollen vertauscht wurden:
SHOW CONFIGURATION;
Führen Sie den folgenden Befehl aus, um zur ursprünglichen Konfiguration zurückzukehren:
SWITCHOVER TO DBDG_SITE1;
Datenbank-Failover mit Data Guard-Broker
Ein Failover ist ein Rollenwechsel, bei dem eine der Standby-Datenbanken aufgrund eines kompletten Ausfalls zur primären Datenbank migriert wird. Das Wiederherstellen wird erst dann in die Standby-Datenbank gesendet, wenn die Standby-Datenbank wiederhergestellt wurde.
Failover ausführen
Melden Sie sich beim ersten Bare-Metal-Lösungsserver an, der die Standby-Datenbank hostet.
Stellen Sie eine Verbindung zur Data Guard-Befehlszeilenschnittstelle her und führen Sie dann ein Failover der primären Datenbank zur Standby-Datenbank aus:
dgmgrl
CONNECTSYS@DBDG_SITE2
Wenn Sie zur Eingabe eines Passworts aufgefordert werden, geben Sie das Passwort für Ihre SYS-Remote-Anmeldung für die Datenbank ein.
Failover initialisieren:
FAILOVER TO DBDG_SITE2
Führen Sie show configuration; aus, um zu prüfen, ob DBDG_SITE2 jetzt die primäre Datenbank ist und DBDG_SITE1 wiederhergestellt werden muss.
Primäre Datenbank reaktivieren
Sie können die primäre Datenbank erst nach einem Failover wiederherstellen, wenn flashback database aktiviert ist. So aktivieren Sie die ausgefallene primäre Datenbank wieder:
Melden Sie sich beim ersten Bare-Metal-Lösungsserver an, der die primäre Datenbank hostet.
Stellen Sie eine Verbindung zur Data Guard-Befehlszeilenschnittstelle her, melden Sie sich in den primären Datenbanken an und aktivieren Sie dann die fehlerhafte Datenbank wieder:
dgmgrl
CONNECTSYS@DBDG_SITE2
Wenn Sie zur Eingabe eines Passworts aufgefordert werden, geben Sie das Passwort für Ihre SYS-Remote-Anmeldung für die Datenbank ein.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThis document provides instructions on how to validate a Data Guard deployment by checking redo log sequence numbers and process status between primary and standby databases.\u003c/p\u003e\n"],["\u003cp\u003eThe process for performing a database switchover, which reverses the roles of the primary and standby databases, is detailed, including steps to validate and execute the switchover.\u003c/p\u003e\n"],["\u003cp\u003eSteps to perform a database failover, where a standby database becomes the new primary due to a site outage, are outlined, as well as a warning about potential data loss during this process.\u003c/p\u003e\n"],["\u003cp\u003eThe document explains how to reinstate a failed primary database after a failover, requiring that the flashback database feature is enabled.\u003c/p\u003e\n"]]],[],null,["# Validate the Data Guard deployment\n==================================\n\nAfter you've [set up the Data Guard broker](/bare-metal/docs/solutions/oracle/data-guard-setup/broker),\nyou need to verify that redo was copied from the primary database and applied on\nthe standby database. The following procedure can be used to check the Data\nGuard status from within the primary and standby databases.\n\nThe following examples are used throughout this guide:\n\nValidate the Data Guard deployment\n----------------------------------\n\n1. Log in to the first Bare Metal Solution server that hosts the primary database,\n then set the `ORACLE_SID` environment variable so you can connect to the\n primary database:\n\n source oraenv \u003c\u003c\u003c \"\u003cvar translate=\"no\"\u003eDBDG_SITE11\u003c/var\u003e\"\n\n2. Start SQL\\*Plus, then determine the latest sequence number for archived redo\n logs:\n\n sqlplus / as sysdba\n\n SELECT THREAD#, max(SEQUENCE#) \"Last Primary Seq Archived\"\n FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =\n VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;\n\n The following output has maximum sequence number of 40 for thread 1 and a\n maximum sequence number of 33 for thread 2: \n\n THREAD# Last Primary Seq Archived\n ---------- -------------------------\n 1 40\n 2 33\n\n Record the results to compare with the standby database. Sequence numbers on\n the standby database are expected to match the primary database.\n3. Log in to the first Bare Metal Solution server that hosts the standby database, then\n set the `ORACLE_SID` environment variable so you can connect to the standby\n database:\n\n source oraenv \u003c\u003c\u003c \"\u003cvar translate=\"no\"\u003eDBDG_SITE21\u003c/var\u003e\"\n\n4. Start SQL\\*Plus, then validate that the latest sequence number received and\n applied for archived redo logs matches the latest sequence number on the\n primary database:\n\n sqlplus / as sysdba\n\n SELECT THREAD#, max(SEQUENCE#) \"Last Standby Seq Received\"\n FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =\n VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;\n\n SELECT THREAD#, max(SEQUENCE#) \"Last Standby Seq Applied\"\n FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =\n VDB.RESETLOGS_CHANGE# AND VAL.APPLIED IN ('YES','IN-MEMORY') GROUP BY\n THREAD# ORDER BY 1;\n\n The following output has sequence numbers that match the prior query run\n against the standby database: \n\n THREAD# Last Standby Seq Received\n ---------- -------------------------\n 1 40\n 2 33\n\n THREAD# Last Standby Seq Applied\n ---------- ------------------------\n 1 40\n 2 33\n\n5. Check that the status of the managed recovery process is `APPLYING_LOG`:\n\n SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE '%MRP%';\n\n The following example shows a single managed recovery process named `MRP0`\n with status of `APPLYING_LOG`: \n\n PROCESS STATUS\n --------- ------------\n MRP0 APPLYING_LOG\n\n6. Check for any transport or apply lag on the standby database:\n\n COLUMN NAME FORMAT a20\n COLUMN VALUE FORMAT a30\n SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME LIKE '%lag%';\n\n The following output shows no lag on the standby database: \n\n NAME VALUE\n -------------------- ------------------------------\n transport lag +00 00:00:00\n apply lag +00 00:00:00\n\n If there is lag, consult Oracle's Data Guard troubleshooting [documentation](https://docs.oracle.com/en/database/oracle/oracle-database/19/haovw/tune-and-troubleshoot-oracle-data-guard.html#GUID-E8C27979-9D37-4899-9306-A5AE2B5CF6C0).\n\nDatabase switchover using the Data Guard broker\n-----------------------------------------------\n\nA switchover is a role reversal in which the primary database becomes a standby\ndatabase, and vice versa. During the switchover process, database clients are\ndisconnected from the primary database. Depending on how your application\nconnects to the database, a switchover can disrupt application traffic. Oracle\noffers [options to maintain application continuity](https://docs.oracle.com/en/database/oracle/oracle-database/19/racad/ensuring-application-continuity.html)\nduring role transitions. You can test your disaster recovery readiness by\nperforming a database switchover with the following instructions:\n\n1. Log in to the Bare Metal Solution server that hosts the primary database.\n\n2. Launch the Data Guard command line interface, and connect to the standby\n database:\n\n dgmgrl\n\n CONNECT SYS@\u003cvar translate=\"no\"\u003eDBDG_SITE2\u003c/var\u003e\n\n3. When prompted for a password, enter your SYS remote login password for the\n database.\n\n4. Validate that the database is ready for a switchover.\n\n VALIDATE DATABASE \u003cvar translate=\"no\"\u003eDBDG_SITE2\u003c/var\u003e;\n\n A successful result will report that the database is ready for switchover.\n5. If successful, perform the switchover command:\n\n SWITCHOVER TO \u003cvar translate=\"no\"\u003eDBDG_SITE2\u003c/var\u003e;\n\n If the command succeeds, you'll receive a message that \u003cvar scope=\"DBDG_SITE2\" translate=\"no\"\u003eDBDG_SITE2\u003c/var\u003e\n is the new primary database in the configuration.\n6. Run the following command to confirm that the database roles are swapped:\n\n SHOW CONFIGURATION;\n\n7. Run the following command to return to the original configuration:\n\n SWITCHOVER TO \u003cvar translate=\"no\"\u003eDBDG_SITE1\u003c/var\u003e;\n\n| **Note:** Running the switchover command while connected to the primary database might result in the connection being dropped. This is due to the primary database being restarted during the switchover process.\n\nDatabase failover using Data Guard broker\n-----------------------------------------\n\nA failover is a role transition in which one of the standby databases moves to\nthe primary role due to a complete site outage. Redo will not be shipped to the\nstandby database until the standby database has been reinstated.\n| **Warning:** A failover typically involves data loss.\n\n### Perform the failover\n\n1. Log in to the first Bare Metal Solution server that hosts the standby database.\n\n2. Connect to the Data Guard command line interface, then failover the primary\n to the standby database:\n\n dgmgrl\n\n CONNECT SYS@\u003cvar translate=\"no\"\u003eDBDG_SITE2\u003c/var\u003e\n\n3. When prompted for a password, enter your SYS remote login password for the\n database.\n\n4. Initiate the failover:\n\n FAILOVER TO \u003cvar translate=\"no\"\u003eDBDG_SITE2\u003c/var\u003e\n\n Run `show configuration;` to verify that \u003cvar scope=\"DBDG_SITE2\" translate=\"no\"\u003eDBDG_SITE2\u003c/var\u003e\n is now the primary database, and \u003cvar scope=\"DBDG_SITE1\" translate=\"no\"\u003eDBDG_SITE1\u003c/var\u003e\n needs to be reinstated.\n\n### Reinstate the primary database\n\nYou can only reinstate the primary database after a failover if\n[`flashback database`](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/examples-of-using-oracle-data-guard.html#GUID-1163448F-6B18-4A44-AA8D-7CDF0D1360FB)\nis enabled. To reinstate the failed primary database:\n\n1. Log in to the first Bare Metal Solution server that hosts the primary database.\n\n2. Connect to the Data Guard command line interface, log in to the primary\n databases, then reinstate the failed database:\n\n dgmgrl\n\n CONNECT SYS@\u003cvar translate=\"no\"\u003eDBDG_SITE2\u003c/var\u003e\n\n When prompted for a password, enter your SYS remote login password for the\n database.\n3. Reinstate the database:\n\n REINSTATE DATABASE \u003cvar translate=\"no\"\u003eDBDG_SITE1\u003c/var\u003e;\n EXIT;\n\nNext steps\n----------\n\nNext, [set up a Data Guard observer on Compute Engine](/bare-metal/docs/solutions/oracle/data-guard-setup/observer)."]]