DataGuard: troubleshooting of non-real-time update small problems in the logical standby database of the DG Series

DataGuard: troubleshooting of non-real-time update small problems in the logical standby database of the DG Series

I. Overview

DataGuard is increasingly becoming an important tool for disaster recovery and pressure-sharing in databases. As the legendary DBA, you have to go to the kitchen and get to the hall. Let's take a look at this small problem.

Ii. handling process:

The non-real-time data is not artificially delayed data transmission or update. The main problem is that when the master database updates the table data backup database in a timely manner, the data is transmitted only after the master database is manually archived. That is, when the standby database of the master database does not receive the transaction (log), the master database switches to the archive backup database to read the archived log data for extraction. Transmission process for DG

Check the parameter configurations of the master database and slave database. No exception is found. A test dg Environment is set up with reference to the dg configuration, and the test environment data is updated in real time. When viewing the dg configuration document, I found that one more immediate statement was used to start the log application in the test environment. I didn't check the official and related documents before, but I thought that one more is to start the log application immediately. By viewing the official documentation, I learned that immediate means to apply logs immediately. Description:

To start SQL Apply, start the logical standby database and issue the following statement:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

To start real-time apply on the logical standby database to immediately apply redo data from the standby redo log files on the logical standby database, include the IMMEDIATE keyword as shown in the following statement:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

If the real-time apply feature is enabled, log apply services can apply redo data as it is already ed, without waiting for the current standby redo log file to be archived. this results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins.

Use the alter database statement to enable the real-time apply feature, as follows:

· For physical standby databases, issue the alter database recover managed standby database using current logfile statement.

· For logical standby databases, issue the alter database start logical standby apply immediate statement.

Standby redo log files are required to use real-time apply

Stop the log application and start it again (of course, IMMEDIATE is added this time) to view the table data. Of course, the data is updated in real time.

Iii. Summary

In fact, there is nothing to sum up. The basic knowledge is not strong, and relevant documents have not been carefully reviewed.

Install Oracle 11gR2 (x64) in CentOS 6.4)

Steps for installing Oracle 11gR2 in vmwarevm

Install Oracle 11g XE R2 In Debian

Important configuration parameters of Oracle Data Guard

Configure Oracle 11g Data Guard based on the same host

Explore Oracle 11g elastic uard

Oracle Data Guard (RAC + DG) archive deletion policies and scripts

Role conversion for Oracle Data Guard

FAL gap in Oracle Data Guard logs

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby