RAC 11.2 architecture (III)

Standby Database

 

RAC is mainly a high-availability and scalable solution. One of its advantages is that it can protect the system from service loss when the instance fails, this causes unplanned interruptions in a single instance database.

However, RAC generally does not prevent catastrophic site faults unless it is a long-distance cluster, which is rare during installation. Similarly, human errors may lead to logical errors in the database, such as the following operations: delete a table and disable the flashback table function, use incorrect where conditions to update data, and mix the product environment with the development or test environment.

If there is no standby database, flashback database or recovery by time is required in the case of such an accident. In today's large database systems, restoration by time points often cannot be used as an option, because this means that the full database restore and recovery takes a lot of time. Additionally, RAC is used in many places to provide high availability, which also shows why downtime of several hours is intolerable. The flashback database feature introduced in Oracle 10 Gb greatly reduces the recovery time in many cases. In fact, the flashback database feature has become very useful, not only for online production database recovery, but also for Data
In the guard environment.

 

Introduction to Oracle standby Database

 

To avoid site faults or human errors, you need to add an additional precaution in the RAC environment to provide disaster tolerance capabilities. Oracle Enterprise Edition introduced a feature from Version 7.3 to meet this requirement, called Oracle Data guard.

In oracle 7 and 8/8i, this feature is called standby database. Its principle is simple and effective: a remote data center is used to create a copy that is exactly the same as an online database (or primary database. This standby database remains in the medium recovery status unless it is opened in read-only mode. Note that when the database is opened in read-only mode, the changes received by the application from the primary database cannot be applied, except for the Active Data guard option introduced in Oracle 11.1.

When there is no problem in itself, a change without an application will prolong the time required for the backup database transformation, because additional archive logs need to be applied unless you are willing to lose data. If Active Data guard is not used, the database needs to be restored in the Mount state. The Mount status prevents users outside of sysdba from connecting to the database. If you try to connect, an error message for the ORA-1033 "Oracle initialization or shutdown in progress" appears.

When the standby feature is introduced in Oracle 7.3, it requires a lot of manual processes to maintain the standby Database: The Database Administrator is responsible for transmitting the archive logs generated by the primary database to the standby site, use tools similar to RCP and FTP (rsync. After logs are transferred to the standby site, the Standby database must be in recovery mode. The only thing the administrator can do is to enable the standby database in order to take over the role of the master database. The process for DBA to copy logs is called manual recovery ).

Starting from Oracle 8i, the Standby database uses managed recovery to synchronize with the master database. Through Oracle Net * 8 Communication, the primary database transfers changes to the standby database and then applies them to data files to maintain system synchronization. The actual application of these changes can be postponed to prevent the system from being affected by the user errors mentioned above. The backup database can also be used as a report or backup data, so as to share some load from the master database.

Oracle 9i reached another milestone, introducing logical standby databases and switchover operations. In addition, the Standby database feature was officially renamed as data guard in Oracle 9i. Data Guard users also have another option to transmit redo information to standby: The archiver process was used to archive redo logs and then transfer them to the standby database. Now the log writer process can achieve this goal. Standby redo log is introduced to correspond to the online redo log of the primary database. Therefore, the redo stream can be written to standby.
In the redo log, you do not want to wait for the archived redo log, which reduces the risk of data loss. Oracle 9i database also introduces data gurad broker, which supports em and command line tools to simplify the installation and management of standby databases.

Oracle 10g has a significant development, and real-time application features are integrated into the database kernel. Use standby redo logs on the backup database server. The redo stream transmitted to the destination can be applied to the backup database immediately without waiting for the application after the standby redo log archive. It greatly reduces the possibility of data loss.

This section describes one of the 11g Oracle databases. The redo generated by user activity in the master database is processed by the log network server process (lns0) -- unlike the previous version that used log writer to transmit data to the remote file server process (RFS) of the standby database. The RFS process writes the redo stream to standby redo logs in sequence. The management recovery process (mrp0) on the standby database will immediately apply the received information. When it is filled up, the Standby redo log will be archived through one of the archive processes in the standby database.

This figure shows the physical standby configured in 11.1 for asynchronous redo transmission and real-time applications. Note that nsan is used in 11.2 instead of lsnn to asynchronously transmit redo data.

Oracle 11.1 introduces support for data errors. You can set a new parameter db_lost_write_protect to prevent data loss. Data guard will also receive the detected Bad blocks again when applying redo to the physical standby application, and vice versa. This feature is called Automatic Block Media recovery ).

