Examine the Data Guard configuration: Identify two poss…

Examine the Data Guard configuration:
Identify two possible reasons for this error.

Examine the Data Guard configuration:
Identify two possible reasons for this error.

A.
The FastStartFaiIoverTarget property is not set on Sheep.

B.
The FastStartFaiIoverTarget property is not set on Dogs.

C.
The FastStartFaiIoverTarget property is not set on DogsFSI.

D.
The LogXptMode property is set to ASYNC on Dogs.

E.
The RedoRoutes property is not set on Dogs

F.
The RedoRoutes property is not set on DogsFSI



Leave a Reply 8

Your email address will not be published. Required fields are marked *


edge

edge

Hi Below the picture (Id id not respect case).

dgmgrl > show configuration
configuration animals
Protection Mode : MaxAvailability

databases
dogs- Primary database
dogsfsi- Far Sync
sheep. Physical standby database

Fast-start failover: Disabled
configuratio status: Disabled

An attempt to enable fast-start failover raises an error

dgmgrl> enable fast-start failover
Error- ORA-16693: requirements not met for enabling fast-start failover

JFK

JFK

With some minor corrections:

DGMGRL > show configuration;

Configuration-Animals

Protection Mode: MaxAvailability

Databases:
dogs- Primary database
dogsfsi- Far Sync
sheep- Physical standby database

Fast-Start Failover: DISABLED

Configuration status: SUCCESS

An attempt to enable fast-start failover raises an error

DGMGRL> enable fast-start failover;
Error: ORA-16693: requirements not met for enabling fast-start failover
Failed.

JFK

JFK

D:
https://docs.oracle.com/database/121/DGBKR/dbresource.htm#g1046794
if you plan to set the overall Oracle Data Guard configuration to operate in maximum availability mode, you must use the EDIT DATABASE command to set the SYNC mode for redo transport services. For example:

DGMGRL> EDIT DATABASE ‘South_Sales’ SET PROPERTY LogXptMode=’SYNC’;

Additional info:
https://docs.oracle.com/database/121/DGBKR/cli.htm#DGBKR520
Use the EDIT CONFIGURATION command to upgrade the broker configuration protection mode.
If the configuration is disabled when you enter this command, the actual protection mode change is not applied until you enable the configuration with the ENABLE CONFIGURATION command. The broker will not allow you to enable the configuration if it does not find a standby database in the configuration that can support the requirements of the protection mode.

Nelz

Nelz

D and E
https://docs.oracle.com/database/121/DGBKR/sofo.htm#DGBKR392
Ensure that the standby database you choose to be the target of fast-start failover has its LogXptMode property set to either SYNC or FASTSYNC if you wish to enable fast-start failover in maximum availability mode, or to ASYNC if you wish to enable fast-start failover in maximum performance mode. The current primary database must have its LogXptMode property set accordingly and must have standby redo logs configured. Alternatively, use the RedoRoutes property to configure the redo transport mode for the target standby and the database currently in the primary role

Nelz

Nelz

A is incorrect because there is only one standby database. YOu dont have to set the property FastStartFailoverTarget
If there is more than one standby database in the configuration, you must explicitly set the FastStartFailoverTarget property on the primary database to select a target standby database. When enabling fast-start failover, the broker verifies that the property indicates an existing standby, and then reciprocally sets the standby database’s FastStartFailoverTarget property to the primary database. (Note that the target standby cannot be a far-sync standby. However the target can receive redo from a far sync instance.)

PK

PK

For “MaxAvailability” protection mode must be chosen transport SYNC or FASTSYNC.
With Far Sync standby in the configuration the redo shipping from primary must be SYNC (SYNC/AFFIRM) of FASTSYNC (SYNC/NOAFFIRM).
From Far Sync to terminal standby shipping can by ASYNC. Even though that Far Sync is shipping to terminal standby in ASYNC whole configuration meet demands for protection mode “MaxAvailability”.

From above is understood that LogXptMode property for primary db dogs must be set to SYNC or FASTSYNC (directly to physical standby sheeps or to Far Sync standby dogsfsi).
It will throw error if it is set to ASYNC thus D is correct.

Error is reported also if FastStartFaiIoverTarget property is not set correctly. But according to documentation for this broker parameter it is set automatically.
FastStartFaiIoverTarget –
If only one physical or logical standby database exists, then the broker selects that as the default value for this property on the primary database when fast-start failover is enabled.
If more than one physical or logical standby database exists, then the broker selects one based on the order in which they are specified in the property definition. Targets are verified when fast-start failover is enabled.
For the target standby database, the broker automatically selects the current primary database as the value for this property when fast-start failover is enabled.

So from above info about FastStartFaiIoverTarget is obvious that it doesn’t need to be set at all as we have one Far Sync standby and one Physical standby. It will be configured automatically during enabling of configuration, thus A, B and C are incorrect.

RedoRoutes property can be used to define complex redo shipping paths. It can be used to define cascaded standby databases in dataguard.
In this example it would be handy to use them when shipping redo from Primary db dogs to Far Sync dogsfsi and from there to Physical Standby sheep.
For such scenario we must setup RedoRoutes on Primary and Far Sync standby.
DGMGRL> EDIT DATABASE ‘dogs’ SET PROPERTY RedoRoutes='(LOCAL : dogsfsi SYNC)’;
DGMGRL> EDIT FAR_SYNC ‘dogsfsi’ SET PROPERTY RedoRoutes='(dogs : sheep’);
This would be working until switchover from Primary to Physical Standby. To make it work even after switchover it is necessary to define RedoRoutes for redo shipping from sheeps to dogsfsi and from them to dogs.
DGMGRL> EDIT DATABASE ‘sheep’ SET PROPERTY RedoRoutes='(LOCAL : dogsfsi SYNC)’;
DGMGRL> EDIT FAR_SYNC ‘dogsfsi’ SET PROPERTY RedoRoutes=(‘dogs : sheep)(sheep : dogs)’;

So if there would be such configuration in this case then E and F are necessary to make it work as cascaded standby.
And I would say also correct definition of RedoRoutes on sheeps standby is necessary to make if working after switchover.
If Far Sync is not configured as cascaded standby source for Physical Standby sheep then E and F are not necessary.
FSFO can be enabled as there is one Primary and one Physical Standby. The Far Sync in such configuration is there just for nothing.

YK6

YK6

@PK
5.5.1 Prerequisites for Enabling Fast-Start Failover

Ensure that the standby database you choose to be the target of fast-start failover has its LogXptMode property set to either SYNC or FASTSYNC if you wish to enable fast-start failover in maximum availability mode, or to ASYNC if you wish to enable fast-start failover in maximum performance mode. The current primary database must have its LogXptMode property set accordingly and must have standby redo logs configured.

Alternatively, use the RedoRoutes property to configure the redo transport mode for the target standby and the database currently in the primary role.

seems, that only RedoRoutes can be set on primary (without touching LogXpTMode) and FSFO will be work in this configuration.
So, E is correct