Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Memvalidasi deployment Data Guard
Setelah menyiapkan broker Data Guard,
Anda perlu memverifikasi bahwa redo disalin dari database utama dan diterapkan di
database standby. Prosedur berikut dapat digunakan untuk memeriksa status Data
Guard dari dalam database utama dan standby.
Contoh berikut digunakan di seluruh panduan ini:
Nama unik database
Nama host server
Nama instance RAC
Peran
DBDG_SITE1
site1db1, site1db2
DBDG_SITE11, DBDG_SITE12
Utama
DBDG_SITE2
site2db1, site2db2
DBDG_SITE21, DBDG_SITE22
Siaga
Memvalidasi deployment Data Guard
Login ke server Solusi Bare Metal pertama yang menghosting database utama,
lalu tetapkan variabel lingkungan ORACLE_SID agar Anda dapat terhubung ke
database utama:
sourceoraenv <<< "DBDG_SITE11"
Mulai SQL*Plus, lalu tentukan nomor urutan terbaru untuk log redo
yang diarsipkan:
Catat hasilnya untuk dibandingkan dengan database standby. Nomor urutan di database standby diharapkan cocok dengan database utama.
Login ke server Solusi Bare Metal pertama yang menghosting database standby, lalu
tetapkan variabel lingkungan ORACLE_SID agar Anda dapat terhubung ke database
standby:
sourceoraenv <<< "DBDG_SITE21"
Mulai SQL*Plus, lalu validasikan bahwa nomor urut terbaru yang diterima dan
diterapkan untuk log redo yang diarsipkan cocok dengan nomor urut terbaru di
database utama:
Output berikut menunjukkan tidak ada keterlambatan pada database standby:
NAME VALUE
-------------------- ------------------------------
transport lag +00 00:00:00
apply lag +00 00:00:00
Jika ada jeda, lihat dokumentasi pemecahan masalah Data Guard Oracle.
Peralihan database menggunakan broker Data Guard
Switchover adalah pembalikan peran saat database utama menjadi database
standby, dan sebaliknya. Selama proses pengalihan, klien database akan
terputus dari database utama. Bergantung pada cara aplikasi Anda
terhubung ke database, pengalihan dapat mengganggu traffic aplikasi. Oracle menawarkan opsi untuk mempertahankan kontinuitas aplikasi selama transisi peran. Anda dapat menguji kesiapan pemulihan dari bencana dengan
melakukan pengalihan database dengan petunjuk berikut:
Login ke server Solusi Bare Metal yang menghosting database utama.
Luncurkan antarmuka command line Data Guard, dan hubungkan ke database
standby:
dgmgrl
CONNECTSYS@DBDG_SITE2
Saat diminta memasukkan sandi, masukkan sandi login jarak jauh SYS untuk database.
Validasi bahwa database siap untuk pengalihan.
VALIDATE DATABASE DBDG_SITE2;
Hasil yang berhasil akan melaporkan bahwa database siap untuk beralih.
Jika berhasil, jalankan perintah pengalihan:
SWITCHOVER TO DBDG_SITE2;
Jika perintah berhasil, Anda akan menerima pesan bahwa DBDG_SITE2
adalah database utama baru dalam konfigurasi.
Jalankan perintah berikut untuk mengonfirmasi bahwa peran database telah ditukar:
SHOW CONFIGURATION;
Jalankan perintah berikut untuk kembali ke konfigurasi awal:
SWITCHOVER TO DBDG_SITE1;
Failover database menggunakan broker Data Guard
Failover adalah transisi peran saat salah satu database standby berpindah ke
peran utama karena pemadaman situs secara total. Lakukan ulang tidak akan dikirim ke database standby hingga database standby diaktifkan kembali.
Melakukan failover
Login ke server Solusi Bare Metal pertama yang menghosting database standby.
Hubungkan ke antarmuka command line Data Guard, lalu failover database utama
ke database standby:
dgmgrl
CONNECTSYS@DBDG_SITE2
Saat diminta memasukkan sandi, masukkan sandi login jarak jauh SYS untuk database.
Memulai failover:
FAILOVER TO DBDG_SITE2
Jalankan show configuration; untuk memverifikasi bahwa DBDG_SITE2
kini menjadi database utama, dan DBDG_SITE1
perlu diaktifkan kembali.
Mengaktifkan kembali database utama
Anda hanya dapat mengaktifkan kembali database utama setelah terjadi failover jika
flashback database
diaktifkan. Untuk mengaktifkan kembali database utama yang gagal:
Login ke server Solusi Bare Metal pertama yang menghosting database utama.
Terhubung ke antarmuka command line Data Guard, login ke database
utama, lalu aktifkan kembali database yang gagal:
dgmgrl
CONNECTSYS@DBDG_SITE2
Saat diminta memasukkan sandi, masukkan sandi login jarak jauh SYS untuk database.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]
