| Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Part Number B14239-03 |
|
|
View PDF |
| Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Part Number B14239-03 |
|
|
View PDF |
This chapter describes how redo data is applied to a standby database. It includes the following topics:
Log 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, log apply services wait for the full archived redo log file to arrive on the standby database before applying it to the standby database. Section 5.3.1 and Section 5.3.2 describe how redo data transmitted from the primary database is received by the remote file server process (RFS) on the standby system where the RFS process writes the redo data to either archived redo log files or standby redo log files. However, if you use standby redo log files, 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 up by the RFS process. Real-time apply is described in more detail in Section 6.2.1.
Log 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.
|
Caution: You can also open a physical standby database in read-only mode to allow users to query the standby database for reporting purposes. While open, redo data is still received; however, Redo Apply stops and the physical standby database is not kept synchronized with the primary database. If a failure occurs during this time, it can prolong the time it takes for a failover operation to complete. See Section 8.2, "Opening a Standby Database for Read-Only or Read/Write Access" for more information. |
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, log 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 6-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, log apply services can recover redo from standby redo log files as they are being filled.
Figure 6-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 log apply services immediately beginning to apply archived redo log files to the standby database, before the time interval expires. Also, see:
Section 12.8, "Using a Physical Standby Database with a Time Lag"
Oracle Database SQL Reference for the DELAY attribute of the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement
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 12 for scenarios showing how to use Data Guard with Flashback Database, and Oracle Database Backup and Recovery Basics 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 log 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 log 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 log apply services on a physical standby database, see Section 8.5.4. 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.
If you want to stop SQL Apply immediately, issue the following statement:
SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;
To monitor SQL Apply, see Section 9.2. You can also monitor the standby database using Oracle Enterprise Manager. See Appendix A, "Troubleshooting Data Guard" and Oracle Data Guard Broker.
Also, see the discussion about the V$ARCHIVE_DEST_STATUS fixed view in Section 8.5.4.3 and the Oracle Database Reference for complete reference information about views.
