dba tips archive for oracle (activating the standby database )

7/30/2019 DBA Tips Archive for Oracle (Activating the Standby Database )

1/19

DBA Tips Archive for Oracle

Activating the Standby Database - (10g, Physical

Standby)

by Jeff Hunter, Sr. Database Administrator

Contents

Introduction

Role Transition

Which Role Transition Operation Should I Use?

Implement Role Switchover Operation

Implement Role Failover Operation

Further Reading

About the Author

Introduction

The tasks involved in creating and managing a Data Guard configuration are fairly straightforward. Oncethe standby database is put into operation, you are happy, your customer is happy, management is happy- everyone is happy with the piece of mind that their data is being replicated to their disaster recovery site.But the time will eventually come where the inevitable will occur and the primary database becomesunavailable. You are now faced with failing over production activities to an available standby database.Other circumstances can also arise where scheduled maintenance needs to occur on the primarydatabase and database operations need to be switched over to the standby database. In either case, therole of the primary database and the standby database will need to be changed. This is known as RoleTransition and is the subject of this article.

It is assumed that a primary and one physical standby database is already configured in order to performthe role transition steps described in this guide. The examples used in this guide will make use of theOracle Data Guard configuration described in the article below:

Data Guard Configuration Example - (Oracle 10g, Physical Standby)

The following tables summarize the Oracle Data Guard configuration that will be used in this guide:

Primary Database
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Introductionhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Introductionhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Role%20Transitionhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Role%20Transitionhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Which%20Role%20Transition%20Operation%20Should%20I%20Use?http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Which%20Role%20Transition%20Operation%20Should%20I%20Use?http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Implement%20Role%20Switchover%20Operationhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Implement%20Role%20Switchover%20Operationhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Implement%20Role%20Failover%20Operationhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Implement%20Role%20Failover%20Operationhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Further%20Readinghttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Further%20Readinghttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#About%20the%20Authorhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#About%20the%20Authorhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/http://window.history.back%28%29/http://www.idevelopment.info/http://window.history.back%28%29/http://www.idevelopment.info/http://window.history.back%28%29/http://www.idevelopment.info/http://window.history.back%28%29/http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#About%20the%20Authorhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Further%20Readinghttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Implement%20Role%20Failover%20Operationhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Implement%20Role%20Switchover%20Operationhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Which%20Role%20Transition%20Operation%20Should%20I%20Use?http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Role%20Transitionhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_47.shtml#Introduction


2/19

Oracle Release Oracle 10g Release 2 (10.2.0.5)

Host Name vmlinux1.idevelopment.info (192.168.1.160)

Operating System Red Hat Linux 5 (CentOS 5.5)

Database Name (db_name) modesto

Database Domain (db_domain) idevelopment.info

Oracle SID modesto

Database Unique Name (db_unique_name) modesto

TNS Alias modesto.idevelopment.info

Service Names modesto.idevelopment.info, modesto

Database Files - (db_create_file_dest) /u02/oradata

Flash Recovery Area -(db_recovery_file_dest)

/u03/flash_recovery_area

Local Online Redo Log Files -(log_archive_dest_1)

location=use_db_recovery_file_dest (all_logfiles,all_roles)

Remote Archive Destination -

(log_archive_dest_2)service=turlock (online_logfiles,primary_role)

Physical Standby Database

Oracle Release Oracle 10g Release 2 (10.2.0.5)

Host Name vmlinux2.idevelopment.info

(192.168.1.162)

Operating System Red Hat Linux 5 (CentOS 5.5)

Database Name (db_name) modesto

Database Domain (db_domain) idevelopment.info

Oracle SID turlock

Database Unique Name (db_unique_name) turlock

TNS Alias turlock.idevelopment.info

Service Names turlock.idevelopment.info, turlock

Database Files - (db_create_file_dest) /u02/oradata

Flash Recovery Area -

(db_recovery_file_dest)/u03/flash_recovery_area

Local Online Redo Log Files - location=use_db_recovery_file_dest


3/19

(log_archive_dest_1) (all_logfiles,all_roles)

Remote Archive Destination -(log_archive_dest_2)

service=modesto (online_logfiles,primary_role)

Role Transition

Role transition plays an important part in Data Guard by providing an interface that allows the DBA toactivate a standby database to take over as the primary database. There are two types of role transitionssupported in Oracle 10gData Guard:

Switchover

This operation is a reversible role transition between the primary database and one of it standbydatabases. With a switchover, there is no data loss, and the old primary database will remain inthe Data Guard configuration as a standby database. This operation is generally used to reduceprimary database downtime during a scheduled outage. This may include outages related tooperating system or hardware upgrades. After the required tasks for the planned outage have

