Copy of Fail Over Process

7/27/2019 Copy of Fail Over Process

1/8

FAIL OVER PROCESS

FAILOVER ON ORACLE DATABASES PROTECTED WITH ORACLE DATAGUARD============================================================1. What is a Failover ?

Oracle DataGuard is a Disaster Recovery (DR) Solution for Oracle Databases.The basic idea behind DataGuard is a Standby Database performing all changesfrom a Primary Database on itself, too. So the Standby Database should be aconstantly updated copy of a Primary Database. This copy can either be amounted and in Recovery mode placed (Physical Standby) or an open Database(Logical Standby - Oracle 9iR2 only). In case of a loss of the PrimaryDatabase, the Standby can take over the Primary Role and act as a PrimaryDatabase. Also for planned outages of the Primary Database (eg. Hardwareupgrades,...), the Standby Database can takeover the Primary Role andswitchback to the Standby Role once the Upgrade is complete.

Please refer to the following notes for information on creating a Standby

Database:

Note 180031.1: Creating a Data Guard ConfigurationNote 186150.1: Data Guard 9i Creating a Logical Standby Database

The Difference between a Switchover and a Failover is, that after a Failover,the Standby Database becoming a Primary now, cannot switchback to become aStandby Database again. In Opposition a Switchover exchanges the DatabaseRoles (The Primary becomes a Standby and the Standby becomes a Primary).Switchovers can be performed arbitrarily, a Failover only once.

2. Failover Types

2.1 Failover on Physical Standby Database

A Failover can be performed when all or most of the information until theUnavailability of the Primary Database was propageted to the Standby. Theusage of Standby RedoLogs ia a great advantage here. If you have no StandbyRedoLogs available, you will always encounter some Data Loss (depending onthe Changes since the latest LogSwitch). To perform a Failover just followthese steps:

- The Primary Database is down for any reason

- Verify a Standby RedoLog is in use for Primary current Online RedoLog. Youthen find in the ALERT.LOG of the Standby something like:

RFS: Successfully opened standby logfile 4:'C:\ORACLE\ORADATA\PRIMARY\STBY01.LOG'

- If this is the case run the following commands:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;


2/8

This cancels the normal managed Recovery. To get the Standby RedoLog Informationis still required. Therefore issue this command:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;- If a Standby RedoLog is not used for any reason, then run this one:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH SKIPSTANDBY LOGFILE;

Please keep in mind that this one causes (Minimal) Data Loss as the latestetinformation from the down Primary Database is not available anymore.

- Once this is complete (This performs a complete Recovery or incompleteRecovery until the last SCN included in the latest archived Log available atthe Standby), you can now make the Standby Database a Primary:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY

WARNING: This will only succeed if the correct RECOVER FINISH-statement was

issued before. If you forgot the 'SKIP STANDBY LOGFILE' although youhave no Standby RedoLogs, the COMMIT to Switchover will fail with theerror that more Media Recovery is required here.

- If the COMMIT TO SWITCHOVER fails for any reason you have to use the ACTIVATE

command which forces the Failover (and may cause Data Loss !!)

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

- Shutdown and restart the Databse after this command ended successfully:

SQL> SHUTDOWN IMMEDIATESQL> STARTUP

- Now the Standby is open as a new Primary Database

2.2 Failover on a Logical Standby Database (Oracle 9iR2 only):

A Failover to a Logical Standby Database is also possible, but not recommendedfor DR, as there are some restrictions on Logical Standby Databases (seeOracle 9i DataGuard Concepts and Administration, Chapter 4.1.4 DetermineSupport for Datatypes or Tables). So a Failover to a Logical Standby Databasemight always cause a Data Loss.To perform a Failover to a Logical Standby Database, perform the following

steps:

- The Primary Database is down for any reason

- Determine if all Archive Logs have been transfered from the Primary Databaseto the Logical Standby Database (Either look for them in the directory andquery the DBA_LOGSTDBY_LOG-view).

- Copy all missing ArchiveLogs and the Online RedoLogs from the PrimaryDatabase to the Logical Standby Database if possible.


3/8

- Register all copied or not already registered LogFiles to the Logical StandbyDatabase:

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '';

- Turn off Logical Apply Delay Interval (if set):

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('APPLY_DELAY');SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

- Ensure all registered Logfiles have been applied:

SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;- Stop Logical Apply Services:

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

- Activate the Logical Standby Database:

SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;

SWITCH OVER PROCESS

Overview---------------

