In this Article I will show you the result of performing Data Guard Broker Role Operations when we have a Snapshot Standby Database in our configuration. Usually when we have a Physical Standby in our Data Guard Configuration we don't have any issue, assuming that all the validations of connectivity between database are properly performed, however to perform Role Operations when using Snapshot Standby Database is not usual, but we can be in that case. Let me show you my environment:
- db12102 - Primary Database (db1)
- db12102s - Snapshot Standby Database (db1s)
And my Broker configuration looks this way:
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1 - Primary database
db1s - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS(status updated 59 seconds ago)
Let's proceed to convert our Physical Standby Database to Snapshot Standby Database, that way we will have the proper configuration to perform our role operations:
DGMGRL> convert database 'db1s' to snapshot standby;
Converting database "db1s" to a Snapshot Standby database, please wait...
Database "db1s" converted successfully
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1 - Primary database
db1s - Snapshot standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 24 seconds ago)
Before to perform any Role Operation with Broker, like Switchover or Failover, we should validate both databases, I recommend the following note to perform a good validation before to perform these operations:
12c Dataguard Switchover Best Practices using DGMGRL(Dataguard Broker Command Prompt) (Doc ID 1582837.1)
After performing our validations, we can proceed to execute our first Role Operation: Switchover.
Switchover operation with Snapshot Standby Database:
DGMGRL>
DGMGRL> switchover to 'db1s';
Performing switchover NOW, please wait...
Error: ORA-16831: operation not allowed on this member
Failed.
Unable to switchover, primary database is still "db1"
This result was expected, As the note "11g Using Snapshot Standby Database. (Doc ID 443720.1)" says, we cannot perform a Switchover Operation with a Snapshot Standby Database. Unfortunately, the note has not updated to 12c yet. The note says also we cannot perform Failover with Snapshot Standby Database, let's confirm that:
The first step before to perform a Failover operation is to be connected to the Standby Database. In the configuration of this article, the Primary Database is available. We could make a mistake and connect to Primary Database instead of Standby Database, if you do so, you will receive the following error:
[oracle@db12102s ~]$ dgmgrl sys/manager1@db1
DGMGRL> failover to 'db1s';
Converting database "db1s" to a Physical Standby database, please wait...
Error: ORA-16600: not connected to target standby database for failover
Failed.
Failed to convert database "db1s"
DGMGRL>
And that error does not mean a failover cannot be performed, as the Note (Doc ID 443720.1) explains, the error received says basically that it doesn't make sense to be connected to the Primary Database if what we want to do is a Failover, when we are doing a Failover, the primary Database is suppose to be destroyed or unrecoverable, that's why. For example, in the following image, We perform a Failover when our Primary Site (San Francisco) is unrecoverable and Boston (Standby Site) has to provide the service:
Said that, let's proceed (connected to Snapshot Standby Database):
DGMGRL> failover to 'db1s';
Converting database "db1s" to a Physical Standby database, please wait...
Operation requires shut down of instance "db1" on database "db1s"
Shutting down instance "db1"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires start up of instance "db1" on database "db1s"
Starting instance "db1"...
ORACLE instance started.
Database mounted.
Continuing to convert database "db1s" ...
Database "db1s" converted successfully
Performing failover NOW, please wait...
Failover succeeded, new primary is "db1s"
DGMGRL>
So it seems the note (Doc ID 443720.1) that up to date is in 11g, has to be updated for 12c, because clearly we saw that we can perform Failover Operations if our Standby is a Snapshot Standby Database. Let's confirm that:
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1s - Primary database
db1 - Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 51 seconds ago)
DGMGRL>
The configurations looks successfully. Now the Primary Database is "db1s" which is the former Snapshot Standby Database. And the former Primary Database now is disabled, and DGMGRL says that it must be reinstated (Using Flashback to bring it back as Standby). Anyways, we have a new Primary Database now:
SQL> select name, open_mode, db_unique_name, database_role from v$database;
NAME OPEN_MODE DB_UNIQUE_NAME DATABASE_ROLE
------ ----------- --------------- ----------------
DB1 READ WRITE db1s PRIMARY
What happened? let's take a look in the alert log of the former Snapshot Standby Database and I will include a couple of comments with blue color:
Shutting down instance (immediate) -- Request to shutdown the instance.
...
Thread 1 closed at log sequence 1
Successful close of redo thread 1
Completed: alter database CLOSE NORMAL
alter database DISMOUNT
Shutting down archive processes
...
Completed: alter database DISMOUNT
...
Shutting down Data Guard Broker processes
Completed: Data Guard Broker shutdown
...
Instance shutdown complete
...
Starting ORACLE instance (normal) (OS id: 12735) -- The instance is started again
...
alter database mount -- The database is mounted.
...
Database mounted in Exclusive Mode -- Mounted but as exclusive...
Lost write protection mode set to "typical"
...
Starting Data Guard Broker (DMON)
...
alter database convert to physical standby -- The magic! before Failover the Snapshot Standby is converted to Physical Standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (db1)
Flashback Restore Start -- Flashback is used to convert it to Physical Standby.
Flashback Restore Complete
Drop guaranteed restore point
Stopping background process RVWR
Deleted Oracle managed file /data/db1/DB1S/flashback/o1_mf_cz0797vb_.flb
Deleted Oracle managed file /data/db1/DB1S/flashback/o1_mf_cz079bbm_.flb
Guaranteed restore point dropped -- restore point created when we convert it to Snapshot Standby was deleted, as expected.
Clearing standby activation ID 1517972155 (0x5a7a6abb)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
...
Physical Standby Database mounted.
CONVERT TO PHYSICAL STANDBY: Complete - Database mounted as physical standby
Completed: alter database convert to physical standby
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT NODELAY --After convert it to Physical Standby, Oracle applies all the logs received and not applied while it was in Snapshot Standby Database.
...
Media Recovery Log /data/db1/DB1S/archivelog/2016_10_01/o1_mf_1_125_cz07g3pd_.arc
Media Recovery Log /data/db1/DB1S/archivelog/2016_10_01/o1_mf_1_126_cz07g3ps_.arc
Media Recovery Log /data/db1/DB1S/archivelog/2016_10_01/o1_mf_1_127_cz07qhrf_.arc
Media Recovery Log /data/db1/DB1S/archivelog/2016_10_01/o1_mf_1_128_cz07qhsg_.arc
Media Recovery Log /data/db1/DB1S/archivelog/2016_10_01/o1_mf_1_129_cz07qhsw_.arc
Media Recovery Log /data/db1/DB1S/archivelog/2016_10_01/o1_mf_1_130_cz080vtk_.arc
Media Recovery Log /data/db1/DB1S/archivelog/2016_10_01/o1_mf_1_131_cz089zpp_.arc
Media Recovery Log /data/db1/DB1S/archivelog/2016_10_01/o1_mf_1_132_cz08bk2y_.arc
Media Recovery Waiting for thread 1 sequence 133
...
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT NODELAY --The recovery finishes and now it's ready for next step....
Data Guard Broker: A failover will now be attempted -- .... which is perform the Failover.
ALTER DATABASE FAILOVER TO db1s
Media Recovery Start: Managed Standby Recovery (db1)
...
Primary database is in MAXIMUM PERFORMANCE mode
...
Media Recovery Log /data/db1/DB1S/archivelog/2016_10_01/o1_mf_1_133_cz08bp3v_.arc
Media Recovery Waiting for thread 1 sequence 134 (in transit)
...
Media Recovery Complete (db1)
...
Resetting standby activation ID 1506922624 (0x59d1d080)
ALTER DATABASE SWITCHOVER TO PRIMARY (db1) -- A switchover inside a Failover?
...
Standby became primary SCN: 3217112
Setting recovery target incarnation to 4
Switchover: Complete - Database mounted as primary
Completed: ALTER DATABASE FAILOVER TO db1s -- Failover operation completed successfully! [:D]
ALTER DATABASE OPEN -- And now the database is open.
Data Guard Broker initializing...
Assigning activation ID 1517964988 (0x5a7a4ebc)
...
Completed: ALTER DATABASE OPEN
...
Failover succeeded. Primary database is now DB1S.
Follow me:
