在上一篇Oracle 10g DataGuard学习（二）中，我们详细解释了DG主备库间redo data传输方式及原理，当主库redo data传输到备库后，备库该如何应用，以保持主备库数据同步，这就是我们本篇要解释的问题。

Log apply services automatically apply redo to standby databases to maintain synchronization with the primary database and allow transactionally consistent access to the data. 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.
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.
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.

以来源于Oracle 10g官方文档，主要解释了log apply services通过两种方式维护主备数据库，对于物理备库而言，只能通过redo apply（介质恢复）方式同步主备库数据，对于逻辑备库而言，只能通过sql apply（执行SQL语句）方式同步主备库数据。在具体解释该含义之前，我们先看一张官档上的Applying Redo Data图：

这张图为实时应用redo data的原理图（关于LGWR SYNC概念上一篇已解释），从这个图上，我们可以清楚的看到备库RFS进程在接收到主库传来的redo daya后将其先写入到standby redo log中后，如果备库为物理备库，则由MRP进程（Media Recovery Process）将standby redo log以介质恢复的方式应用于物理备库，以此保证与主库的数据同步；如果备库为逻辑备库，则先由LSP进程（Logical Standby Process）将standby redo log解析成SQL语句，然后去逻辑备库中执行，以此保证与主库的数据同步。

关于Real-Time Apply to Apply Redo Data Immediately解释：
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.

上面说了这么一大段，其实理解Real-Time Apply to Apply Redo Data只需抓住一点：如果开始实时redo data应用，log apply services可以直接应用接收到的redo data到备库，而不用等当前的standby redo log file归档，这正可以使主备库间switchover或failover更快完成。既然有Real-Time Apply to Apply Redo Data，必然也有time delay apply redo data。通常情况下，我们希望主库产生的redo data能够及时在备库应用，这样当主库发生意外宕机（硬件故障或是地震），以failover方式切换备库后，可以立即对外提供服务，并且数据不会出现丢失或是很少丢失（如果采用最大保护模式）。那为什么这里出现了延迟redo data应用于备库呢？这是因为对于数据实时性要求不高的数据库系统，我们希望可以通过设置主备库LOG_ARCHIVE_DEST_n参数中DELAY=minutes属性来延迟redo data在备库中的应用，这样当主库应用系统发生崩溃或是错误的操作时，只要在我们设置的延迟redo data应用的时间范围内，我们就可以及时介入，暂停备库redo data应用，然后从备库中将主库应用误操作的数据库恢复回来。注意设置time delay apply redo data不会影响redo data传输，而仅影响redo data在备库中的应用。

该篇最后结合官档简单介绍redo data应用于备库的SQL命令：
Applying Redo Data to Physical Standby Databases
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.
Starting Redo Apply
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;
Stopping Redo Apply
To stop Redo Apply, issue the following SQL statement in another window:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Monitoring Redo Apply on Physical Standby Databases
To monitor the status of log apply services on a physical standby database, see DG Section 8.5.4.
Applying Redo Data to Logical Standby Databases
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.
Starting SQL Apply
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;
Stopping SQL Apply on a Logical Standby Database
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;
Monitoring SQL Apply on Logical Standby Databases
To monitor SQL Apply, see DG Section 9.2. Also, see the discussion about the V$ARCHIVE_DEST_STATUS fixed view in DG Section 8.5.4.3 and the Oracle Database Reference for complete reference information.

以上为该篇内容，到此我们用了三个篇幅来解释DG的基本原理及基础理论知识，后面将会更新DG的搭建，切换及调优，敬请期待！