Database Reference
In-Depth Information
17:55:11.81 Monday, September 16, 2013
Initiating Fast-Start Failover to database "CDBFSDCA"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "CDBFSDCA"
17:55:37.00 Monday, September 16, 2013
The old primary is shut down at this stage, and the Broker logfile recorded more information as to what happened.
09/16/2013 17:55:12
FAILOVER TO CDBFSDCA
Beginning failover to database CDBFSDCA
Notifying Oracle Clusterware to prepare database for FAILOVER
09/16/2013 17:55:19
DMON: Old primary "CDBFSDCB" needs reinstatement
09/16/2013 17:55:33
Warning: Another process is opening pluggable databases
Waiting for open to complete.
Will retry in 15 seconds, maximim wait time is 15 minutes
09/16/2013 17:55:36
Protection mode set to MAXIMUM AVAILABILITY
09/16/2013 17:55:37
Deferring associated archivelog destinations of sites permanently disabled due to Failover
Notifying Oracle Clusterware to buildup primary database after failover
Posting DB_DOWN alert ...
... with reason Data Guard Fast-Start Failover - Primary Disconnected
Notice how it detected that a failover has likely taken place. As soon as the old primary is started again it will be
reinstated:
18:01:19.41 Monday, September 16, 2013
Initiating reinstatement for database "CDBFSDCB"...
Reinstating database "CDBFSDCB", please wait...
Reinstatement of database "CDBFSDCB" succeeded
18:01:58.56 Monday, September 16, 2013
The configuration shows no more warnings, and you can switch over to the old primary during the next
change window.
Maintaining archived logs
Maintaining archived redo logs in a Data Guard configuration is something that needs careful planning. A very
common problem with standby databases falling out of sync with the primary is when the archive log destination fills
up. Without space no additional redo can be applied on the standby, and a flurry of errors will be recorded in the alert.
log of both the primary database as well as the standby database that has run out of space. A fantastic way to deal with
archived logs—but not only them—is the Fast Recovery Area ('FRA'). It has been introduced with Oracle 10g as the
Flash Recovery Area, but was renamed to Fast Recovery Area in a later release; for all purposes the two are the same.
The goal of the FRA, as it is often abbreviated to, is to simplify management of files which need backing up. Files
found to be stored in the FRA include
Search WWH ::
Custom Search