been completed, the original roles for the primary and standby database can be transitioned backto normal.

Failover

This operation transitions a standby database to the primary role and is typically used in responseto a failure on the primary database. During a failover operation, one of the standby databaseswill transition its role to the primary database and the old primary database is rendered unable toparticipate in the configuration. (Although it could be rebuilt and entered back into theconfiguration as a standby database). The amount of data loss incurred by this operation ispredicated on the protection mode under which the old primary database was operating under.You would typically choose the failover method only when the primary database becomesunavailable and there is no possibility of restoring it to a service within a reasonable amount oftime.

Which Role Transition Operation Should I Use?

When faced with the decision on which role transition is best for the given situation, you need to alwayschoose one that best reduces downtime and has the least potential for data loss. Also to consider is howthe change will affect any other standby database in the configuration. You should consider the followingwhen making the decision on which operation to use:

What is the current state of the primary database just before the transition? Is it available?

What is the state of the selected standby database to be used in the role transition at the time oftransition?

Is the standby database configured as a physical or logical standby database?

The following decision tree can be used to assist when making this critical decision as to which operationto perform:


4/19

One key point to consider is that if it would be faster to repair the primary database (from failure or asimple planned hardware/software upgrade), the most efficient method would be to perform the tasks andthen to bring up the primary database as quickly as possible and not perform any type of role transition.This method can impose less risk to the system and does not require any client software to be re-configured.

Another consideration involves a Data Guard configuration which includes a logical standby database. Aswitchover operation can be performed using either a physical or logical standby database. Take note,however, of the following issues you may run in to regarding physical and logical standby configurations.If the configuration includes a primary, a physical standby, and a logical standby, and a switchover isperformed on the logical standby, the physical standby will no longer be a part of the configuration andmust be rebuilt. In the same scenario, if a switchover operation is performed on the physical standby, thelogical standby remains in the Data Guard configuration and does not need to be rebuilt. Obviously, aphysical standby is a better option to be a switchover candidate than a logical standby when multiplestandby types exist in a given configuration.

The sections that follow describe how to perform both switchover and failover operations.

Implement Role Switchover Operation

A switchover operation is a reversible role transition between the primary database and one of its standbydatabases. With a switchover, there is no data loss, and the old primary database will remain in the DataGuard configuration as a standby database. This operation is generally used to reduce primary databasedowntime during a scheduled outage. This may include outages related to operating system or hardware


5/19

upgrades. After the required tasks for the planned outage are completed, the original roles for the primaryand standby database can be transitioned back to normal.

This example uses the same two-node Data Guard configuration that was created in the guide DataGuard Configuration Example - (Oracle 10g, Physical Standby) a primary database (modesto on

hostvmlinux1.idevelopment.info) sending redo to a single physical standby database (turlock on

host vmlinux2.idevelopment.info). The Data Guard protection mode for the primary database isset tomaximum performance which means the standby database does not receive any redo data until theprimary database fills its current online redo and archives it. Under normal operation, the data receivedand applied to the standby database is only as current as the last archived redo log sent from the primarydatabase.

In this section, I will be performing a role transition where the modesto database running on

host vmlinux1 will transition its role from primary to physical standby while the turlock database on

host vmlinux2will transition its role from physical standby to primary using the graceful switchover

operation. This will all occur without any loss of data!

There are three methods that can be used to perform a switchover: SQL*Plus, the Data Guard Broker,and Grid Control. The method used in this example will use only SQL*Plus.

A switchover operation takes place in two phases:

1. The existing primary database is transitioned to a standby role. After this first phase isimplemented, the Data Guard configuration temporarily has two standby databases.

2. A standby database (in this example, there was only one physical standby database) istransitioned to the primary role.

Switchover Preparation

The key to a successful switchover is planning and adequate testing. It is highly recommended to test anytype of architectural change of this magnitude in a test environment before attempting it on a production

system!

The following is a list of checks that should be completed prior to performing a switchover operation.

Initialization Parameters

One of the most important checks involves verifying that the initialization parameters for the primary andstandby support both roles.

For example, make certain that the VALID_FOR attribute for the LOG_ARCHIVE_DEST_n parameter

(dest_id=2 in my configuration) is configured to assume the primary role when its role is changed.Additionally, verify that the service and db_unique_name are valid for each definition.

[ PRIMARY ]

log_archive_dest_2='service=turlock.idevelopment.info valid_for=(online_logfiles,pri[ STANDBY ]

