| Oracle® Data Guard Concepts and Administration 11g Release 1 (11.1) Part Number B28294-01 |
|
|
View PDF |
| Oracle® Data Guard Concepts and Administration 11g Release 1 (11.1) Part Number B28294-01 |
|
|
View PDF |
This chapter describes how redo data is applied to a standby database. It includes the following topics:
Apply services automatically apply redo to standby databases to maintain synchronization with the primary database and allow transactionally consistent access to the data.
By default, apply services wait for the full archived redo log file to arrive on the standby database before applying it to the standby database. However, if you use a standby redo log, you can enable real-time apply, which allows Data Guard to recover redo data from the current standby redo log file as it is being filled. Real-time apply is described in more detail in Section 7.2.1.
Apply services use the following methods to maintain physical and logical standby databases:
Redo apply (physical standby databases only)
Uses media recovery to keep the primary and physical standby databases synchronized.
SQL Apply (logical standby databases only)
Reconstitutes SQL statements from the redo received from the primary database and executes the SQL statements against the logical standby database.
Logical standby databases can be opened in read/write mode, but the target tables being maintained by the logical standby database are opened in read-only mode for reporting purposes (providing the database guard was set appropriately). SQL Apply enables you to use the logical standby database for reporting activities, even while SQL statements are being applied.
The sections in this chapter describe Redo Apply, SQL Apply, real-time apply, and delayed apply in more detail.
This section contains the following topics:
If the real-time apply feature is enabled, apply services can apply redo data as it is received, 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.
Figure 7-1 shows a Data Guard configuration with a local destination and a standby destination. As the remote file server (RFS) process writes the redo data to standby redo log files on the standby database, apply services can recover redo from standby redo log files as they are being filled.
Figure 7-1 Applying Redo Data to a Standby Destination Using Real-Time Apply
In some cases, you may want to create a time lag between the time when redo data is received from the primary site and when it is applied to the standby database. You can specify a time interval (in minutes) to protect against the application of corrupted or erroneous data to the standby database. When you set a DELAY interval, it does not delay the transport of the redo data to the standby database. Instead, the time lag you specify begins when the redo data is completely archived at the standby destination.
Note:
If you define a delay for a destination that has real-time apply enabled, the delay is ignored.Specifying a Time Delay
You can set a time delay on primary and standby databases using the DELAY=minutes attribute of the LOG_ARCHIVE_DEST_n initialization parameter to delay applying archived redo log files to the standby database. By default, there is no time delay. If you specify the DELAY attribute without specifying a value, then the default delay interval is 30 minutes.
You can cancel a specified delay interval as follows:
For physical standby databases, use the NODELAY keyword of the RECOVER MANAGED STANDBY DATABASE clause:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
For logical standby databases, specify the following SQL statement:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
These commands result in apply services immediately beginning to apply archived redo log files to the standby database, before the time interval expires.
As an alternative to setting an apply delay, you can use Flashback Database to recover from the application of corrupted or erroneous data to the standby database. Flashback Database can quickly and easily flash back a standby database to an arbitrary point in time.
See Chapter 13 for scenarios showing how to use Data Guard with Flashback Database, and Oracle Database Backup and Recovery User's Guide for more information about enabling and using Flashback Database.
By default, the redo data is applied from archived redo log files. When performing Redo Apply, a physical standby database can use the real-time apply feature to apply redo directly from the standby redo log files as they are being written by the RFS process. Note that apply services cannot apply redo data to a physical standby database when it is opened in read-only mode.
This section contains the following topics:
To start apply services on a physical standby database, ensure the physical standby database is started and mounted and then start Redo Apply using the SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement.
You can specify that Redo Apply runs as a foreground session or as a background process, and enable it with real-time apply.
To start Redo Apply in the foreground, issue the following SQL statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
If you start a foreground session, control is not returned to the command prompt until recovery is canceled by another session.
To start Redo Apply in the background, include the DISCONNECT keyword on the SQL statement. For example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
This statement starts a detached server process and immediately returns control to the user. While the managed recovery process is performing recovery in the background, the foreground process that issued the RECOVER statement can continue performing other tasks. This does not disconnect the current SQL session.
To start real-time apply, include the USING CURRENT LOGFILE clause on the SQL statement. For example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
To stop Redo Apply, issue the following SQL statement in another window:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
To monitor the status of apply services on a physical standby database, see Section 9.5.1. You can also monitor the standby database using Oracle Enterprise Manager. Also, see the Oracle Database Reference for complete reference information about views.
SQL Apply converts the data from the archived redo log or standby redo log in to SQL statements and then executes these SQL statements on the logical standby database. Because the logical standby database remains open, tables that are maintained can be used simultaneously for other tasks such as reporting, summations, and queries.
This section contains the following topics:
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;
To stop SQL Apply, issue the following statement on the logical standby database:
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
When you issue this statement, SQL Apply waits until it has committed all complete transactions that were in the process of being applied. Thus, this command may not stop the SQL Apply processes immediately.
To monitor SQL Apply, see Section 10.2. You can also monitor the standby database using Oracle Enterprise Manager. See Appendix A, "Troubleshooting Data Guard" and Oracle Data Guard Broker.
