Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







Data Guard switchover Tips

Oracle Database Tips by Donald BurlesonDecember 9, 2015

Oracle Data Guard - Switchover and Failover

Disadvantages of switchover to a Logical Standby Database

A logical Oracle instance provides the extraordinary feature of simultaneous recovery and reporting in a Data Guard environment. However, it is not recommended to transition to a logical Oracle instance due to the following reasons:

  •  There are limitations on a logical Oracle instance in terms of permissible data types and database operations.  Information on these limitations is presented in Chapter 3. As a result, it is very likely that a logical standby database is not a true copy of the primary database; therefore, transitioning to a logical Oracle instance may only provide a subset of functionality as delivered by the primary database.

  • If there are any physical standby databases in the configuration, the physical Oracle instance needs to be created from the new primary database after the transition.

  • Usually, role transition to a logical Oracle instance takes longer than transition to a physical standby database.

Switchover Operation

In this section, the detailed procedure for switching over to a physical or logical Oracle instance will be presented. Preparation on both the primary and the Oracle instance site must be completed in order to minimize the impact on service during role transition.

Preparing the Primary Database for Switchover

A switchover operation begins on the primary database and ends on the standby database. At the end of the switchover, the original primary database assumes the role of the standby site and vice-versa. There are a few things that should always be checked before initiating a switchover. These checks can be categorized in the following three classes:

  • Check for initialization parameters - A symmetrical initialization parameter file should always be used on the primary and all standby databases. A symmetrical init.ora file is explained in Chapter 3. For example, the init.ora file from the primary database is shown below.


Preparing the Primary Database for Switchover

  • In this example file, there are only two archival destinations. A local destination and a remote destination specified by service name "stdby2". The fal_server and fal_client parameters will be used only after the role transition:


  • Check that the Oracle Net connection can be established between the primary and the standby database.

  • Check the protection mode of the primary database by using the script, db_protection.sql, from code depot,. If the protection mode is anything other than MAXIMUM PERFOMANCE, use the following statement to change the protection mode:


  • Check the switchover status of the primary database by using the following statement. The switchover status should be "TO STANDBY":



Switchover to a Logical Standby Database

This section will provide the steps required to perform switchover to the logical standby database. A logical Oracle instance should only be considered in situations when there are no physical standby databases in the Data Guard configuration, or there is only one physical Oracle instance that shares the host machine with the primary database. The host machine will become unavailable for some time after the switchover for maintenance. The following steps should be executed to switchover to a logical standby database:

  • Before starting the switchover process, stop all connections to the primary database. A quiet database always speeds up the switchover operation.

  • The first step in the switchover process is to commit the primary database as the logical standby database. Connect to the primary database as a user having SYSDBA privilege and execute this statement:


  • The next step is to convert the logical Oracle instance into the primary database. Connect to the logical Oracle instance as a user having SYSDBA privilege and execute the following statement:


  • Optionally, the entire archive log destination can be disabled on the original primary database using ALTER SYSTEM statements.

Switchover to a Logical Standby Database

  • Create a database link on all other logical standby databases in the Data Guard configuration and link the original primary database to the new primary database. The dbms_logstdby package can be used to temporarily bypass the database guard on logical standby databases to create the database link. On the new primary database, grant the
    SELECT_CATALOG_ROLE to the database user account to be used for the database link. The database link is required for future switchover operations; therefore, this step is optional at this time.

Switchover to a logical Oracle instance will invalidate all the physical standby databases in the Data Guard configuration.

Verify Switchover Operation

A successful switchover operation will initiate transmission of redo data from the new primary database to standby databases, including the original primary database in the Data Guard configuration. To verify the switchover operation, archive the current log file on the new primary database and check the STANDBY_ARCHIVE_DEST directory on the standby databases.

If Oracle Net is configured properly, the new archived log should appear in this directory on all the standby databases. Query a Oracle instance to verify that the recent changes on the new primary database are propagated and applied to the standby databases.

If the switchover was to a logical standby database, only check the other logical Oracle instance and the original primary database for new archived log files.





The above text is an excerpt from the book: Oracle Data Guard Handbook

Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.