Role Transitions in Oracle Data Guard
Learn about Role Transitions in Oracle Data Guard β including switchovers, failovers, triggers, and how to use Flashback Database effectively.
Seamlessly switch roles between primary and standby databases to ensure high availability and disaster recovery.
What is a Role Transition?
In Oracle Data Guard, a Role Transition is when the role of a Primary database and one of its Standby databases is swapped or promoted, depending on the situation:
- π Switchover β Planned, no data loss
- β Failover β Unplanned, recovery after failure
1. Introduction to Role Transitions
Oracle Data Guard allows either:
- The Primary database to become a Standby, and
- A Standby to take over as the Primary.
This helps maintain zero or minimal downtime during:
- Maintenance
- Disaster Recovery
- Planned migration or upgrades
2. Preparing for a Role Transition
Before performing a role transition:
β Ensure:
- The standby is fully synchronized
- All configurations are correct
- Flashback Database is enabled (for reversibility)
- Monitoring tools (like
dgmgrlor OEM) are in place
Use:
SELECT SWITCHOVER_STATUS FROM V$DATABASE;If the result is TO STANDBY or TO PRIMARY, it’s ready.
3. Choosing the Target Standby for Role Transition
If you have multiple standby databases, choose one based on:
- βοΈ Sync level (real-time or lagging?)
- βοΈ Location (same region or DR site?)
- βοΈ Performance capacity
- βοΈ Recovery time objective (RTO)
π Use Data Guard Broker (dgmgrl) to get health and sync status of each standby.
π 4. Switchovers
A planned role transition β no data loss.
- Performed when both primary and standby are healthy
- Reversible
- Used during patching, upgrades, or testing DR setups
β¨ Steps:
- Verify readiness
- Issue switchover command
- Monitor the transition
- Confirm new roles
DGMGRL> SWITCHOVER TO standby_db;5. Failovers
An unplanned role transition β usually due to primary failure.
- Performed when the primary is not accessible
- May involve data loss (depending on protection mode)
- Cannot automatically go back to original state without reinstating
Steps:
- Confirm primary is inaccessible
- Promote the best standby
- Reinstate the original primary later (if recoverable)
DGMGRL> FAILOVER TO standby_db;βοΈ 6. Role Transition Triggers
Role transitions can be:
| Trigger Type | Example Scenario |
|---|---|
| Manual | DBA initiates switch/failover during patching |
| Automatic | Data Guard Fast-Start Failover (FSFO) detects primary crash |
| Scripted | Via shell or OEM automation |
7. Transitions with Physical Standby
π Switchover to Physical Standby:
- MRP must be stopped
- Redo apply must be in sync
- Very fast transition
β Failover to Physical Standby:
- Use
ACTIVATE STANDBY DATABASE - May require applying missing logs
- Reinstate primary if Flashback is enabled
8. Transitions with Logical Standby
π Switchover to Logical Standby:
- SQL Apply must be stopped
- May require checking data compatibility
- More flexible, but slightly slower
β Failover to Logical Standby:
- Use
ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE - Ensure standby is fully caught up
β οΈ Not all failovers are supported for Logical Standby if major DDL differences exist.
9. Using Flashback Database After Role Transition
Flashback allows you to reverse role transitions quickly:
| Scenario | Use Flashback? | Command Example |
|---|---|---|
| After Switchover | β Yes | FLASHBACK DATABASE TO SCN; |
| After Unsuccessful Failover | β Yes | Restore original primary without rebuild |
| Flashback for testing | β Yes | Safely simulate transitions |
Requirements:
- Flashback must be enabled
- Fast recovery area configured
β Summary Table
| Operation | Planned? | Data Loss? | Used When | Reversible? |
|---|---|---|---|---|
| Switchover | β Yes | β No | Maintenance, patching, testing | β Yes |
| Failover | β No | β οΈ Possible | Crash, corruption, DR failover | β No (unless flashback enabled) |