In Oracle 11g R2, the limit for the previous 10 log archiving destinations (local and remote) is increased to 30 standby databases. When the master database is a rac11.2 database, the cascade standby database configuration for transferring the redo from a standby database to another standby database is unavailable (read is supported ).

Standby database types: Physical standby database, snapshot standby database, and logical standby database, transient logical standby databasephysical standby database physical standby database is the first available standby database option. In all respects, the physical standby database is a full copy of the master database from bits to bits. All Schema structures, database users, and segments are in the same level as the master database at the block level. The physical standby database is synchronized with the production database by applying redo apply. This process is the same as that performed by the database administrator after a media fault occurs in the database. In addition to disaster recovery, standby databases can also be used for reporting and backup. With a few manual steps, the physical standby database can also be used to test the tricky upgrade in the production system. You can stop receiving logs from the standby database and start the standby database in read-write mode. After the test is completed (the upgrade test is performed on the slave database with the same data as the production database), you can use the flashback database feature to restore it to the previous time point, and change back to physical standby. The disadvantage of this process is that when the standby database is opened in read-write access mode, it will not continue to receive archived logs from the master database. When it is switched back to the physical standby database, A large amount of network traffic is generated.

The Snapshot standby database snapshot standby database can hit the physical standby database and use read-write to test the same effect. In addition, the snapshot database does not need administrators to worry about the details. Snapshot standby receives archived logs from the production database, significantly reducing the overhead for solving the gap problem. At that time, after the snapshot standby database was changed back to the physical standby database, the archived logs received will be applied. Therefore, the time required for the standby database to return to the State of synchronization with the product database is proportional to the number of redo logs to be applied. When a standby database is upgraded, the redo transmission mechanism ensures that dictionary changes can be propagated to all destinations when the catalog upgrade script is executed in the master database. This applies to physical and snapshot standby database configurations. Make sure that the Oracle binary file (software) on the standby server exactly corresponds to the binary file in the master database. You can select a standby database for a single instance or a multi-node RAC system for your disaster recovery solution. However, make sure that your standby database can handle all the workload. We recommend that you use the same hardware configuration for the production environment and standby environment. If you do this, your standby database is also a RAC database, and all instances can receive redo from the master database, thus sharing the load. However, only one instance can apply redo. The logical standby database of logical standby database is different from the physical standby database. It is not a strict copy of the master database. In the initial stage of logical standby database configuration, it is the same as physical standby, but it can be opened in read-write mode. At this stage, the master database and the logical standby database are different. The physical (and snapshot) standby database synchronizes with the master database by applying redo logs. In contrast, the logical standby database synchronizes data by executing the same SQL statements as the master database. This mechanism is generally called SQL apply. SQL apply uses the log miner feature to extract SQL statements from the redo stream, and then applies this SQL statement (instead of redo) to the standby database. Therefore, the logical standby database has the same data structure as the master database, but it may be physically different. The data types supported in the master database are limited. The type list is expanded with the version. Another notable difference between physical and logical standby databases is that logical standby databases are often opened in read-write mode and can also receive changes from the production database. The logical standby database is generally not used for disaster recovery. It is mainly used to provide a report environment and share the load from the production database. It provides high data accuracy. In fact, the logical standby database is usually opened in read-write mode, which means that data structures similar to indexes and materialized views can be created in addition, to speed up the query (the maintenance cost in the master database may be too high ). Finally, the logical standby database can be used in the process of upgrading the master database or applying patches, with almost no downtime. This technology is called Rolling upgrade in Oracle documentation ). Transient logical standby database oracle is aware that few businesses are willing to configure a logical standby database only for Rolling upgrade of the database. Configuring a logical standby database is not a simple task, and maintaining the logical standby database requires close attention to whether all transactions are applied. Therefore, Oracle 11.1 provides the ability to temporarily convert a physical standby database to a logical standby database for Rolling upgrade of the database. After the upgrade, the logical standby database is changed back to the role of the initial physical standby database. This type of standby database is not listed in the document with the transient logical standby name, but as mentioned in chapter 12th of the Oracle Data guard concepts and administration guide, contains how to perform a rolling upgrade of the database. The process of rolling upgrade is the same as that of using the logical standby database during the upgrade process. However, the installation of this logical standby database is greatly simplified. Most standby databases running in the Remote Disaster Recovery Data Center of Active Data guard are waiting for activated physical standby. Many users think that resources are not used best. If the standby database is used for backup, the tape must be transferred from the Dr site to the master site when a problem occurs. In another case, standby databases are used for reports and special queries that cannot be performed on the master database. They also have the following Disadvantages: When the database is opened in read-only mode, archived logs cannot be applied, this will lead to non-synchronization between the master and slave databases, and the data will become obsolete. Starting from 11.1, Oracle lifted this concern through the active data guard option. After purchasing the Enterprise Edition, this option provides the following benefits:

