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. Once the 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 becomes unavailable. 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 primary database and database operations need to be switched over to the standby database. In either case, the role of the primary database and the standby database will need to be changed. This is known as Role Transition and is the subject of this article. It is assumed that a primary and one physical standby database is already configured in order to perform the role transition steps described in this guide. The examples used in this guide will make use of the Oracle 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

Oracle Release Host Name Operating System Database Name (db_name) Database Domain (db_domain) Oracle SID Database Unique Name (db_unique_name) TNS Alias Service Names Database Files - (db_create_file_dest) Flash Recovery Area (db_recovery_file_dest) Local Online Redo Log Files (log_archive_dest_1) Remote Archive Destination (log_archive_dest_2)

Oracle 10g Release 2 (10.2.0.5) vmlinux1.idevelopment.info (192.168.1.160) Red Hat Linux 5 (CentOS 5.5) modesto idevelopment.info modesto modesto modesto.idevelopment.info modesto.idevelopment.info, modesto /u02/oradata /u03/flash_recovery_area location=use_db_recovery_file_dest (all_logfiles,all_roles) service=turlock (online_logfiles,primary_role)

Physical Standby Database

Oracle Release Host Name Operating System Database Name (db_name) Database Domain (db_domain) Oracle SID Database Unique Name (db_unique_name) TNS Alias Service Names Database Files - (db_create_file_dest) Flash Recovery Area (db_recovery_file_dest) Local Online Redo Log Files Oracle 10g Release 2 (10.2.0.5) vmlinux2.idevelopment.info (192.168.1.162) Red Hat Linux 5 (CentOS 5.5) modesto idevelopment.info turlock turlock turlock.idevelopment.info turlock.idevelopment.info, turlock /u02/oradata /u03/flash_recovery_area location=use_db_recovery_file_dest

(log_archive_dest_1) Remote Archive Destination (log_archive_dest_2)

(all_logfiles,all_roles) 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 to activate a standby database to take over as the primary database. There are two types of role transitions supported in Oracle 10g Data Guard: Switchover This operation is a reversible role transition between the primary database and one of it standby databases. With a switchover, there is no data loss, and the old primary database will remain in the Data Guard configuration as a standby database. This operation is generally used to reduce primary database downtime during a scheduled outage. This may include outages related to operating 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 back to normal. Failover This operation transitions a standby database to the primary role and is typically used in response to a failure on the primary database. During a failover operation, one of the standby databases will transition its role to the primary database and the old primary database is rendered unable to participate in the configuration. (Although it could be rebuilt and entered back into the configuration as a standby database). The amount of data loss incurred by this operation is predicated 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 becomes unavailable and there is no possibility of restoring it to a service within a reasonable amount of time.

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 always choose one that best reduces downtime and has the least potential for data loss. Also to consider is how the change will affect any other standby database in the configuration. You should consider the following when 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 of transition? 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 operation to perform:

One key point to consider is that if it would be faster to repair the primary database (from failure or a simple planned hardware/software upgrade), the most efficient method would be to perform the tasks and then 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 reconfigured. Another consideration involves a Data Guard configuration which includes a logical standby database. A switchover 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 is performed on the logical standby, the physical standby will no longer be a part of the configuration and must be rebuilt. In the same scenario, if a switchover operation is performed on the physical standby, the logical standby remains in the Data Guard configuration and does not need to be rebuilt. Obviously, a physical standby is a better option to be a switchover candidate than a logical standby when multiple standby 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 standby databases. With a switchover, there is no data loss, and the old primary database will remain in the Data Guard configuration as a standby database. This operation is generally used to reduce primary database downtime during a scheduled outage. This may include outages related to operating system or hardware

