Oracle 19c Active Data Guard Switchover Procedure

-

 

Oracle 19c Active Data Guard Switchover Procedure

Oracle Active Data Guard provides high availability and disaster recovery by allowing seamless role transitions between the primary and standby databases. A switchover is a planned role reversal where the primary database becomes the standby, and the standby takes over as the new primary without data loss.

This guide covers the step-by-step procedure for switchover in Oracle 19c Active Data Guard.

1. Pre-Checks

Before initiating a switchover, ensure both databases are synchronized and healthy.

On both primary and standby:

SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;

  • Primary should show: PRIMARY, READ WRITE

  • Standby should show: PHYSICAL STANDBY, READ ONLY WITH APPLY or MOUNTED

Also, confirm there are no active sessions or long-running transactions on the primary.

2. Verify Log Transport and Apply

Ensure redo logs are being shipped and applied correctly.

On Primary:

SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST;

On Standby:

SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;

  • ARCH and LGWR processes should be running on primary.

  • MRP (Managed Recovery Process) should be running on standby.

3. Prepare Standby (Optional)

If standby is running in read-only with apply, cancel recovery before switchover:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

4. Switchover Command (Primary)

On the Primary Database:

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

The database is now in standby mode.

5. Activate New Primary (Standby)

On the Standby Database:

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE OPEN;

The standby is now promoted to the new primary database.

6. Convert Former Primary to Standby

On the Former Primary (now mounted as standby):

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

This re-establishes redo apply.

7. Verify New Roles

On both databases:

SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE;

Expected Results:

  • New Primary → PRIMARY, READ WRITE

  • New Standby → PHYSICAL STANDBY, MOUNTED or READ ONLY WITH APPLY

8. Post-Checks

Validate the overall Data Guard configuration.

Using Data Guard Broker (DGMGRL):

DGMGRL> SHOW CONFIGURATION;

If Data Guard Broker is configured, switchover is much simpler:

DGMGRL> CONNECT sys/password@primary;
DGMGRL> SWITCHOVER TO 'standby_db_unique_name';
DGMGRL> SHOW CONFIGURATION;

Conclusion

A switchover in Oracle 19c Active Data Guard ensures a zero data loss, planned role reversal between primary and standby databases. This is typically done during planned maintenance, patching, or to test disaster recovery readiness.

Comments

Post a Comment

Popular posts from this blog

Configure Oracle Database Vault Realms

-
Configure Oracle Database Vault Realms to Secure the HR Schema Oracle Database Vault (DV) is a powerful security feature that enables fine-grained access control by enforcing security policies that protect sensitive data. One of the most important components in Database Vault is the Realm , which creates a security boundary around database objects to prevent unauthorized access — even by highly privileged users. In this blog, we’ll walk through the step-by-step process of configuring a Realm to secure the HR schema in an Oracle Database 19c environment. You’ll learn how to: Create a Realm Add objects to it Restrict access Enable auditing for security tracking What is a Realm? A Realm in Oracle Database Vault defines a logical security boundary around one or more database objects. Once a Realm is in place, no one — not even privileged users like DBAs — can access the protected objects without being explicitly authorized. Realms are ideal for: Securing sensitive ap...
Read more

Configure Transparent Database Encryption (TDE) in Oracle CDB

-
   Configure Transparent Database Encryption (TDE) in Oracle CDB Transparent Data Encryption (TDE) is a vital Oracle feature used to secure sensitive data at rest by encrypting database files. In this guide, we'll walk through configuring TDE in a CDB (Container Database) environment and demonstrate its effectiveness with a test tablespace and HR schema. Prerequisites Oracle Database (12c and above, preferably 19c or later) File system access to create wallets Appropriate privileges to administer TDE and manage tablespaces Step 1: Create a New Tablespace in PDB Connect to the PDB and create a new tablespace: sql SQL > CREATE TABLE SPACE userstab DATAFILE '/opt/oracle/oradata/XE/XEPDB1/userstab01.dbf' SIZE 1 G; Tablespace created. Step 2:Install the Sample HR Schema Install the sample HR schema into the newly created userstab tablespace: sql SQL > @? / demo / schema / human_resources / hr_main.sql This will create and populate HR sc...
Read more

Cloning Oracle E-Business Suite 12.2.11: RMAN + Rapid Clone

-
Cloning Oracle E-Business Suite (EBS) environments is a critical part of managing development, testing, and DR landscapes. In this post, we walk through the process of cloning EBS 12.2.11 from a production environment to a non-production one using RMAN active duplication and Oracle Rapid Clone utilities . Clone Scenario Source Database CDB : PRODCDB Source PDB : prod Target Database CDB : RNDCDB Target PDB : RND Step 1: Prepare the Target Server Create Required Directories mkdir -p /u01/oracle/RNDCDB mkdir -p /u01/oracle/RND mkdir -p /u01/oracle/clone_logs Verify Swap Space (Must be ≥ 16GB) free -h Step 2: Run Pre-Clone on Source Database Tier cd $ORACLE_HOME/appsutil/scripts/prod_PRODCDB perl adpreclone.pl dbTier Application Tier cd $ADMIN_SCRIPTS_HOME perl adpreclone.pl appsTier  Step 3: Clone the CDB with RMAN 3.1: Startup Target CDB in NOMOUNT Mode export ORACLE_SID=RNDCDB sqlplus / as sysdba STARTUP NOMOUNT; 3.2: Run RMAN Active Duplicate rman target sys@PRODCDB auxiliary sy...
Read more