log_archive_dest_2='service=modesto.idevelopment.info valid_for=(online_logfiles,pri
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml


6/19

If the Data Guard configuration contains other standby databases, verify that the new primary database

contains a LOG_ARCHIVE_DEST_n definition for each standby database. This ensures each standby

database will continue to receive redo data from the new primary database.

The next set of parameters handle the Fetch Archive Logcapabilities which are used to handlelog gap

resolution(FAL_SERVER and FAL_CLIENT). It is only recognized on a physical standby database and is

the process used by the physical standby to fetch any missing archive log files from one of the databasesin a Data Guard configuration (primary or standby). Setting the FAL parameters has become lessimportant with the introduction ofproactive gap resolution in Oracle9iRelease 2. This new featureresolves just about any type of gap request from a physical or logical using a ping process from theprimary database. On the primary database, the archive process has been designated as the pingprocess and will poll all standby databases looking for gaps and will also process any outstanding gaprequests that were posted by the Apply process. Although it would appear that setting

the FAL parameters is no longer required, they can become extremely useful in situations where a gap in

the redo was encountered while the primary was not accessible. To handle this scenario, set

the FAL_SERVER parameter equal to all databases (primary and standby) in the Data Guard

configuration. Set FAL_CLIENT on each database to the TNS alias for the database requesting gap

resolution. This value is used by the receiver of the gap request (FAL_SERVER) so that the archive

process on the FAL server database can connect back to the requester.

For example:

[ PRIMARY ]

fal_server='modesto','turlock'fal_client='modesto'

[ STANDBY ]

fal_server='modesto','turlock'fal_client='turlock'

TNS Alias

Verify that the primary and standby host each have valid TNS aliases that point to one another. Inaddition, make certain that each of the TNS aliases are the ones used in

the LOG_ARCHIVE_DEST_nparameter(s).

For the purpose of this example, the following TNS aliases have been defined and tested on both theprimary and standby host:

MODESTO.IDEVELOPMENT.INFO =(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = vmlinux1.idevelopment.info)(PORT = 1521))(CONNECT_DATA =

(SERVER = DEDICATED)(SERVICE_NAME = modesto.idevelopment.info)

))

TURLOCK.IDEVELOPMENT.INFO =
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_5.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_5.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_5.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_5.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_5.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_5.shtml


7/19

(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = vmlinux2.idevelopment.info)(PORT = 1521))(CONNECT_DATA =

(SERVER = DEDICATED)(SERVICE_NAME = turlock.idevelopment.info)

)

)

Disconnect User Connections

To ensure a quick and efficient switchover, disconnect all user connections. If that is not possible, attemptto restrict user activity as much as possible.

During the transition of the primary database to a standby, you can use the WITH SESSION

SHUTDOWN clause of the SWITCHOVER command to kill any user connections.

Verify Tempfiles on Primary and Standby

Verify that both the primary and standby database temporary tablespaces are defined with tempfiles:

[ PRIMARY ]

