What you will learn
A planned switchover exchanges roles while preserving Data Guard. It differs from emergency failover and retiring the old site. The historical notes mixed these operations; this lesson keeps the former primary as a standby and validates the application before any later decommission.
Before you begin
Use an isolated Oracle Database 19c Linux lab with a certified patch level. Names host1.sample.com and host2.sample.com identify distinct lab hosts; replace them consistently with your own addresses. Use oracle for database software and grid for Grid Infrastructure where ownership is separated. Connect through local operating-system authentication or a configured wallet; no example includes a password. Preserve a tested backup and record the database identity before changes. Complete the standby lab with DEMO_PRI and DEMO_STBY. These unique names remain stable after roles reverse. Prepare a maintenance window, write drain, role-based services, restart connectivity, and a tested switchback plan.
1. Check broker readiness
SHOW CONFIGURATION;
SHOW DATABASE VERBOSE DEMO_PRI;
SHOW DATABASE VERBOSE DEMO_STBY;
VALIDATE DATABASE VERBOSE DEMO_STBY;
Run in DGMGRL connected to the primary. Inspect transport, apply, protection mode, and restart requirements. Resolve all validation findings. Maximum archived sequence numbers alone can mislead across threads or resetlogs incarnations.
2. Commit an application marker
CREATE TABLE dg_probe (probe_id NUMBER PRIMARY KEY,note VARCHAR2(50));
INSERT INTO dg_probe VALUES (1,'before switchover');
COMMIT;
Create this fixture once in the lab application schema. Drain ordinary writes and coordinate jobs that must not run on both sites. Record the final marker and ensure clients can reconnect.
3. Switch and verify roles
SWITCHOVER TO DEMO_STBY;
SHOW CONFIGURATION;
SHOW DATABASE VERBOSE DEMO_PRI;
SHOW DATABASE VERBOSE DEMO_STBY;
SELECT db_unique_name,database_role,open_mode FROM v$database;
Inspect both databases. For Clusterware-managed deployments also inspect SRVCTL role, startup, and service state; do not overwrite broker-managed state using an old script.
4. Exercise the new primary
SELECT * FROM dg_probe WHERE probe_id=1;
INSERT INTO dg_probe VALUES (2,'after switchover');
COMMIT;
Connect through the application service. Confirm fresh redo reaches the former primary. Check tempfiles, scheduled jobs, backups, and monitoring before ending the window.
5. Read the example output
The following is illustrative, normalized output, not a transcript from a customer system. Values depend on your release and lab state.
DB_UNIQUE_NAME DATABASE_ROLE OPEN_MODE
DEMO_STBY PRIMARY READ WRITE
DEMO_PRI PHYSICAL STANDBY MOUNTED
The names have not changed; their roles have.
Verify the result
Both rows are present on the new primary, applications reconnect, and reverse transport/apply is current. Verify the standby remains recoverable and schedule a backup under the new role configuration.
Troubleshooting
For an incomplete transition inspect actual roles before retrying. Do not substitute FAILOVER for a failed planned switchover without a separate recovery decision. Successful role change with failed connections suggests service or client issues.
Recovery and next steps
Switch back only after the new standby catches up and passes validation. Preserve standby redo logs and broker configuration. Retiring the former site is a separate task after replacement protection is established.