• In read-only mode, you can enable recovery management for the physical standby database, which allows you to put queries on the current product data in the standby database and use both of them. Oracle calls this feature Real Time query ).
• With this option, you can use block change tracking in the standby database for faster Incremental backup.

Active Data guard can also be used as an extension tool based on the network environment. For example, multiple standby databases can be opened in read-only mode using the active data guard option to provide real-time data query for Web servers. This significantly extends data access. Data can only be updated on the master database through a controlled user interface, and these changes will be immediately presented to the user through real-time query. Role conversion data guard supports two types of role conversion: switchover and failover. During the switchover operation, the master database switches through the log and waits for the redo application to be applied to standby to ensure that no data is lost before it changes itself to the standby database. In this case, all databases in the Data guard configuration are physical standby databases. The administrator can select one of the other standby databases to act as the master database. When performing the following maintenance operations, switchover is a good solution to minimize the required time:

• Update hardware
• Migrate to another storage method, such as ASM
• Migrate to another storage array
• Transfer Data Center
• Change the font length of a Database
• Upgrade database and cluster version
• Upgrade Operating System

Although downtime cannot be completely canceled, switchover's role in executing these tasks has been verified. **************************************** **************************************** **************************************** **************************************** ******************************** A typical case of switchover

In a hardware upgrade project, we successfully deployed a switchover. In one case, we increased the number of cluster nodes from two to three, upgraded the operating system, modified the storage, and changed the database length.

The system to be replaced consists of two nodes. The 32-bit Red Hat 3.9 and the RAC of 10.2.0.3 use the first version of ocfs. The new system has three nodes. The cluster software and ASM and RDBMS versions are 10.2.0.4 and run on 64-bit rhel5.3. We use ASM to replace ocfs1. at the same time, the Standby database with the same configuration as the master database server can also be used in the remote data center. It takes more than an hour to complete the preparation and health check. **************************************** **************************************** **************************************** **************************************** * ******************************* Failover is used in more serious situations, generally, switchover is no longer available for the master database, probably because of site failure or backend data loss. In this case, the administrator should try to save as many archived logs as possible. DBAs should also minimize or eliminate the gap before enabling the standby database in read-write mode. Data may be lost Based on the protection mode configured by data guard. Before introducing the flashback database feature, activating the standby database usually means that the master database needs to be completely rebuilt by restore from the backup. Currently, if flashback is enabled for the primary database in case of a fault, it will take much less time and effort to restart and instantiate the database. For example, if a faulty database is restarted after a power failure in the data center, you can flashback it to an SCN before activating the new master database. Here, only a few commands are needed to convert the database into a physical standby. After the problem is solved, the original master database can provide services through a switchover, just as before the Failover. Depending on the standby database type (logical or physical), role conversion to primary may be slightly different, and each database administrator should be familiar with the steps required for role conversion. Regular Disaster Recovery tests should be conducted to ensure that the disaster recovery center's standby database and the entire infrastructure dependent on it (such as server Load balancer and application servers) can bear the workload. Easy-to-understand documents are also important because they can help more people with little experience to achieve this goal and stay calm at critical moments. Tip: When switchover operations involving Rac are performed, only one instance can be left before the switchover command is executed. This restriction is not partially removed until Oracle 11.2. Data Guard provides three different data protection modes. Based on business needs, data guard can be set to the maximum performance mode without affecting operations on the master database. Alternatively, it can be set to protect zero data loss. The following are the advantages and disadvantages of these three options.

