Oracle Data Guard Concept paper

A data guard configuration consists of a production library and one or more standby databases, in the data guard configuration, both the primary and standby environments can be either RAC or standalone.

This article mainly introduces some basic knowledge of dataguard

Dataguard classification, Dataguard service type, dataguard protection mode

1.Dataguard The repository is divided into physical standby and logical standby and snapshot standby.

The repository is a consistent copy of the main library, and a backup of the main library allows you to create up to 30 repositories, add them to the dataguard environment, and, once created, Dataguard maintain each of the repositories by automating the application of redo data transferred from the main library to the standby repository.

1.1 Physical Standby Library (physical standby database)

The physical standby provides the same copies physically as the primary database, the disk database structure is identical to the main library, the physical standby is a block-to-block copy, and a physical standby is synchronized with the redo data hold and the master library received from the main library, called the Log application (redo apply), The 11g Dataguard can be opened when the log is applied, and 10g is not allowed. This feature of 11g is called active Data guard.

1.2 Logical Standby Library (Logical standby database)

The logical repository contains the same logical information as the main library, the physical structure and data structures can be different, the logical repository converts the redo received from the main library into SQL statements, and then executes the SQL statement on the standby, called the SQL application (SQL apply). In addition to being able to apply to disaster recovery, the logical repository allows users to query the logical repository and generate reports through a logical standby for other purposes, using a logical repository to upgrade database software, and to patch operations without downtime.

1.3 Snapshot Standby library (Snapshot Standby database)

Snapshot repositories are available in 11g, like physical and logical repositories, where the snapshot repository receives redo data from the main library, and unlike physical or logical repositories, the snapshot repository receives only the redo data it receives. Until the snapshot repository is converted to a physical repository, discard any updates to the snapshot repository before applying the received redo data. The snapshot database is best used in a physical standby snapshot scenario that requires temporary, updatable.

Typical data guard configuration from Oracle Concept

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/73/A1/wKiom1YCaUrTFbUvAAEdLBVn9vE036.jpg "title=" Typical DG configuration. png "alt=" wkiom1ycaurtfbuvaaedlbvn9ve036.jpg "/>

2. Dataguard Service type (Data guardservices)

Log Transport service (Redo Transport services)

Log app service (apply services)

role conversion (roles transitions)

2.1 The Log shipping service manages the transfer of redo data from the production library to one or more archive directories. The Log Transport service completes the following tasks:

2.1.1 transferring redo data from the main library to the standby in the configuration

2.1.2 after the network fails, manage the missing archivelog of the repository, automatically resolve the missing

2.1.3 automatically scans for faulty or corrupt redo in the repository, and automatically re-obtains and replaces the damaged archive log from the main library or other standby repositories.

Log_archive_dest_n The initialization parameters are used to determine the location of local redo and remote archive redo. Detailed parameter resolution in Log_archive_dest_n

2.2 The Log Application service applies redo data in the standby repository, maintains and synchronizes the library's main library, redo data is applied by default from the archive redo log, and if real-time application is enabled, it is applied directly from the standby redo log, and for non-real-time application redo, when the main library log is switched, The redo log that is transferred from the main library is applied to the standby library. By default, for non-real-time apps, app service waits for the repository redo log to be archived before the archive redo log is applied, and the live app allows the app service to apply redo data from the redo log of the repository currently being populated.

How log Apps work: Redo apply and SQL apply

The main difference between the physical and the logical repositories is that the log application works differently, the physical standby uses redo apply, and the logical repository uses SQL apply, similar to the master-slave approach of MySQL.

Redo Apply use regular database recovery techniques, i.e. media recovery, on the physical standby to apply the data in the redo. :

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/73/9E/wKioL1YCaoOxZvc9AAHKF1JSHmw232.jpg "title=" Redo Apply.png "alt=" Wkiol1ycaooxzvc9aahkf1jshmw232.jpg "/>

SQL Apply using this approach on the logical repository, first convert the received redo data into SQL statements, then execute the generated SQL statements in the logical repository, and then apply them in the standby repository. The Logminer technology is used.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/73/A1/wKiom1YCanKDbydeAAIAVoLZpZU559.jpg "title=" sql Apply.png "alt=" Wkiom1ycankdbydeaaiavolzpzu559.jpg "/>

Log App service configuration

Standby Redolog

Real-time applications require that the standby database must have standby redo logs, LGWR synchronous and asynchronous transfer modes require a transport destination configuration standby redo logs, standby redo logs are used to store redo logs received from a master library, standby The redo logs are the same on the fabric and online redo logs, and the Standbyredo logs are created and managed using the same SQL that created and managed the online redo logs.

Standby The database uses the RFS foreground process to receive the redo log sent over, writes it to the current standby redo log group, and when the source database has a log switch, the incoming redo is written to the next standby redo log group, before the standby Logs are archived through the ARCN foreground process. In the source database, the process populates and archives the Redo log group sequentially, which is mirrored to each redo transport destination, where the standby database populates and archives standby redo log groups in the same order.

The size of each standby redo log must be at least as large as the largest redo log in the Redo log group of the redo source database, the standby redo log of the recommended transport destination and all logs in the redo log of the source master library are the same large.

For each redo thread of the standby database, the standby redo log is at least one redo log group than the redo log in the redo Source main library, in the source main library, the query V$log view determines the number of source main library redo log groups, for RAC, query v$ The thread view determines the number of threads redo the source master library and configures the standby redo logs used by each thread.

Operation Process:

selectgroup#,bytes from V$log; Main Library

selectgroup#,bytes from V$standby_log; Standby Library

Oracle It is recommended that the primary database in Dataguard also create standby redo logs so that switchover to the standby role can immediately receive redo data in real time

alterdatabase Add standby logfile Create or add a standby redo log, if standby redo log rent is inactive or redo transport is used to resolve the missing, then standby data received by the database is written directly to an archive redo log.

Real-time application of redo data

When real-time application features are enabled, application services can apply received redo data without waiting for the current standby redo data to be archived, which makes switchover and failover faster because standby The data in the redo log has been applied to the standby database at the beginning of failover or switchover, reducing the time it takes to switch.

Physical standby enables real-time referencing

Alterdatabase Recover managed Standby database using Curren logfile Dixconnect fromsession;

Logical standby enables real-time referencing

Alterdatabase Start logical standby apply immediate;

Enable real-time apps requires a repository configuration by standby redo logs, and the archive is turned on

Note: for log transport, it can be divided into real-time transmission (synchronous, asynchronous) and switched-time transfer (the default mode of transmission), real-time transmission is not related to real-time applications, real-time transmission is only related to Dataguard protection mode.

Delayed application Redo

To some extent, protect the application against the main library and reduce the impact of misoperation on the standby database. After you set the delay interval, you cannot delay the transfer of redo data to the standby database, only delaying the application of redo logs, starting from the standby destination to complete the archive and calculate the delay time. The archive log is applied after the end of the delay.

Specify the delay time:

In the main library and the standby set the delay time by specifying the Log_archive_dest_n initialization parameter delay=<minutes>, the default is no delay time, if the delay parameter is specified but no value is specified, the default is 30 minutes.

Cancel a specified time

Physical Standby Library

Alterdatabase Recover managed standby database Nodelay;

Logical Standby Library

Alterdatabase start logical standby apply Nodelay;

Execute the above command before the application service immediately begins applying the archive redo log file to the standby at the time interval.

2.3 use the switch over or failover operation to change the database role, convert the standby to the main library, or convert the main library to a standby.

Switchover is the conversion of a repository in the Main library, which ensures that no data is lost and is typically in a planned operation. During switchover, the main library role is turned into a standby repository, the repository is converted to the master library, and when the main library inactive, failover can convert the standby to the primary library role, failover may result in data loss, and failover is only used if the primary database fails to start.

3.dataguard the protection mode

Oracle Three protection modes are available to meet different levels of the system. Maximum protection, maximum performance, maximum availability. Three protection modes require sending redo data to at least one repository using a specific redo transfer option

3.1 Maximum Protection

If the main library fails, the maximum protection mode ensures that no data is lost, the redo data required for transaction recovery must be written to the main library's online redo log and at least one synchronized standby standby redo log before the transaction completes the commit, and if the main library cannot write redo data to at least one repository, In order to ensure that the data is not lost, the main library is closed, which is the maximum protection mode.

Conditions that must be met to use the maximum protection mode:

A. The main Library must be archived to the standby using the LGWR Sync affirm property in the Log_archive_dest_n parameter settings

B. Standby redo log must be configured for the standby library

c. at least one backup repository is available

The main library with maximum protected mode cannot use shutdown immediate to perform a close operation on a unique standby database. Because it causes the main library to close

3.2 Maximum Performance

is the default protection mode, providing the highest level of database protection mode without affecting the performance of the main library, where the user transaction of the main library is allowed to be committed once it is written to the local online redo, and it does not need to be written to at least one repository at once, as long as the main library uses arch or LGWR The Async property Archives the remote repository, and the redo data is written to one or more repositories, but for transactional commits it is done asynchronously, so delaying write redo data to the repository does not affect the performance of the main library, which provides less protection than the highest available mode, But it can affect the performance of the main library at least.

3.3 Highest Available

In the same way that the maximum protection mode is used, ensure that the redo log is fully written to the local database and at least one of the standby redo logs of the repository, before it is given the information to return the commit completion, and if for some reason the repository is unavailable, the main library cannot speak redo write to the repository standby Redo, the main library is not closed at this time, the main library will temporarily reduce the protection mode to maximum performance mode, and continue to work, once the repository is back to normal, the main library's missing elimination scheme will be started, the missing part of the archive redo log will be filled, when the main library next log open, The protection mode in the main library will also rise to the maximum availability. Use the highest available conditions that must be met:

A. The main library needs to be archived to the standby using the LGWR Sync affirm attribute in the Log_archive_dest_n initialization parameter

B. Standby redo log must be configured for the standby library

c. at least one standby repository is available

This article is from "The girl said" blog, please be sure to keep this source http://sugarlovecxq.blog.51cto.com/6707742/1697530

Oracle Data Guard Concept paper