A switchover is a role reversal between the primary database and one of its standbydatabases. A switchover operation guarantees no data loss. This is typically donefor planned maintenance of the primary system. During a switchover, the primarydatabase transitions to a standby role and the standby database transitions to

the primary role. The transition occurs without having to re-create eitherdatabase.

By contrast, a failover is an irreversible transition of a standby database tothe primary role. This is only done in the event of a catastrophic failure ofthe primary database.

Before starting a switchover operation:-------------------------------------------

1. Verify that both the primary and standby init.ora support role transition.Oracle recommends that you maintain a single init.ora for both the primary

and the standby. Each init.ora should have all the parameters that are neededto support either the standby or primary role. An example of the primaryinit.ora follows:

-- snip ---

### Primary database primary role parameterr ###

LOG_ARCHIVE_DEST_1='LOCATION=/database/oracle/920DG/primary/arch'


4/8

LOG_ARCHIVE_DEST_2='SERVICE=920DG_hasunclu2'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_FORMAT=%d_%t_%s.arc

### Primary database standby role parameters ###

FAL_SERVER=920DG_hasunclu2FAL_CLIENT=920DG_hasunclu1DB_FILE_NAME_CONVERT=('/standby','/primary')LOG_FILE_NAME_CONVERT=('/standby','/primary')STANDBY_ARCHIVE_DEST=/database/oracle/920DG/archSTANDBY_FILE_MANAGEMENT=AUTO

-- snip --

An example of a standby init.ora follows:

-- snip --

### Standby database standby role parameters ###

FAL_SERVER=920DG_hasunclu1FAL_CLIENT=920DG_hasunclu2DB_FILE_NAME_CONVERT=("/primary","/standby")LOG_FILE_NAME_CONVERT=("/primary","/standby")STANDBY_ARCHIVE_DEST=/database/oracle/920DG/standby/archLOG_ARCHIVE_DEST_1='LOCATION=/database/oracle/920DG/standby/arch'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_FORMAT=%d_%t_%s.arcSTANDBY_FILE_MANAGEMENT=AUTO

### Standby database primary role parameters ###

LOG_ARCHIVE_DEST_2='SERVICE=920DG_hasunclu1'LOG_ARCHIVE_DEST_STATE_2=DEFER

-- snip --

With the initialization parameters on both the primary and standby databasesset as described above, the only parameter that needs to change after a roletransition is the LOG_ARCHIVE_DEST_STATE_2 parameter. Change this parameter toENABLED on the database that assumes the primary role.

2. Verify that there is network connectivity between the primary and standbylocations.

3. Each location in the Data Guard configuration should have connectivitythrough Oracle Net to the primary database and to all associated standbydatabases.

4. Verify that there are no active users connected to the databases.

5. Verify that all but one primary instance and one standby instance in a RealApplication Clusters configuration are shut down.


5/8

6. For a Real Application Clusters database, only one primary instance and onestandby instance can perform the switchover operation. Shut down all otherinstances before the switchover operation.

7. For switchover operations involving a physical standby database, the primarydatabase instance is open and the standby database instance is mounted.

8. The standby database that you plan to transition to the primary role must bemounted before you begin the switchover operation. Ideally, the physicalstandby database will also be actively recovering archived redo logs whenthe database roles are switched. If the physical standby database is openfor read-only access, the switchover operation still will take place, butwill require additional time.

9. For switchover operations involving a logical standby database, both the primaryand standby database instances are open.

10. Place the standby database that will become the new primary database inARCHIVELOG mode.

11. Remove any redo data application delay in effect on the standby database.

Steps to perform switchover with Physical Standby databases:--------------------------------------------------------------

1. Verify that it is possible to perform a switchover operation. On the primaryquery the switchover_status column of v$database to verify that switchoverto standby is possible.

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS------------------TO STANDBY

In order to perform a switchover all sessions to the database need to bedisconnected. In version 901 this was a manual process. In version 9.2.0this process has been automated with the with session shutdown clausethat has been added to the alter database commit to switchover command.If SWITCHOVER_STATUS returns SESSIONS ACTIVE then you should eitherdisconnect all sessions manually or when performing step 2 you should appendthe with session shutdown clause. For example:

SQL> alter database commit to switchover to standby with session shutdown;

Note that the clause also works with the switchover to primary command.

The SWITCHOVER_STATUS column of v$database can have the following values:

NOT ALLOWED - Either this is a standby database and the primary database hasnot been switched first, or this is a primary database and there are no standby databases.

SESSIONS ACTIVE - Indicates that there are active SQL sessions attached to


