Examine the Data Guard configuration:
DGMGRL> show configuration;
Configuration -Animals Protection Nlode MaxAvaiIabiIity
Databases
dogs- Primary database
cats- Snapshot standby database
sheep- Snapshot standby database
Fast-Start Failover DISABLED
Configuration Status: ORA-01034: ORACLE not available ORA-16625: cannot reach database “dogs’1 DGM- 17017 unable to determine configuration status
You wish to perform a failover to Sheep
Which command, or sequence of commands, should you issue to the broker before executing “failover to sheep”, using the broker?
A.
DGMGRL> convert database cats to physical standby,
B.
DGMGRL> convert database sheep to physical standby;
C.
DGMGRL> convert database sheep to physical standby; DGMGRL> convert database cats to physical standby;
D.
DGMGRL>edit configuration set protection mode as maxperformance; DGMGRL> convert database sheep to physical standby;
E.
None, because you can directly failover to a Snapshot Standby Database
why not just B?
tested in labenvironment…
DGMGRL> show configuration;
Configuration – config2
Protection Mode: MaxAvailability
Databases:
prim – Primary database
stdby2 – Snapshot standby database
stdby1 – Snapshot standby database
Fast-Start Failover: DISABLED
Configuration Status:
ORA-12543: TNS:destination host unreachable
ORA-16625: cannot reach database “prim”
DGM-17017: unable to determine configuration status
DGMGRL>
DGMGRL> failover to stdby1;
Converting database “stdby1” to a Physical Standby database, please wait…
Operation requires shutdown of instance “STDBY1” on database “stdby1”
failover will do the convert…, only for the new primary.
If we test it with a manual convert
DGMGRL> convert database stdby1 to physical standby;
Converting database “stdby1” to a Physical Standby database, please wait…
Error: ORA-12541: TNS:no listener
Error: ORA-16625: cannot reach database “prim”
Failed.
Failed to convert database “stdby1”
answer d
DGMGRL> edit configuration set protection mode as maxperformance;
Error: ORA-12541: TNS:no listener
Error: ORA-16625: cannot reach database “prim”
so actually E…
which is confirmed in https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=131691762194029&id=2058653.1&displayIndex=4&_afrWindowMode=0&_adf.ctrl-state=4gqx2fcji_77#FIX
In case of loss of primary site in an Oracle Data Guard configuration, it is possible to failover to either a physical or a snapshot standby database. But failing over to a snapshot standby database will require more time because the broker must first convert it back to a physical standby database.
right answer: E
also in the manual: https://docs.oracle.com/cd/B19306_01/server.102/b14230/sofo.htm#BCGBFFIH
5.4 Manual Failover
You can convert a standby database to a primary database when the original primary database fails and there is no possibility of recovering the primary database in a timely manner. This is known as a manual failover. There may or may not be data loss depending upon whether your primary and target standby databases were transactionally consistent at the time of the primary database failure. The word manual is used to contrast this type of failover with a fast-start failover (described in Section 5.5).
Correct E.
Note:
If the failover target is a physical or snapshot standby database, the original primary database must be reinstated or re-created in order to be a standby database for the new primary database.
E is correct. I have tested in lab.
A, B, C, D are incorrect
Because in order to issue CONVERT or EDIT CONFIGURATION commands, broker must communicate to the Primary database “dogs” which is currently not available.
In a non-Broker configuration, you must convert the snapshot standby database to physical standby using manual methods.
Here Data Guard Broker is used so you can directly failover to a Snapshot Standby Database and it will perform the failover to “Sheep”. Once the failover is complete you must reinstate old primary database “dogs” by 1) startup mount “dogs”, 2) Connect to new primary database “Sheep” and issue “reinstate database dogs”. You might need to change the protection mode afterwards, if required if the LogXptMode was not set originally otherwise it will report a Warning, however, data guard will function as expected.
DGMGRL> show configuration;
Configuration – Animals
Protection Mode: MaxAvailability
Members:
dogs – Primary database
Error: ORA-01034: ORACLE not available
cats – Snapshot standby database
sheep – Snapshot standby database
Fast-Start Failover: DISABLED
Configuration Status:
ERROR (status updated 0 seconds ago)
DGMGRL> convert database cats to physical standby;
Converting database “cats” to a Physical Standby database, please wait…
Error: ORA-01034: ORACLE not available
Error: ORA-16625: cannot reach database “dogs”
Failed.
Failed to convert database “cats”
DGMGRL> convert database sheep to physical standby;
Converting database “sheep” to a Physical Standby database, please wait…
Error: ORA-01034: ORACLE not available
Error: ORA-16625: cannot reach database “dogs”
Failed.
Failed to convert database “sheep”
DGMGRL> edit configuration set protection mode as maxperformance;
Error: ORA-01034: ORACLE not available
Error: ORA-16625: cannot reach database “dogs”
Failed.
DGMGRL> failover to sheep;
Converting database “sheep” to a Physical Standby database, please wait…
Operation requires shut down of instance “sheep” on database “sheep”
Shutting down instance “sheep”…
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires start up of instance “sheep” on database “sheep”
Starting instance “sheep”…
ORACLE instance started.
Database mounted.
Continuing to convert database “sheep” …
Database “sheep” converted successfully
Performing failover NOW, please wait…
Failover succeeded, new primary is “sheep”
THanks for trying it !!