upgrades. After the required tasks for the planned outage are completed, the original roles for the primary and standby database can be transitioned back to normal. This example uses the same two-node Data Guard configuration that was created in the guide Data Guard 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 tomaximum performance which means the standby database does not receive any redo data until the primary database fills its current online redo and archives it. Under normal operation, the data received and applied to the standby database is only as current as the last archived redo log sent from the primary database. 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 is implemented, the Data Guard configuration temporarily has two standby databases. 2. A standby database (in this example, there was only one physical standby database) is transitioned to the primary role. Switchover Preparation The key to a successful switchover is planning and adequate testing. It is highly recommended to test any type 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 and standby 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,primary_r [ STANDBY ] log_archive_dest_2='service=modesto.idevelopment.info valid_for=(online_logfiles,primary_r

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 Log capabilities which are used to handle log 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 databases in a Data Guard configuration (primary or standby). Setting the FAL parameters has become less important with the introduction of proactive gap resolution in Oracle9i Release 2. This new feature resolves just about any type of gap request from a physical or logical using a ping process from the primary database. On the primary database, the archive process has been designated as the ping process and will poll all standby databases looking for gaps and will also process any outstanding gap requests 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. In addition, 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 the primary 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 =

(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, attempt to 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 that the application of redo is current with the primary. From the primary database, perform a log switch and then verify the transmissions of the archived redo log file was successful. If the transmission was successful, the status of the destination will be VALID as shown below.

SQL> alter system switch logfile;

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 to the standby database. In the case of a physical standby database, verify Redo Apply by querying the status of the MRP0 process in V$MANAGED_STANDBY:

SQL> select client_process, process, sequence#, status 2 from v$managed_standby; CLIENT_PROCESS -------------ARCH ARCH ARCH ARCH N/A N/A PROCESS SEQUENCE# STATUS --------- ---------- -----------ARCH 0 CONNECTED ARCH 0 CONNECTED ARCH 0 CONNECTED ARCH 0 CONNECTED MRP0 732 WAIT_FOR_LOG RFS 0 IDLE

In the case of a physical standby database, if the MRP0 record is not returned in the above query, then redo apply is not running. In order ensure an efficient switchover process, Redo Apply should be started and 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 disconnect; If the MRP0 record is returned but shows a status of WAIT_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.

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 redo when it becomes a standby.

SQL> 2 3 4

select group#, status, type, count(*) as "Members" from v$logfile group by group#, status, type order by group#; TYPE Members ------- ---------ONLINE 2 ONLINE 2 ONLINE 2 STANDBY 2 STANDBY 2 STANDBY 2 STANDBY 2

GROUP# STATUS ---------- ------1 2 3 4 5 6 7

Cancel Jobs and Backups

Cancel any running jobs on the primary database and disable any new ones from starting. This can include RMAN backups, maintenance jobs, etc. If RMAN backups are configured to run from the standby database, stop them as well as they can interfere with the switchover process. Use the following query to identify 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.status 2 from v$rman_status r join v$session s using (sid); PROCESS -------4033 4033 OPERATION --------------RMAN BACKUP STATUS PCT ------- ---------RUNNING 0 RUNNING 33.96 STATUS -------INACTIVE INACTIVE

Oracle Real Application Clusters (RAC)

If the primary or standby database is configured using Real Application Clusters (RAC), verify that all but the one primary database instance and/or one physical standby instance are shut down. When using Oracle RAC, only one primary database instance and only one physical standby instance can perform the switchover 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 on the 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.

SQL> select switchover_status from v$database; SWITCHOVER_STATUS -------------------TO STANDBY 2. If SWITCHOVER_STATUS returns a value of TO STANDBY, then everything is good and a switchover 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. If the SWITCHOVER_STATUS column of V$DATABASE indicated SESSIONS ACTIVE, issue the SWITCHOVERcommand with the "WITH SESSION SHUTDOWN" clause.

SQL> alter database commit to switchover to physical standby with session shutdown; Database altered. 5. As part of the switchover process, all redo generation is terminated, any DML cursors are invalidated, user connections are terminated, and the current log is archived for all threads (or just 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 the online redo logs are archived again, sending the final sequences to the standby database(s). With a physical standby database switchover, the primary database gets closed and a final log switch occurs 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 standby database. Before the switchover operation commits on the former primary database and before the 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

Fixed Size Variable Size Database Buffers Redo Buffers Database mounted.

1273420 318767540 905969664 15503360

bytes bytes bytes bytes

8. At this point in the switchover process, there are two standby databases in my Data Guard configuration. 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, a special switchover marker called the End Of Redo (EOR) was placed in the redo stream and sent to the standby database(s). The EOR marker states that no more redo has been generated. As soon as the standby receives and recovers the EOR marker, it is then eligible to become the primary 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. If SWITCHOVER_STATUS returns TO PRIMARY, the EOR marker has been recovered and it is possible 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 returns NOT ALLOWED, the EOR marker has not been received and recovered 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, if SWITCHOVER_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 database needs to be shut down and restarted.

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

Database dismounted. ORACLE instance shut down. SQL> startup; ORACLE instance started. Total System Global Area 1241513984 bytes Fixed Size 1273420 bytes Variable Size 318767540 bytes Database Buffers 905969664 bytes Redo Buffers 15503360 bytes Database mounted. Database opened. 14. If there were other standby databases in the Data Guard configuration (not involved in the switchover), there is no need to shut down and restart them if they were online at the time of the switchover operation. These standby databases will continue to function normally after the switchover completes as long as 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. 15. As a final step, issue either of the following statements from the new physical standby database to 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 disconnec If the role transition was executed in order to perform maintenance on the former primary, it can now be shut 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 the primary database. During a failover operation, one of the standby databases in the Data Guard configuration will transition its role to the primary database and the old primary database is rendered unable to participate in the configuration. That's not to say that the old primary database can never be a part of the Data Guard configuration. It can certainly be rebuilt and entered back into the configuration as a 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 a lot of time and resources. Prior to Oracle Database 10 g, however, this was the only option available. Starting with Oracle Database 10g and the introduction of Flashback Database, it is now possible to rewind the old primary database back in time to the point just before where the failure occurred and from there, bring it back into the configuration as a standby. After the Flashback Database operation, the roles can be changed using switchover, thus bringing the primary database (and the Data Guard configuration) back to its original state.

Use the following guide to learn more about using Flashback Database after a failover operation: Using Flashback Database After a Failover - (Oracle 10g)

You would typically choose the failover method only when the primary database becomes unavailable and there is no possibility of restoring it to a service within a reasonable amount of time. As a DBA, your chief responsibility is to provide the best option that results in the least amount of interruption and data loss. For example, if the primary database is down as the result of a failure, it may be possible to restart the 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 the advice from the DBA. As part of any disaster recovery plan, the steps discussed in this section should be tested 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 mode under which the old primary database was operating under. A failover can be performed after all or most of the data 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 the failover operation will remain in the Data Guard configuration and do not have to be shutdown or restarted. This includes standby databases running in maximum protection mode and are configured with standby redo logs. This also includes standby databases running in maximum availability mode that are current and have received all redo from the primary database before the transition. In some cases, it might be necessary to recreate all standby databases after configuring the new primary database. This pertains to a Data Guard configuration set up in maximum performance mode 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 Data Guard 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 the primary database fills its current online redo and archives it. Under normal operation, the data received and applied to the physical standby database is only as current as the last archived redo log sent from the primary 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 maximum performance, there will always be a good likelihood that data loss will occur when transitioning the physical standby database to the primary role in this configuration. Also with this protection mode, any other standby databases in the configuration will need to be rebuilt unless they are using Flashback Database. Failover Preparation

The key to a successful failover is planning and adequate testing. It is highly recommended to test any type 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 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 that the service and db_unique_name are valid for each definition. When a failover operation occurs and the standby database being transitioned was configured for maximum protection mode, you must ensure that all other standby databases in the Data Guard configuration that were also set up for maximum protection continue to receive logs from the new primary database. With the configuration being implemented in this guide there are no other standby databases and 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 after the failover, I set the state of log_archive_dest_2 to defer on the physical standby database selected for role transition:

... log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) log_archive_dest_2='service=modesto.idevelopment.info valid_for=(online_logfiles,primary_r log_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 for maximum 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 possible from 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 or maximum protection mode, it will need to be placed in maximum performance mode. This step is required because 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 by issuing the following SQL statement on the physical standby database:

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 and therefore does not require the above SQL statement to be run. It doesn't hurt, however, to run it in order to ensure the physical standby database is configured for maximum performance before attempting the failover 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 a failover operation irreversibly removes the original primary database from the Data Guard configuration, these features service to protect a primary database operating in maximum protection 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 failover operation. 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 that are known to be missing for each thread. The data returned reflects the lowest and highest known gap 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 here to learn more about Log Gap Detection and Resolution.

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 illustrated in 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 logs from sequence 854 to sequence 859 for thread 1. If possible locate and copy all of the identified missing archived redo logs to the target standby database from either the primary database (if available) or from other standbys. If working in a RAC environment, this would need to include missing archived redo logs from all threads. Once copied over, the missing archived redo logs will need to be registered with the target standby database:

SQL> alter database register logfile '/u03/flash_recovery_area/TURLOCK/archivelog/20 Database altered. SQL> alter database register logfile '/u03/flash_recovery_area/TURLOCK/archivelog/20 Database altered.

SQL> alter database register logfile '/u03/flash_recovery_area/TURLOCK/archivelog/20 Database altered. SQL> alter database register logfile '/u03/flash_recovery_area/TURLOCK/archivelog/20 Database altered. SQL> alter database register logfile '/u03/flash_recovery_area/TURLOCK/archivelog/20 Database altered. SQL> alter database register logfile '/u03/flash_recovery_area/TURLOCK/archivelog/20 Database 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 highest log 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 ---------- ----------

900

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

SQL> alter database register logfile '<log_file_spec_n>'; About Partial Archived Redo Logs It is possible to copy over and register what is known as a partial archived redo log file. A partial archived redo log file contains all of the primary database redo data received by the standby database when the primary database fails, but the archived redo log is not automatically registered in the standby database. When you register a partial archived redo log, it prevents the recovery of the standby redo logs (if they exist). Therefore, whether or not you have registered a partial archived redo log 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 following message when attempting to register the archived redo log: Register archivelog 'filespec1' was created due to a network disconnect; archivelog contents are valid but missing subsequent data

5. Perform terminal recovery on the target standby by issuing managed recovery mode with the 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 to initiate 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, you must enter the following command instead:

SQL> alter database recover managed standby database finish skip standby logfile; Database altered. 7. The above SQL statement performs incomplete recovery until the last SCN included in the latest archived redo log available at the physical standby database.

8. Once the terminal recovery command completes, convert the physical standby into a primary database 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 be applied. 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 the appropriate 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 bytes Fixed Size 1273420 bytes Variable Size 318767540 bytes Database Buffers 905969664 bytes Redo Buffers 15503360 bytes Database 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 setup and synchronized with the current primary. If Flashback Database was enabled on the original primary database before the failover and the original primary database is still available after the

original primary machine comes back online, it is possible to restore the original primary database back into the Data Guard configuration as a physical standby database using the steps outlined in the following guide: Using Flashback Database After a Failover - (Oracle 10g)

Further Reading
Additional information on Oracle 10g Release 2 Data Guard can be found in the Data Guard Concepts and Administration. This guide is available from the Oracle Documentation Library website located at the following address http://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, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, 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 include mathematical encryption theory, programming language processors (compilers and interpreters) in Java and 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 site at: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 of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter and is protected 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 jhunter@idevelopment.info. I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any 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 on Thursday, 19-Jan-2012 01:11:34 EST Page Count: 12964