Fast-Start Failover An Overview In Dataguard Environment
=============== =============== =============== =============== =============== ==
This article describes the automatic fast start failover configuration and the conditions for trigerring a fast start failover in dataguard environment .
In Faststart failover dataguard configuration if the primary database becomes unavailable, the observer confirms with the target standby database that the primary production database is unavailable and that the target standby
database is synchronized with the production database, if so, initiates a faststart failover to the target standby database if there is a gurantee that no data will be lost.
Minimum requirements for enabling Fast-Start Failover
- The Data Guard configuration must be in MaxAvailability protection mode.
- The LogXptMode property for both the primary database and the Fast-Start Failover target standby database must be SYNC.
- The primary database and the Fast-Start Failover target standby database must both have flashback enabled.
- No valid target standby database was specified in the primary database's FastStartFailov erTarget property prior to the attempt to enable Fast-Start Failover, and more than one standby database exists in the Data Guard configuration.
DGMGRL for Linux: Version 10.2.0.1.0 - 64bit Production
Copyright (c) 2000, 2005, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/passwd
Connected.
DGMGRL> create configuration 'ORCL' as
> primary database is 'ORCL_DB'
> connect identifier is 'ORCL.world';
Configuration "ORCL" created with primary database "ORCL_DB"
DGMGRL> show configuration
Configuration
Name: ORCL
Enabled: NO
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
ORCL_DB - Primary database
Current status for "ORCL":
DISABLED
DGMGRL> add database 'STNDBY_DB' as
> connect identifier is STNDBY_DB maintained as physical;
Database "STNDBY_DB" added
DGMGRL> show database verbose 'STNDBY_DB';
Database
Name: STNDBY_DB
Role: PHYSICAL STANDBY
Enabled: NO
Intended State: OFFLINE
Instance(s):
orcl
Properties:
InitialConnectI dentifier = 'STNDBY_DB'
LogXptMode = 'ASYNC'
Dependency = ''
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '10'
NetTimeout = '180'
LogShipping = 'ON'
PreferredApplyI nstance = ''
ApplyInstanceTi meout = '0'
ApplyParallel = 'AUTO'
StandbyFileMana gement = 'MANUAL'
ArchiveLagTarge t = '0'
LogArchiveMaxPr ocesses = '2'
LogArchiveMinSu cceedDest = '1'
DbFileNameConve rt = ''
LogFileNameConv ert = ''
FastStartFailov erTarget = ''
StatusReport = '(monitor)'
InconsistentPro perties = '(monitor)'
InconsistentLog XptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'localhost.loca ldomain'
SidName = 'orcl'
LocalListenerAd dress = '(ADDRESS=(PROT OCOL=tcp)(PORT= 1540)(HOST=loca lhost.localdoma in))'
StandbyArchiveL ocation = '/u04/oradata/arch'
AlternateLocati on = ''
LogArchiveTrace = '0'
LogArchiveForma t = '%t_%s_%r.dbf'
LatestLog = '(monitor)'
TopWaitEvents = '(monitor)'
Current status for "STNDBY_DB" :
DISABLED
DGMGRL> enable configuration
Enabled.
DGMGRL> EDIT DATABASE 'ORCL_DB' SET PROPERTY FastStartFailov erTarget = 'STNDBY_DB';
Property "faststartfailo vertarget" updated
DGMGRL> EDIT DATABASE 'STNDBY_DB' SET PROPERTY FastStartFailov erTarget = 'ORCL_DB';
Property "faststartfailo vertarget" updated
DGMGRL> EDIT DATABASE 'ORCL_DB' SET PROPERTY 'LogXptMode'='S YNC';
Property "LogXptMode " updated
DGMGRL> EDIT DATABASE 'STNDBY_DB' SET PROPERTY 'LogXptMode'='S YNC';
GMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY ;
Operation requires shutdown of instance "ORCL" on database "ORCL_DB"
Shutting down instance "orcl"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "orcl" on database "ORCL_DB"
Starting instance "orcl"...
ORACLE instance started.
Database mounted.
-Here check for UNDO renention and flashback database ,enable fast start failover and start observer from DGMGRL
DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.
DGMGRL> START OBSERVER;
Observer started
DGMGRL> show configuration verbose
Configuration
Name: ORCL
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
ORCL_DB - Primary database
STNDBY_DB - Physical standby database
- Fast-Start Failover target
Fast-Start Failover
Threshold: 30 seconds
Observer: localhost.local domain
-Events that may trigger a fast start failover are instance failure ,datafile taken offline due to IO errors ,shutdown abo
rt /others ...,here a shutdown abort is initated in the primary instance .
Observer log:-
Current status for "ORCL":
SUCCESS
18:46:48.69 Wednesday, January 09, 2008
Initiating fast-start failover to database "STNDBY_DB" ...
Performing failover NOW, please wait...
Failover succeeded, new primary is "STNDBY_DB"
18:47:19.09 Wednesday, January 09, 2008
Alert Log:-
RFS[7]: Possible network disconnect with primary database
Wed Jan 9 18:46:15 2008
RFS[6]: Possible network disconnect with primary database
Wed Jan 9 18:46:15 2008
RFS[8]: Possible network disconnect with primary database
Wed Jan 9 18:46:48 2008
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE
Wed Jan 9 18:46:48 2008
Terminal Recovery: Stopping real time apply
Wed Jan 9 18:46:49 2008
MRP0: Background Media Recovery cancelled with status 16037
Wed Jan 9 18:46:49 2008
Errors in file /u03/app/admin/oracle/admin/ORCL/bdump/orcl_mrp0_18084 .trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Wed Jan 9 18:46:49 2008
Errors in file /u03/app/admin/oracle/admin/ORCL/bdump/orcl_mrp0_18084 .trc:
ORA-16037: user requested cancel of managed recovery operation
Wed Jan 9 18:46:49 2008
MRP0: Background Media Recovery process shutdown (orcl)
Wed Jan 9 18:46:49 2008
Terminal Recovery: Stopped real time apply
Wed Jan 9 18:46:49 2008
Attempt to do a Terminal Recovery (orcl)
Wed Jan 9 18:46:49 2008
Media Recovery Start: Managed Standby Recovery (orcl)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 2 processes
Terminal Recovery timestamp is '01/09/2008 18:46:50'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 173 redo required
Terminal Recovery: /u04/oradata/ORCL/ORCL_stdby_redo 06.log
Identified End-Of-Redo for thread 1 sequence 173
Wed Jan 9 18:46:50 2008
Incomplete recovery applied all redo ever generated.
Recovery completed through change 1062009
Wed Jan 9 18:46:50 2008
Media Recovery Complete (orcl)
Terminal Recovery: successful completion
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
Resetting standby activation ID 1169895671 (0x45bb30f7)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE
Wed Jan 9 18:46:54 2008
Here the standby database performs a fast-start failover and changes the role to primary ,in many cases it
will be possible to restart the original production database after a fast-start failover, and after the problem
that had caused the failover has been resolved. For this reason, following a fast-start
failover the observer periodically attempts to reconnect to the original production
database. When the observer regains network access to the original production
database, it initiates a request for the Data Guard Broker to automatically reinstate
it as a standby database to the new production database.
Vinod Sadanandan
Oracle DBA
=============== =============== =============== =============== =============== ==
This article describes the automatic fast start failover configuration and the conditions for trigerring a fast start failover in dataguard environment .
In Faststart failover dataguard configuration if the primary database becomes unavailable, the observer confirms with the target standby database that the primary production database is unavailable and that the target standby
database is synchronized with the production database, if so, initiates a faststart failover to the target standby database if there is a gurantee that no data will be lost.
Minimum requirements for enabling Fast-Start Failover
- The Data Guard configuration must be in MaxAvailability protection mode.
- The LogXptMode property for both the primary database and the Fast-Start Failover target standby database must be SYNC.
- The primary database and the Fast-Start Failover target standby database must both have flashback enabled.
- No valid target standby database was specified in the primary database's FastStartFailov erTarget property prior to the attempt to enable Fast-Start Failover, and more than one standby database exists in the Data Guard configuration.
DGMGRL for Linux: Version 10.2.0.1.0 - 64bit Production
Copyright (c) 2000, 2005, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/passwd
Connected.
DGMGRL> create configuration 'ORCL' as
> primary database is 'ORCL_DB'
> connect identifier is 'ORCL.world';
Configuration "ORCL" created with primary database "ORCL_DB"
DGMGRL> show configuration
Configuration
Name: ORCL
Enabled: NO
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
ORCL_DB - Primary database
Current status for "ORCL":
DISABLED
DGMGRL> add database 'STNDBY_DB' as
> connect identifier is STNDBY_DB maintained as physical;
Database "STNDBY_DB" added
DGMGRL> show database verbose 'STNDBY_DB';
Database
Name: STNDBY_DB
Role: PHYSICAL STANDBY
Enabled: NO
Intended State: OFFLINE
Instance(s):
orcl
Properties:
InitialConnectI dentifier = 'STNDBY_DB'
LogXptMode = 'ASYNC'
Dependency = ''
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '10'
NetTimeout = '180'
LogShipping = 'ON'
PreferredApplyI nstance = ''
ApplyInstanceTi meout = '0'
ApplyParallel = 'AUTO'
StandbyFileMana gement = 'MANUAL'
ArchiveLagTarge t = '0'
LogArchiveMaxPr ocesses = '2'
LogArchiveMinSu cceedDest = '1'
DbFileNameConve rt = ''
LogFileNameConv ert = ''
FastStartFailov erTarget = ''
StatusReport = '(monitor)'
InconsistentPro perties = '(monitor)'
InconsistentLog XptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'localhost.loca ldomain'
SidName = 'orcl'
LocalListenerAd dress = '(ADDRESS=(PROT OCOL=tcp)(PORT= 1540)(HOST=loca lhost.localdoma in))'
StandbyArchiveL ocation = '/u04/oradata/arch'
AlternateLocati on = ''
LogArchiveTrace = '0'
LogArchiveForma t = '%t_%s_%r.dbf'
LatestLog = '(monitor)'
TopWaitEvents = '(monitor)'
Current status for "STNDBY_DB" :
DISABLED
DGMGRL> enable configuration
Enabled.
DGMGRL> EDIT DATABASE 'ORCL_DB' SET PROPERTY FastStartFailov erTarget = 'STNDBY_DB';
Property "faststartfailo vertarget" updated
DGMGRL> EDIT DATABASE 'STNDBY_DB' SET PROPERTY FastStartFailov erTarget = 'ORCL_DB';
Property "faststartfailo vertarget" updated
DGMGRL> EDIT DATABASE 'ORCL_DB' SET PROPERTY 'LogXptMode'='S YNC';
Property "LogXptMode " updated
DGMGRL> EDIT DATABASE 'STNDBY_DB' SET PROPERTY 'LogXptMode'='S YNC';
GMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY ;
Operation requires shutdown of instance "ORCL" on database "ORCL_DB"
Shutting down instance "orcl"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "orcl" on database "ORCL_DB"
Starting instance "orcl"...
ORACLE instance started.
Database mounted.
-Here check for UNDO renention and flashback database ,enable fast start failover and start observer from DGMGRL
DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.
DGMGRL> START OBSERVER;
Observer started
DGMGRL> show configuration verbose
Configuration
Name: ORCL
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
ORCL_DB - Primary database
STNDBY_DB - Physical standby database
- Fast-Start Failover target
Fast-Start Failover
Threshold: 30 seconds
Observer: localhost.local domain
-Events that may trigger a fast start failover are instance failure ,datafile taken offline due to IO errors ,shutdown abo
rt /others ...,here a shutdown abort is initated in the primary instance .
Observer log:-
Current status for "ORCL":
SUCCESS
18:46:48.69 Wednesday, January 09, 2008
Initiating fast-start failover to database "STNDBY_DB" ...
Performing failover NOW, please wait...
Failover succeeded, new primary is "STNDBY_DB"
18:47:19.09 Wednesday, January 09, 2008
Alert Log:-
RFS[7]: Possible network disconnect with primary database
Wed Jan 9 18:46:15 2008
RFS[6]: Possible network disconnect with primary database
Wed Jan 9 18:46:15 2008
RFS[8]: Possible network disconnect with primary database
Wed Jan 9 18:46:48 2008
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE
Wed Jan 9 18:46:48 2008
Terminal Recovery: Stopping real time apply
Wed Jan 9 18:46:49 2008
MRP0: Background Media Recovery cancelled with status 16037
Wed Jan 9 18:46:49 2008
Errors in file /u03/app/admin/oracle/admin/ORCL/bdump/orcl_mrp0_18084 .trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Wed Jan 9 18:46:49 2008
Errors in file /u03/app/admin/oracle/admin/ORCL/bdump/orcl_mrp0_18084 .trc:
ORA-16037: user requested cancel of managed recovery operation
Wed Jan 9 18:46:49 2008
MRP0: Background Media Recovery process shutdown (orcl)
Wed Jan 9 18:46:49 2008
Terminal Recovery: Stopped real time apply
Wed Jan 9 18:46:49 2008
Attempt to do a Terminal Recovery (orcl)
Wed Jan 9 18:46:49 2008
Media Recovery Start: Managed Standby Recovery (orcl)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 2 processes
Terminal Recovery timestamp is '01/09/2008 18:46:50'
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 173 redo required
Terminal Recovery: /u04/oradata/ORCL/ORCL_stdby_redo 06.log
Identified End-Of-Redo for thread 1 sequence 173
Wed Jan 9 18:46:50 2008
Incomplete recovery applied all redo ever generated.
Recovery completed through change 1062009
Wed Jan 9 18:46:50 2008
Media Recovery Complete (orcl)
Terminal Recovery: successful completion
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
Resetting standby activation ID 1169895671 (0x45bb30f7)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE
Wed Jan 9 18:46:54 2008
Here the standby database performs a fast-start failover and changes the role to primary ,in many cases it
will be possible to restart the original production database after a fast-start failover, and after the problem
that had caused the failover has been resolved. For this reason, following a fast-start
failover the observer periodically attempts to reconnect to the original production
database. When the observer regains network access to the original production
database, it initiates a request for the Data Guard Broker to automatically reinstate
it as a standby database to the new production database.
Vinod Sadanandan
Oracle DBA