Operation Mode	Description
Maximum protection	This mode provides maximum protection to ensure that no data is lost when the master database fails. To achieve this protection level, the Standby database must confirm that the redo generated by the transaction in the master database has been written to its standby redo log, and the corresponding transaction in the master database can be committed. If the master database cannot be written to the standby database's standby redo log, it will be disabled to prevent data loss. Zero data loss is expensive: the submission time of an application is higher than that of other protection modes. When a network problem occurs, the master database may be shut down.
Maximum performance	In this mode, the Standby database does not affect the performance and availability of the master database. This is the default protection level. There is no redo write dependency between the master and slave databases. In other words, the transaction commit of the master database is irrelevant to standby. Therefore, many services perform regular and forced log switching on the master database by initializing the archive_lag_target parameter.
Maximum availability	This is a balanced hybrid mode in the other two modes. When a transaction is committed in the master database, at least one synchronized standby database must receive the redo in its standby redo log. If no slave database can receive the redo stream, the master database runs in the maximum performance mode.

Data guard broker is a major part of the replication framework. It allows you to define data gurad configurations, including all types of standby databases. It is installed by default by RDBMS binary files. It is introduced in Oracle 9i and is very mature but rarely used. From the user's perspective, data guard broker simplifies the installation, maintenance, and monitoring of data guard configurations. This is also true for role switching. Of course, it fully supports RAC. After being integrated into the Enterprise Manager (EM rather than dbconsole), you only need to move the mouse and enter a small amount of keyboard to install the physical/logical standby database. Enterprise Managers integrated with brokers have higher availability than command lines. Enterprise Manager features are more abundant, but more infrastructure is needed. In use, data guard broker configures initialization parameters for instance startup through its own binary configuration file and other background processes. In this configuration, it also monitors the database. In RAC, this configuration file must be stored in shared storage. ASM, bare devices, and cluster file systems can be used to store these files. You do not need to copy this configuration to each database. On the contrary, the broker automatically maintains a Single Image view of the data guard configuration by copying the changes to all relevant databases ). You do not need to try to modify the data guard configuration by entering the command through sqlplus, because these changes may occur in the next data
The guard broker is overwritten when it is started: once it becomes a broker, it will always be a broker. In concept, the main objects for data guard broker operations are configuration, database, instance, and attribute. At the beginning, a configuration with only the master database is created, and up to 30 standby databases can be added, except for their respective attributes. Data guard broker automatically detects whether the database is composed of multiple instances and registers them to the database. After all databases are added, the Administrator is satisfied with the installation and the configuration can be enabled. In this case, the broker manages the data guard environment. The database object contains some attributes and related status information. As prompted earlier, we will not directly modify the initialization parameters. As an alternative, you can change the database status to enable/disable log transmission or resume management. With the evolution of Data guard, the database attributes that you can read and modify are constantly increasing. The following are some important attributes that you can modify:

• Synchronous and asynchronous. Synchronous/asynchronous transmission of redo to standby
• Latency of the redo application to the standby database; this setting is useful in the Multi-standby database environment to prevent human-caused data errors.
• Redo compression. Archive logs can be compressed from 11.1. Oracle 11.2 introduces the redo stream compression, but requires the license of the advanced compression option.
• Data File Name Conversion
• Conversion of log file names
• The preferred instance for applications in RAC
• Parallel Applications

When using Enterprise Manager, you do not need to remember the names of these attributes, but use graphical user interfaces (GUI) to manage data guard configurations. Data guard broker supports modifying redo transmission and application services in RAC and a single instance. Another benefit is that it allows you to set an unattended data guard configuration for automatic failover. It is called fast start failover ). With this feature, observation processes running outside the database server can monitor the master database. In some cases, you can configure to automatically switch to standby for failures. In the RAC environment, as long as a process can respond to user requests, the broker considers the RAC database to be available. From Oracle 11.1, you can control fast through the dbms_dg package
Start failover option. After the Failover is completed, data guard broker will issue a fan time to indicate that the new pig database is ready for use. Fan uses the ONS process for release time. Therefore, the database must be a RAC or a single instance database that uses Oracle restart.