Oracle 19c Data Guard Switchover Procedure – Step-by-Step Guide

By -

Purpose

This guide describes a step-by-step approach to perform a switchover in an Oracle Data Guard configuration.

Prerequisites

  • Primary and Standby are healthy and synchronized.
  • Both databases are under clusterware control.
  • SYSDBA connectivity is available.
  • Application services are stopped before switchover.

Environment Details

Primary Database:

 PRD_CDB

Standby Database:

 STBY_CDB

Primary Server:

 PRD_NODE1

Standby Server:

 STBY_NODE1

Switchover Procedure (With Actual Output)

STEP 1. Remove DelayMins (if configured)

DGMGRL> connect sys/<password>

DGMGRL> show database PRD_CDB delaymins;

DGMGRL> edit database PRD_CDB set property 'DelayMins'='0';

DGMGRL> show database PRD_CDB delaymins;

Sample Output:

DelayMins = '180'

Property "DelayMins" updated 

DelayMins = '0'

Step 2. Shut Down Application Services

Ensure all application connections to PRD_CDB are stopped.

Step 3. Validate Archive Destinations

SELECT DEST_NAME, STATUS, DESTINATION FROM V$ARCHIVE_DEST WHERE DESTINATION IS NOT NULL;

Step 4. Check Primary Database Status

DGMGRL> SHOW DATABASE 'PRD_CDB';

Sample Output:

Database - PRD_CDB

  Role:               PRIMARY

  Intended State:     TRANSPORT-ON

  Instance(s):

    prd1

    prd2

Database Status:

SUCCESS

Step 5. Check Standby Database Status

DGMGRL> SHOW DATABASE VERBOSE 'STBY_CDB';

Sample Output:

Database - STBY_CDB

  Role:               PHYSICAL STANDBY

  Intended State:     APPLY-ON

  Apply Lag:          0 seconds

  Transport Lag:      (unknown)

  Instance(s):

    stby1 (apply instance)

    stby2

Database Status:

SUCCESS

Step 6. Validate Databases for Switchover

DGMGRL> validate database PRD_CDB;

DGMGRL> validate database STBY_CDB;

Sample Output:

Ready for Switchover:  Yes

Flashback Database:    Off

Managed by Clusterware: YES

Step 7. Perform Switchover

DGMGRL> SWITCHOVER TO STBY_CDB;

Sample Output:

Performing switchover NOW, please wait...

Connected to "STBY_CDB" as SYSDBA.

New primary database "STBY_CDB" is opening...

Oracle Clusterware is restarting database "PRD_CDB" ...

Switchover succeeded, new primary is "STBY_CDB"

Step 8. Post-Switchover Verification

DGMGRL> SHOW CONFIGURATION;

Sample Output:

Configuration Status: SUCCESS

Primary:   STBY_CDB

Standby:   PRD_CDB

Frequently Asked Questions:

1. What is a switchover in Oracle Data Guard?

A switchover is a planned role reversal where the primary database

becomes standby and the standby database becomes primary without

data loss.

2.What conditions must be met before performing a switchover?

  • Standbydatabase must be in sync with primary.
  • RedoApply must be running.
  • No archivegap.
  • DG Broker configuration must be valid.
  • Databases should be ready for switchover (DGMGRL VALIDATE).

3. What does the “VALIDATE DATABASE” command check?

It checks:

  • Database sync status
  • Apply lag and transport lag
  • Archive gaps
  • Flashback availability
  • Clusterware management
  • Whether databases are ready for role transition

4. What is “Apply Lag” and “Transport Lag”?

  • Apply Lag – delay between redo applied on standby vs primary.
  • Transport Lag – delay in redo shipping.

Zero lag is ideal before switchover

5. What do you do if switchover fails halfway?

 

6. How do you check if a DB is ready for switchover?

DGMGRL> VALIDATE DATABASE <db_name>;

7. How do you check Data Guard configuration after switchover?

DGMGRL> SHOW CONFIGURATION;

DGMGRL> SHOW DATABASE <db_name>;

8. What should DBAs check post-switchover?

New primary open read/write

Old primary running as standby

Apply running

Archive log shipping

Services running correctly


Related Posts:


Comments

Post a Comment

Popular posts from this blog

How to troubleshoot long running concurrent request in R12.2

By -
We frequently encounter issues with concurrent programs running long and concurrent requests not picking up jobs. These problems are often expected from the development and functional team we need to address this issue To solve this, we should take the following steps: Collect below basis level of information to development team 1 Oracle seeded program/Custom program? 2 How much time it used earlier? 3 Is there any recent code change done in concurrent program? 4 Is this program fetching higher data compare to last run? 5 Does this job running any specific time/ It can be run any time? 6 Does this job fetching data using DB link? 7 Does the problem happen on both the test and production instance?   Troubleshooting Steps for Concurrent Requests Check for Locks and Blocking sessions Identify if the request is running but blocked by database locks/Blocking sessions. Use DBA tools or queries to identify and release locks if necessary. Review Parameters and Data ...
Read more

EBS R12.2 Cloning Step by step

By -
Image
I explained Cloning step by step procedure for database and R12.2 application. My Database version 11.2.0.3.0         1. Preclone db tier and application Tier     2. Copy the apps Tier  and db home only to target server     3. Take Rman full backup and copy the backup to target server            cd [RDBMS ORACLE_HOME]/appsutil/clone/bin              $ perl adcfgclone.pl dbTechStack                         Run adcfgclone dbTechStack This files are to be restored to a different location: db_file_name_convert=('/oracle/PROD/db/data' , '/oracle/CLONE/db/data') log_file_name_convert=('/oracle/PROD/db/data' , '/oracle/CLONE/db/data') $ sqlplus '/as sysdba' SQL> s...
Read more

How to Grant Privileges in Oracle EBS R12.2 Using AD_ZD.GRANT_PRIVS

By -
When working with Oracle E-Business Suite (EBS) R12.2, granting privileges to applicatation objects requires special care to avoid invalidating objects in the current edition.  Grants cannot be performed in the run edition when the application is being used. A direct GRANT (DDL) command can potentially cause object invalidation when the application is actively being used. To handle this in a more controlled manner, Oracle introduced the AD_ZD.GRANT_PRIVS utility. Why Use AD_ZD.GRANT_PRIVS? In Oracle EBS R12.2, all grants should be performed using the AD_ZD.GRANT_PRIVS procedure rather than the traditional GRANT statement.  The reason is simple: the GRANT statement directly modifies objects in the database, and this can invalidate them in the current edition. Invalidations during runtime can cause service interruptions, which is unacceptable in a live system. Syntax for Granting and Revoking Privileges The AD_ZD package provides two p...
Read more