6/8

the primary or standby database that need to be disconnected before theswitchover operation is permitted.

SWITCHOVER PENDING - This is a standby database and the primary databaseswitchover request has been received but not processed.

SWITCHOVER LATENT - The switchover was in pending mode, but did not completeand went back to the primary database.

TO PRIMARY - This is a standby database, with no active sessions, that isallowed to switch over to a primary database.

TO STANDBY - This is a primary database, with no active sessions, that isallowed to switch over to a standby database.

RECOVERY NEEDED - This is a standby database that has not received theswitchover request.

During normal operations it is acceptable to see the following values forSWITCHOVER_STATUS on the primary to be SESSIONS ACTIVE or TO STANDBY.

During normal operations on the standby it is acceptable to see the valuesof NOT ALLOWED or SESSIONS ACTIVE.

2. Convert the primary database to the new standby:

SQL> alter database commit to switchover to physical standby;

Database altered.

3. Shutdown the former primary and mount as a standby database:

SQL> shutdown immediateORA-01507: database not mounted

ORACLE instance shut down.SQL> startup nomountORACLE instance started.

Total System Global Area 85020944 bytesFixed Size 454928 bytesVariable Size 71303168 bytesDatabase Buffers 12582912 bytesRedo Buffers 679936 bytesSQL> alter database mount standby database;

Database altered.

4. Defer the remote archive destination on the old primary:

SQL> alter system set log_archive_dest_state_2=defer;

5. Verify that the physical standby can be converted to the new primary:

SQL> select switchover_status from v$database;


7/8

SWITCHOVER_STATUS------------------SWITCHOVER PENDING

Note that if the status returns SESSIONS ACTIVE then you should append thewith session shutdown clause to the command in step 6.

6. Convert the physical standby to the new primary:

SQL> alter database commit to switchover to primary;

Database altered.

If you are on verion 9.0.1 then you should first cancel managed recovery priorto issuing the above command. If you are on 9.2.0 and have started managedrecovery with the "through all switchover" clause then you should also cancelmanaged recovery before issuing the above command.

7. Shutdown and startup the new primary:

SQL> shutdown immediateORA-01507: database not mounted

ORACLE instance shut down.SQL> startupORACLE instance started.

Total System Global Area 85020944 bytesFixed Size 454928 bytesVariable Size 71303168 bytesDatabase Buffers 12582912 bytes

Redo Buffers 679936 bytesDatabase mounted.Database opened.SQL>

8. Enable remote archiving on the new primary to the new standby:

SQL> alter system set log_archive_dest_state_2=enable;

9. Start managed recover on the new standby database:

SQL> recover managed standby database disconnect;Media recovery complete.

SQL>

Steps to perform switchover with Logical Standby databases:--------------------------------------------------------------

Note that the SWITCHOVER_STATUS column of the V$DATABASE view is supported onlyfor use with physical standby databases.

1. Switch the primary database to the logical standby database role.


8/8

SQL> alter database commit to switchover to logical standby;

Database altered.

2. Stop the old primary database from shipping archive logs to the logicalstandby:

SQL> alter system set log_archive_dest_state_2=defer scope=both;

System altered.

3. Switch the logical standby database to the primary database role:

SQL> alter database commit to switchover to primary;

Database altered.

4. Enable archiving from the new primary to the new logical standby

SQL> alter system set log_archive_dest_state_2=enable scope=both;

System altered.

5. On each logical standby database, create a database link that points tothe new primary database. (The example in this step uses the database linklocation1.)

Use the DBMS_LOGSTDBY.GUARD_BYPASS_ON procedure to bypass the database guardand allow modifications to the tables in the logical standby database. Forexample:

SQL> EXECUTE DBMS_LOGSTDBY.GUARD_BYPASS_ON;

SQL> CREATE DATABASE LINK location12> CONNECT TO user-name IDENTIFIED BY password USING 'location1';

SQL> EXECUTE DBMS_LOGSTDBY.GUARD_BYPASS_OFF;

6. On the new logical standby database (formerly the primary database) and onany other existing logical standby destinations, begin SQL apply operations:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY location1;

7. On the new primary database, enable archive logging and switch logs to ensurethat all the standby databases begin receiving redo logs by executing thefollowing SQL statements:

SQL> ALTER SYSTEM ARCHIVE LOG START;SQL> ALTER SYSTEM SWITCH LOGFILE;

References:==============

Data Guard Concepts and Admini

Copy of Fail Over Process

Documents

Transcript of Copy of Fail Over Process