|
Fast-Start Failover An Overview In High Availability Environments
In this article I have described the automatic fast start failover configuration
and the conditions for triggering 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 guarantee that no data
will be lost.
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/system
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:
InitialConnectIdentifier = 'STNDBY_DB'
LogXptMode = 'ASYNC'
Dependency = ''
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '10'
NetTimeout = '180'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'MANUAL'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '2'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = ''
LogFileNameConvert = ''
FastStartFailoverTarget = ''
StatusReport = '(monitor)'
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'localhost.localdomain'
SidName = 'orcl'
LocalListenerAddress = '(ADDRESS=(PROTOCOL=tcp)(PORT=1540)(HOST=localhost.localdomain))'
StandbyArchiveLocation = '/u04/oradata/arch'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = '%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 FastStartFailoverTarget = 'STNDBY_DB';
Property "faststartfailovertarget" updated
DGMGRL> EDIT DATABASE 'STNDBY_DB' SET PROPERTY FastStartFailoverTarget = 'ORCL_DB';
Property "faststartfailovertarget" updated
DGMGRL> EDIT DATABASE 'ORCL_DB' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated
DGMGRL> EDIT DATABASE 'STNDBY_DB' SET PROPERTY 'LogXptMode'='SYNC';
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.localdomain
-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_redo06.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.
|
