Role transformation of Oracle 11g Data Guard

1.1 Introduction

The data guard configuration includes a database of 1 primary roles and a database of one or more standby roles, and the role of the database can be obtained through the Database_role field in the V$database.

In addition, the number, location, repository type of the standby library in the data guard configuration and how redo Data is transferred from the main library to the repository determines the role management scheme that can be used in the event of a failure of the main library.

When the database is running in a mutually exclusive role such as primary or standby in data guard, it is possible to dynamically change their role through SQL statements or the data Guard broker graphical interface, data The role conversions supported by the guard are switchover and failover.

• Switchover

Switchover allows the main library to switch roles to one of its repositories, no data loss during switchover, and each database continues to participate in the data Guard configuration with its new role after switching.

• Failover

Failover is used to change the repository to the main library role in response to a failure of the master library, and data loss can occur if the primary library is not running in Maximum protected mode or maximum availability mode before the failure. If the primary and standby are allowed to flash back to the database, as long as the failure is resolved, the original repository can be restored as a repository for the new primary library.

1.1.1 Role Conversion Readiness

Before you convert your roles, you need to do the following:

1. Ensure that the master repository is properly configured

Configuration parameters for Data Guard configuration, archive mode, standby log, etc. http://blog.csdn.net/u010257584/article/details/51140030, skip this, The Log_archive_dest_n and Log_archive_dest_state_n of the standby library must be configured so that the role can be converted to receive redo data from the new primary library.

2. Query V$archive_dest_status to ensure that the standby library does not have redo transmission errors and redo gaps, such as query log_archive_dest_2:

Sql> SELECT STATUS, gap_status from v$archive_dest_status WHERE dest_id = 2;

The next step can be made when the status value is valid, Gap_status is nogap.

3. Ensure that the temporary files for the master repository are consistent.

4. Remove all the latencies for the Redo app, as this may affect the standby to the primary library role.

5.RAC Master Library to physical standby, it is important to keep only one of the RAC instances open, the other instances are closed, and the other closed instances are ready to be brought back online after the conversion is complete.

6. Even if only one of the RAC instances on the standby database is open during the switchover, all other standby db instances will automatically undergo a process of correctly transitioning to their new roles when they are opened.

7. For a physical standby running in real-time query mode, before performing a role conversion, all instances of the repository can be booted to mounted instead of the open state, allowing for the fastest role conversions and the ability to completely terminate all user sessions connected to the physical standby before the role transitions.

1.1.2 Select a target repository for role conversions

For the data guard configuration of the multi-standby library, there are a number of factors to consider when choosing a target repository for role conversions, including:

1. Location and repository type of standby

2. Ability to prepare libraries (hardware specifications such as number of CPUs, available I/O bandwidth, etc.)

3. The time required to perform the role conversion, which is subject to the speed of application of the repository redo data, and the availability of the application in case of data loss.

The type of the role conversion target repository determines the role of the other standby libraries in the post-conversion configuration. For the physical repository, one of the repositories becomes the primary role, and all the other repositories in the configuration become the repository for the new primary role. For the logical repository, one of the repositories becomes the primary role, and all the other repositories in the configuration become the repository for the new primary role. However, the physical repository in this configuration will continue to be used as a repository for the old primary master library without protecting the new main library. in the latter case, if switchover or Failover is switched back to the original main library, then all the repositories of the current new main library will be returned to the original role state. In summary, the physical standby is the best role-conversion target for configurations that contain both physical and logical repositories.

The data Guard provides a v$dataguard_stats view that includes the value of each repository's traffic and the time it takes to perform role conversions (when all redo data has been applied to the repository).

For example:

<pre dir= "ltr" >SQL> column NAME format a24sql> column VALUE format A16     sql> COLUMN datum_time format A2 4sql> SELECT NAME, VALUE, datum_time from V$dataguard_stats;

The query results show that the repository receives and applies all the redo data from the main library. The value of transport lag, apply lag is estimated by the redo data from the main library, which is meaningless if there is an interruption in the connection between the primary and standby libraries. The value of the Datum_time column corresponding to the transport lag, apply lag, if not changed, indicates that they have not been updated and is meaningless, possibly due to an interruption in communication between the primary and standby libraries.

1.1.3 Switchover

Switchover is typically used to reduce the downtime of the main library during planned outages, such as upgrades to the operating system or software, and the rolling upgrades of Oracle database software or patches.

The

switchover is divided into 2 phases, the first phase, the existing main library converted to the standby role, and the second stage, The standby library to the primary library role.

When the original master library has been converted to a repository, but the original repository has not yet been converted to a new main library, the Data Guard environment is as follows:

When the original repository is converted to a new main library, that is, the main library becomes Boston, the repository becomes a SAN The Francisco,data Guard environment is as follows:

switchover, the following 2 points must be satisfied:

1.1.4 failovers

Failovers comes in handy when the main library is unavailable and it is impossible to recover it within a reasonable time. The specific actions performed by failover depend on the failure of the logical and physical standby, the configuration state of data guard at the time of failover, and the specific SQL statement when the failover is started.

Failover San Francisco Main Library to the physical standby Boston, the results are as follows:

Before failover, if possible, transfer all available and unused main library redo data to the repository.

Other prerequisites for failover role conversion are as follows:

• If the standby is running in maximum protected mode, change to the best performance mode first:

sql> ALTER Database SET STANDBY database to maximize performance;

After the conversion is complete, you can reset the standby run mode as needed.

The operating mode of the conversion repository is because the standby is running in maximum protected mode and cannot be failover, and if the primary library is running in maximum protected mode and the standby is in communication, the SQL operation to change the standby to the best performance mode will not succeed. Because the failover operation moves the main library out of the Dataguard configuration, these features are designed to protect the main library running in maximum protected mode from unexpected failover operations.

1.1.5 role Conversion triggers

The system event Db_role_change is triggered when a role conversion occurs. If the database is closed when the database is in the open State or role transformation when the role is converted, the next time the database open, the system event will be triggered immediately.

Db_role_change system events can be used to trigger and perform a series of actions when a role change occurs.

This article is about Oracle's Official document translation, and the shortcomings are welcome criticism !

Role transformation of Oracle 11g Data Guard