SQL> select ts.name as "Tablespace", tf.name as "Tempfile", tf.status as "Status"2 from v$tablespace ts join v$tempfile tf using (ts#);

Tablespace Tempfile Status----------- ------------------------------------------------------- -------TEMP /u02/oradata/MODESTO/datafile/o1_mf_temp_6hc6v3jd_.tmp ONLINE

[ STANDBY ]

SQL> select ts.name as "Tablespace", tf.name as "Tempfile", tf.status as "Status"2 from v$tablespace ts join v$tempfile tf using (ts#);

Tablespace Tempfile Status----------- ------------------------------------------------------- -------TEMP /u02/oradata/TURLOCK/datafile/o1_mf_temp_%u_.tmp ONLINE

Verify Redo is Current with Primary

Make certain that the standby (physical or logical) is applying changes from the primary. Also verify thatthe application of redo is current with the primary.

From the primary database, perform a log switch and then verify the transmissions of the archived redolog file was successful. If the transmission was successful, the status of the destination will be VALID asshown below.

SQL> alter system switch logfile;


8/19

System altered.

SQL> select status, error from v$archive_dest where dest_id = 2;

STATUS ERROR

--------- ---------------------------------------------------------VALID

Once it has been determined that the redo stream is current, make sure that the redo has been applied tothe standby database. In the case of a physical standby database, verify Redo Apply by querying thestatus of the MRP0 process in V$MANAGED_STANDBY:

SQL> select client_process, process, sequence#, status2 from v$managed_standby;

CLIENT_PROCESS PROCESS SEQUENCE# STATUS-------------- --------- ---------- ------------ARCH ARCH 0 CONNECTEDARCH ARCH 0 CONNECTEDARCH ARCH 0 CONNECTEDARCH ARCH 0 CONNECTEDN/A MRP0 732 WAIT_FOR_LOGN/A RFS 0 IDLE

In the case of a physical standby database, if the MRP0 record is not returned in the above query, thenredo apply is not running. In order ensure an efficient switchover process, Redo Apply should be startedand caught up with the current redo stream:

SQL> startup mount

[ START REDO APPLY ]

SQL> alter database recover managed standby database disconnect;

[ START REDO APPLY USING REAL-TIME APPLY ]

SQL> alter database recover managed standby database using current logfile disconnec

If the MRP0 record is returned but shows a status ofWAIT_FOR_GAP, the switchover operation cannot

occur until the redo gap has been resolved.

If the status of the MRP0 process is APPLYING_LOG then the standby is current and using real-time apply

and current with the primary database.

Finally, if the status of the MRP0 process is WAIT_FOR_LOG, the standby is not running real-time apply

(which is OK) or the DELAY qualifier was specified for the destination. If the DELAY qualifier was specified,

stop the apply process and restart it with the NODELAY qualifier; otherwise the switchover operation will

not complete. If the DELAY qualifier was not set and the standby is not using real-time apply, then it

should be current with the primary database.


9/19

Verify Standby Redo Log (SRL) Files on the Primary

The physical standby database used in this example is configured with standby redo log (SRL) files.Verify that SRL files have been created on the current primary database so that it can receive the redowhen it becomes a standby.

SQL> select group#, status, type, count(*) as "Members"2 from v$logfile3 group by group#, status, type4 order by group#;

GROUP# STATUS TYPE Members---------- ------- ------- ----------

1 ONLINE 22 ONLINE 23 ONLINE 24 STANDBY 25 STANDBY 2

6 STANDBY 27 STANDBY 2

Cancel Jobs and Backups

Cancel any running jobs on the primary database and disable any new ones from starting. This caninclude RMAN backups, maintenance jobs, etc. If RMAN backups are configured to run from the standbydatabase, stop them as well as they can interfere with the switchover process. Use the following query toidentify any RMAN backups (and the process ID) running on the primary or standby database:

SQL> select s.process, r.operation, r.status, r.mbytes_processed as "PCT", s.status2 from v$rman_status r join v$session s using (sid);

PROCESS OPERATION STATUS PCT STATUS-------- --------------- ------- ---------- --------4033 RMAN RUNNING 0 INACTIVE4033 BACKUP RUNNING 33.96 INACTIVE

Oracle Real Application Clusters (RAC)

If the primary or standby database is configured using Real Application Clusters (RAC), verify that all butthe one primary database instance and/or one physical standby instance are shut down. When usingOracle RAC, only one primary database instance and only one physical standby instance can perform theswitchover operation. All other instances need to be shutdown before attempting the switchover

operation.

Perform Switchover Operation with a Physical Standby

Use the following steps to perform a switchover. Remember that the switchover process always begins onthe primary database and ends on the selected standby database.

1. From the primary database, query the V$DATABASE view to verify that

the SWITCHOVER_STATUS column indicates that a switchover is possible.


10/19

SQL> select switchover_status from v$database;

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

2. IfSWITCHOVER_STATUS returns a value ofTO STANDBY, then everything is good and aswitchover can occur. If on the other hand SWITCHOVER_STATUS returns SESSIONS ACTIVE,

the SWITCHOVERcommand (below) will need to be issued with the "WITH SESSION SHUTDOWN"

clause.3. Convert the primary database into a physical standby database.

SQL> alter database commit to switchover to physical standby;

Database altered.

4. As noted in the previous step, all sessions to the primary database need to be disconnected. Ifthe SWITCHOVER_STATUS column ofV$DATABASE indicated SESSIONS ACTIVE, issuethe SWITCHOVERcommand with the "WITH SESSION SHUTDOWN" clause.

SQL> alter database commit to switchover to physical standby with session shut

Database altered.

5. As part of the switchover process, all redo generation is terminated, any DML cursors areinvalidated, user connections are terminated, and the current log is archived for all threads (orjust the current thread when not using Oracle RAC). Next, a special switchover marker called

the End Of Redo (EOR) is placed in the header of the next sequence for each thread and theonline redo logs are archived again, sending the final sequences to the standby database(s). Witha physical standby database switchover, the primary database gets closed and a final log switchoccurs but does not allow the primary to advance to the next sequence.

6. After all of the above drama plays out, the primary database is converted into a standbydatabase. Before the switchover operation commits on the former primary database and beforethe current controlfile is converted to a standby controlfile, it is backed up as a trace file in

the user_dump_dest directory which makes it possible to reconstruct the current controlfile if

necessary.7. Shut down and restart the former primary as a new standby database.

SQL> shutdown immediate;ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup mount;ORACLE instance started.

Total System Global Area 1241513984 bytes


11/19

Fixed Size 1273420 bytesVariable Size 318767540 bytesDatabase Buffers 905969664 bytesRedo Buffers 15503360 bytesDatabase mounted.

8. At this point in the switchover process, there are two standby databases in my Data Guardconfiguration. We now move on to the current standby database to transition its role to primary.

9. When the primary database was transitioned to a physical standby in the previous steps, aspecial switchover marker called the End Of Redo (EOR) was placed in the redo stream and sentto the standby database(s). The EOR marker states that no more redo has been generated. Assoon as the standby receives and recovers the EOR marker, it is then eligible to become theprimary database. To ensure that the EOR marker has been recovered on the standby database

and ready for switchover to a primary, query the SWITCHOVER_STATUS column

from V$DATABASE on the standby.

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS--------------------TO PRIMARY

10. IfSWITCHOVER_STATUS returns TO PRIMARY, the EOR marker has been recovered and it ispossible to proceed to the next step which is to convert the standby to the primary role.IfSWITCHOVER_STATUS returns SESSIONS ACTIVE, disconnect any active sessions or issue

the SWITCHOVER command in the next step using the "WITH SESSION SHUTDOWN" clause.

IfSWITCHOVER_STATUS returnsNOT ALLOWED, the EOR marker has not been received andrecovered by the standby and the switchover cannot be processed.

11. Convert the former standby to a primary database.

SQL> alter database commit to switchover to primary;

Database altered.

12. Or, ifSWITCHOVER_STATUS returned SESSIONS ACTIVE in the previous step, use:

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

Database altered.

13. To complete the transition of the standby database to the primary role, the new primary databaseneeds to be shut down and restarted.

SQL> shutdown immediate;ORA-01109: database not open


12/19

Database dismounted.ORACLE instance shut down.

SQL> startup;ORACLE instance started.

Total System Global Area 1241513984 bytesFixed Size 1273420 bytesVariable Size 318767540 bytesDatabase Buffers 905969664 bytesRedo Buffers 15503360 bytesDatabase mounted.Database opened.

14. If there were other standby databases in the Data Guard configuration (not involved in theswitchover), there is no need to shut down and restart them if they were online at the time of theswitchover operation. These standby databases will continue to function normally after theswitchover completes as long as the new primary database contains

a LOG_ARCHIVE_DEST_n definition for each standby database. This ensures each standbydatabase will continue to receive redo data from the new primary database.

15. As a final step, issue either of the following statements from the new physical standby databaseto begin managed recovery operations.

[ START REDO APPLY ]

SQL> alter database recover managed standby database disconnect;

[ START REDO APPLY USING REAL-TIME APPLY ]

SQL> alter database recover managed standby database using current logfile dis

If the role transition was executed in order to perform maintenance on the former primary, it can now beshut down. When maintenance is complete, the roles can be transitioned back if necessary.

Implement Role Failover Operation

A failover operation transitions a standby database to the primary role in response to a failure on theprimary database. During a failover operation, one of the standby databases in the Data Guardconfiguration will transition its role to the primary database and the old primary database is renderedunable to participate in the configuration. That's not to say that the old primary database can never be apart of the Data Guard configuration. It can certainly be rebuilt and entered back into the configuration asa standby database. Depending on the size of the database, rebuilding the old primary and entering it

back into the Data Guard configuration could be an expensive operation as it would potentially involve alot of time and resources. Prior to Oracle Database 10g, however, this was the only option available.

Starting with Oracle Database 10gand the introduction of Flashback Database, it is now possible torewind the old primary database back in time to the point just before where the failure occurred and fromthere, bring it back into the configuration as a standby. After the Flashback Database operation, the rolescan be changed using switchover, thus bringing the primary database (and the Data Guard configuration)back to its original state.


13/19

Use the following guide to learn more about using Flashback Database after a failoveroperation:

Using Flashback Database After a Failover - (Oracle 10g)

You would typically choose the failover method only when the primary database becomes unavailableand there is no possibility of restoring it to a service within a reasonable amount of time. As a DBA, yourchief responsibility is to provide the best option that results in the least amount of interruption and dataloss. For example, if the primary database is down as the result of a failure, it may be possible to restartthe primary and perform crash recovery faster than it would be to perform a failover to a disaster site.With most companies, the decision to perform a failover will be made by management along with theadvice from the DBA. As part of any disaster recovery plan, the steps discussed in this section should betested at a minimum on a quarterly basis within an organization.

The amount of data loss incurred by a failover operation is predicated on the protection modeunderwhich the old primary database was operating under. A failover can be performed after all or most of thedata was last propagated to the standby database after the primary database became unavailable.

During a failover operation involving a physical standby database:

In all cases, the original primary database will be removed from the Data Guard configuration.

In most cases, other physical and logical standby databases not directly participating in thefailover operation will remain in the Data Guard configuration and do not have to be shutdown orrestarted. This includes standby databases running in maximum protection mode and areconfigured with standby redo logs. This also includes standby databases running in maximumavailability mode that are current and have received all redo from the primary database before thetransition.

In some cases, it might be necessary to recreate all standby databases after configuring the newprimary database. This pertains to a Data Guard configuration set up in maximum performancemode where there is a potential for data loss as will be the case in this example.

This example uses the same two-node Data Guard configuration that was created in the guide DataGuard Configuration Example - (Oracle 10g, Physical Standby) a primary database (modesto on

hostvmlinux1.idevelopment.info) sending redo to a single physical standby database (turlock on

host vmlinux2.idevelopment.info). The Data Guard protection mode for the primary database is

set to maximum performance which means the standby database does not receive any redo data until theprimary database fills its current online redo and archives it. Under normal operation, the data receivedand applied to the physical standby database is only as current as the last archived redo log sent from theprimary database.

In this section, I will be performing a role transition where the modesto database running on

host vmlinux1 (the current primary database) is considered unavailable and rendered unusable while

the turlockdatabase on vmlinux2 (the current physical standby database) will transition its role from

standby to primary using a failover operation. Since the primary database was configured for maximumperformance, there will always be a good likelihood that data loss will occur when transitioning thephysical standby database to the primary role in this configuration. Also with this protection mode, anyother standby databases in the configuration will need to be rebuilt unless they are using FlashbackDatabase.

Failover Preparation
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_3.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_3.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_3.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_3.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtml


14/19

The key to a successful failover is planning and adequate testing. It is highly recommended to test anytype of architectural change of this magnitude in a test environment before attempting it on a productionsystem!

The following is a list of checks that should be completed prior to performing a failover operation.

Initialization Parameters

One of the first steps before attempting a failover operation is to identify all initialization parameters that

must be changed to complete the role transition. For example, make certain that the VALID_FOR attribute

for the LOG_ARCHIVE_DEST_n parameter on the soon to be new primary database is configured to

assume the primary role when its role is changed. Additionally, verify thatthe service and db_unique_name are valid for each definition.

When a failover operation occurs and the standby database being transitioned was configured formaximum protection mode, you must ensure that all other standby databases in the Data Guardconfiguration that were also set up for maximum protection continue to receive logs from the new primarydatabase. With the configuration being implemented in this guide there are no other standby databasesand most of the initialization parameters are already in place for the selected standby database to

assume the primary role. Given the fact that the old primary database will be assumed unavailable afterthe failover, I set the state oflog_archive_dest_2 to defer on the physical standby databaseselected for role transition:

...log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(all_logfiles,all_rlog_archive_dest_2='service=modesto.idevelopment.info valid_for=(online_logfiles,prilog_archive_dest_state_1='ENABLE'log_archive_dest_state_2='DEFER'fal_server='modesto','turlock'fal_client='turlock'...

If the Data Guard configuration contains other standby databases configured formaximum protection mode, verify that the new primary database contains a

validLOG_ARCHIVE_DEST_n definition for each standby database. This ensures each

standby database will continue to receive redo data from the new primary database.

Recover Any Un-applied Redo

Before performing any failover operation, transfer as much available and un-applied redo data as possiblefrom the primary database to the standby database(s) in order to reduce the amount of data loss.

Change Protection Mode to Maximum Performance on the Standby

If the physical standby database involved in the failover operation is operating in maximum availability ormaximum protection mode, it will need to be placed in maximum performance mode. This step is requiredbecause you cannot fail over to a physical standby database that is in maximum protection mode.

Place the physical standby database involved in the failover operation to maximum performance mode byissuing the following SQL statement on the physical standby database:


15/19

SQL> alter database set standby database to maximize performance;

Database altered.

SQL> select protection_mode, protection_level from v$database;

PROTECTION_MODE PROTECTION_LEVEL-------------------- --------------------MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE

The Data Guard configuration being used in this guide was already in maximum performance mode andtherefore does not require the above SQL statement to be run. It doesn't hurt, however, to run it in orderto ensure the physical standby database is configured for maximum performance before attempting thefailover operation.

The above ALTER DATABASE ... will not succeed if a primary database in maximum

protection mode is still actively communicating with this standby database. Because afailover operation irreversibly removes the original primary database from the Data Guardconfiguration, these features service to protect a primary database operating in maximumprotection mode from the effects of an unintended failover operation.

Oracle Real Application Clusters (RAC)

If the standby database will be configured as a RAC primary, only one instance can perform the failoveroperation. All other instances need to be shutdown before attempting the failover operation.

Perform Failover Operation to a Physical Standby

Use the following steps to perform a failover to a physical standby database.

1. Identify and resolve any archive log gaps that may exist on the target standby database.

Query the view V$ARCHIVE_GAP on the target standby database to determine if there are gaps

in the archive sequence. This view contains the sequence numbers of any archived redo logs thatare known to be missing for each thread. The data returned reflects the lowest and highest knowngap in the archive sequence.

SQL> select * from v$archive_gap;

no rows selected

If the above query against V$ARCHIVE_GAP returns no rows, there are no known archive log

gaps.

Click hereto learn more about Log Gap Detection and Resolution.
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_5.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_5.shtmlhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_5.shtml


16/19

If the above query against V$ARCHIVE_GAP returns a record, it will display the sequence

numbers of the archived redo logs known to be missing from the standby database as illustratedin the following example:

SQL> select * from v$archive_gap;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#---------- ------------- --------------

1 854 859

From the output above, the physical standby database is currently missing archived redo logsfrom sequence 854 to sequence 859 for thread 1. If possible locate and copy all of the identifiedmissing archived redo logs to the target standby database from either the primary database (ifavailable) or from other standbys. If working in a RAC environment, this would need to includemissing archived redo logs from all threads. Once copied over, the missing archived redo logs willneed to be registered with the target standby database:

SQL> alter database register logfile '/u03/flash_recovery_area/TURLOCK/archiveDatabase altered.






2. Copy and register any other missing archived redo logs. Query the V$ARCHIVED_LOG view on all

other available standby databases in the configuration (if any others exist) to obtain the highestlog sequence number for each thread.

SQL> select unique thread# as "Thread", max(sequence#)2 over (partition by thread#) as "Last" from v$archived_log;

Thread Last---------- ----------


17/19

1 900

3. If you find any archived redo logs that contain sequence numbers higher than the highestsequence number available on the target standby database, copy and register them to the targetstandby database. If the standby database is in managed recovery mode (and why wouldn't itbe), the newly registered archived redo logs will be automatically applied to the standby. If thestandby database is not in managed recovery mode, then manually recover the newly registeredarchived redo logs. This must be done for all threads if you are in a RAC environment.

SQL> alter database register logfile '';

About Partial Archived Redo Logs

It is possible to copy over and register what is known as a partial archived redo log file. Apartial archived redo log file contains all of the primary database redo data received bythe standby database when the primary database fails, but the archived redo log is notautomatically registered in the standby database.

When you register a partial archived redo log, it prevents the recovery of the standby redologs (if they exist). Therefore, whether or not you have registered a partial archived redolog determines which failover command will be necessary to run (next step).

You will know if you registered a partial archived redo log if you get receive the followingmessage when attempting to register the archived redo log:

Register archivelog 'filespec1' was created due to a networkdisconnect;archivelog contents are valid but missing subsequent data

5. Perform terminal recovery on the target standby by issuing managed recovery mode withthe FINISH keyword. If the physical standby database is configured with active standby redo logs

AND you have not registered any partial archived redo log files, issue the following command toinitiate the failover operation:

SQL> alter database recover managed standby database finish;

Database altered.

6. If the standby database was not configured with standby redo logs, or they are not active, youmust enter the following command instead:

SQL> alter database recover managed standby database finish skip standby logfi

Database altered.

7. The above SQL statement performs incomplete recovery until the last SCN included in the latestarchived redo log available at the physical standby database.


18/19

8. Once the terminal recovery command completes, convert the physical standby into a primarydatabase using the following command:

SQL> alter database commit to switchover to primary;

Database altered.

9. After the "COMMIT TO SWITCHOVER" command completes, you can no longer use this database

as a standby database. Also, subsequent redo logs from the original primary database cannot beapplied.

The above SQL statement will only succeed if the correct "ALTER DATABASE RECOVER

MANAGED STANDBY DATABASE ... FINISH;" statement was issued in the previous

step. If you forgot the "... SKIP STANDBY LOGFILE" clause although you have no

standby redo log files, the "COMMIT TO SWITCHOVER" will fail with the error that more

media recovery is required.

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

STANDBY DATABASE" SQL statement which forces the failover operation:

SQL> alter database activate standby database;

10. To complete the failover operation, restart the new primary database in read/write mode using theappropriate initialization parameter file (or SPFILE) for the primary role:

SQL> shutdown immediate;ORA-01109: database not open

Database dismounted.ORACLE instance shut down.

SQL> startup;ORACLE instance started.

Total System Global Area 1241513984 bytesFixed Size 1273420 bytesVariable Size 318767540 bytesDatabase Buffers 905969664 bytes

Redo Buffers 15503360 bytesDatabase mounted.Database opened.

11. Perform a full backup of the new primary database!12. Keep in mind that if this was the only standby database in the Data Guard configuration, then the

database environment will be running unprotected until a new standby database can be setupand synchronized with the current primary. If Flashback Database was enabled on the originalprimary database before the failover and the original primary database is still available after the


19/19

original primary machine comes back online, it is possible to restore the original primary databaseback into the Data Guard configuration as a physical standby database using the steps outlined inthe following guide:

Using Flashback Database After a Failover - (Oracle 10g)

Further Reading

Additional information on Oracle 10gRelease 2 Data Guard can be found in the Data Guard Conceptsand Administration. This guide is available from the Oracle Documentation Library website located at thefollowing addresshttp://download.oracle.com/docs/cd/B19306_01/server.102/b14239.pdf.

About the Author

Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, andanOracle ACE. Jeff currently works as a Senior Database Administrator forThe DBA Zone, Inc.locatedin Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQLprogramming, developing high availability solutions, capacity planning, database security, and physical /

logical database design in a UNIX, Linux, and Windows server environment. Jeff's other interests includemathematical encryption theory, programming language processors (compilers and interpreters) in Javaand C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr.Database Administrator and Software Engineer for over 18 years and maintains his own website siteat:http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California,with a Bachelor's degree in Computer Science.

Copyright (c) 1998-2012 Jeffrey M. Hunter. All rights reserved.

All articles, scripts and material located at the Internet address ofhttp://www.idevelopment.info is the copyright of Jeffrey M. Hunter and isprotected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written

permission. Application to host any of the material elsewhere can be made by contacting me at [email protected].

I have made every effort and taken great care in making sure that the material included on my web s ite is technically accurate, but I disclaimany and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case

be liable for any monetary damages arising from such loss, damage or destruction.

Last modified onThursday, 19-Jan-2012 01:11:34 EST

Page Count: 12964
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtml#Flashing%20Back%20a%20Failed%20Primary%20Database%20into%20a%20Physical%20Standby%20Databasehttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtml#Flashing%20Back%20a%20Failed%20Primary%20Database%20into%20a%20Physical%20Standby%20Databasehttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtml#Flashing%20Back%20a%20Failed%20Primary%20Database%20into%20a%20Physical%20Standby%20Databasehttp://download.oracle.com/docs/cd/B19306_01/server.102/b14239.pdfhttp://download.oracle.com/docs/cd/B19306_01/server.102/b14239.pdfhttp://download.oracle.com/docs/cd/B19306_01/server.102/b14239.pdfhttp://apex.oracle.com/pls/otn/f?p=19297:4:2608385943408152::NO:4:P4_ID:183http://apex.oracle.com/pls/otn/f?p=19297:4:2608385943408152::NO:4:P4_ID:183http://apex.oracle.com/pls/otn/f?p=19297:4:2608385943408152::NO:4:P4_ID:183http://www.dbazone.com/http://www.dbazone.com/http://www.dbazone.com/http://www.idevelopment.info/http://www.idevelopment.info/http://www.idevelopment.info/http://www.idevelopment.info/mailto:[email protected]:[email protected]://www.idevelopment.info/http://www.idevelopment.info/http://www.dbazone.com/http://apex.oracle.com/pls/otn/f?p=19297:4:2608385943408152::NO:4:P4_ID:183http://download.oracle.com/docs/cd/B19306_01/server.102/b14239.pdfhttp://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_49.shtml#Flashing%20Back%20a%20Failed%20Primary%20Database%20into%20a%20Physical%20Standby%20Database

dba tips archive for oracle (activating the standby database )

Documents