In this article we will analyze the behavior of Data Guard Broker when we have two Standby Databases and we are performing Role Operations. I will try to cover all the scenarios, I will do some examples involving Physical Standby Databases, Snapshot Standby Databases and Logical Standby Databases. The focus of this article is to show you the result state of every database inside the Data Guard Configuration after a role operation, we will see that in some cases we will destroy the others Standby Databases when we perform even a Switchover, when you are aware of all this and you have a Primary Database that maintenances many Standby Databases you will be carefully with every role operation. The scenarios that we will cover in this article are the following:
- Switchover with 2 Physical Standby Databases
- Failover with 2 Physical Standby Databases
- Failover with 1 Physical Standby Database and 1 Snapshot Standby Database
- Switchover with 1 Physical Standby Database and 1 Logical Standby Database
- Failover with 1 Physical Standby Database and 1 Logical Standby Database
Switchover with 2 Physical Standby Databases
We will start with a healthy configuration:
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1 - Primary database
db1s - Physical standby database
db1d - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS(status updated 49 seconds ago)
Performing the switchover:
DGMGRL> switchover to 'db1d';
Performing switchover NOW, please wait...
Operation requires a connection to instance "db1" on database "db1d"
Connecting to instance "db1"...
Connected as SYSDBA.
New primary database "db1d" is opening...
Oracle Clusterware is restarting database "db1" ...
Switchover succeeded, new primary is "db1d"
A switchover involving only Physical Standby databases is the most transparently operation in Data Guard Broker, as you see below all the others Physical Databases are healthy, sync, and working normally:
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1d - Primary database
db1 - Physical standby database
db1s - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS(status updated 55 seconds ago)
DGMGRL>
Failover with 2 Physical Standby Databases
Starting with a healthy Configuration:
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1 - Primary database
db1s - Physical standby database
db1d - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 32 seconds ago)
DGMGRL>
Performing the Failover:
DGMGRL> failover to 'db1d';
Performing failover NOW, please wait...
Failover succeeded, new primary is "db1d"
As we see below, the operation was between 'db1d' and 'db1', the other Standby Database is healthy, working normally, it was not impacted at all. Of course, we see "db1' in disabled Status and a message saying that database must be reinstate and this is because we performed a failover, that database (former Primary) is suppose to be destroyed. It is an expected result.
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1d - Primary database
db1- Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
db1s - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS(status updated 68 seconds ago)
If we want to use again the former Primary all what we have to do is reinstate it:
DGMGRL> reinstate database 'db1';
Reinstating database "db1", please wait...
Oracle Clusterware is restarting database "db1" ...
Continuing to reinstate database "db1" ...
Reinstatement of database "db1" succeeded
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1d - Primary database
db1 - Physical standby database
db1s - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS(status updated 11 seconds ago)
Failover with 1 Physical Standby Database and 1 Snapshot Standby Database
In my last article called "Role Operations with Snapshot Standby 12c" I also explained a failover with a Snapshot Standby Database, in this section I will show only the result:
DGMGRL> failover to 'db1d';
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1d - Primary database
db1 - Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
db1s - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS(status updated 82 seconds ago)
DGMGRL>
As my last article says, in 12c we can perform a Failover to a Snapshot Standby Database, and the other Physical Standby Database was not impacted.
Conclusion:Performing Role Operations when we are using only Physical Standby Databases is one of the most transparently Data Guard Operation, all the others Standby Databases are not impacted by a Switchover or Failover. When we are performing a Failover only the former Primary Database has the state "disabled" after the failover.
Switchover with 1 Physical Standby Database and 1 Logical Standby Database
Now we will work with the following Scenario:
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1 - Primary database
db1s - Physical standby database
db1d - Logical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS(status updated 31 seconds ago)
Performing the Switchover:
DGMGRL> switchover to 'db1d';
Performing switchover NOW, please wait...
Switchover succeeded, new primary is "db1d"
Look at this result, it is very interesting, When we perform a Switchover to a Logical Standby Database, that operation impacts all the others Physical Standby Databases making them Disabled and basically destroyed because we must re-create them. Those Physical Standby Databases must be re-recreated after that operation. The former Primary Database becomes Logical Standby because that is the Standby's type of the database we are doing the switchover with. It makes sense all the Physical Standby Databases become Disabled, because the database that became Primary Database was a Logical Standby and that means that it was not physically a copy of the Physical Standby. Since the Physical standby cannot receive and apply blocks from the the new Primary (because are not a physical copy) oracle perform the right decision: making them disabled, and it asks to recreate them.
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1d - Primary database
db1 - Logical standby database
db1s - Physical standby database (disabled)
ORA-16795: the standby database needs to be re-created
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 1475389356 seconds ago)
It is interesting that we can enable it without re-create it:
DGMGRL> enable database 'db1s';
Enabled.
DGMGRL>
However it cannot be used again. We must recreate it first:
DGMGRL> show database verbose 'db1s';
Database Error(s):
ORA-16700: the standby database has diverged from the primary database
BTW, I had to re-create it [:(] in order to show you the next and last example [:)]
Once you have recreated it, all what you have to do is enable it, you don't have to remove that Physical Database and add it back. Just re-create it and enable it.
Failover with 1 Physical Standby Database and 1 Logical Standby Database
Starting with a healthy Configuration. When you are performing a Failover, be sure that you are connected to the Standby Database that you are suppose to failover to, in this case is "db1d".
[oracle@db12102d ~]$ dgmgrl sys/manager1@db1d
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1 - Primary database
db1s - Physical standby database
db1d - Logical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 9816 seconds ago)
Performing Failover:
DGMGRL> failover to 'db1d';
Performing failover NOW, please wait...
Failover succeeded, new primary is "db1d"
Only interesting things here, after a Failover we have a mix of the result that we have reviewed before. Firstable, the Former Primary becomes Disabled and oracle asks us to reinstate it, this is a expected result after a Failover operation, since the former Primary is suppose to be destroyed or unrecoverable. And in the other hand we have a Disabled Physical Standby database and also Oracle asks us to re-create them. Basically we destroyed all our Physical Databases and also the Primary Database is suppose to be destroyed (that's why we decided to do a Failover), this should be the worst case in your DBA life [:D] . So we have to reinstate the former Primary Database if we want to have a healthy "Logical Standby Database" and also we have to recreate all our Physical Standby because the new Primary Database (former Logical Standby Database) is not a physical copy.
DGMGRL> show configuration;
Configuration - NuvolaConfig
Protection Mode: MaxPerformance
Members:
db1d - Primary database
db1 - Logical standby database(disabled)
ORA-16661: the standby database needs to be reinstated
db1s - Physical standby database(disabled)
ORA-16795: the standby database needs to be re-created
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 13 seconds ago)
DGMGRL>
Follow me:
