10g dataguard的real-time apply与no real-time apply

dg为最大可用性模式时，主库可能是通过LGWR或者ARCH传输日志到备库，当使用LGWR传到redo log到备库的standby redo log时，什么时候applied到备库时，有个概念叫：real-time apply和no real-time apply，那是什么命令来决定的呢?下面来做个实验：

 

重启备库

SQL> startup mount

SQL> select protection_mode from v$database;

PROTECTION_MODE
--------------------
MAXIMUM AVAILABILITY

SQL> alter database recover managed standby database disconnect from session;

Database altered.

这时在主库做一次switch logfile,查看备库的alert_log信息：

SQL>  alter system switch logfile;

System altered.

 

备库的log信息如下：

Managed Standby Recovery not using Real Time Apply
Media Recovery Waiting for thread 1 sequence 77
Thu Aug  1 16:42:27 2013
Completed: alter database recover managed standby database disconnect from session
Thu Aug  1 16:47:15 2013
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
RFS[2]: Successfully opened standby log 4: '/u01/app/oracle/oradata/orcl/redo04.log'
Thu Aug  1 16:47:16 2013
Media Recovery Log /u01/app/oracle/oradata/orcl/archivelog/1_82_793805797.dbf
Media Recovery Waiting for thread 1 sequence 83 (in transit)

可以看到用recover managed standby database disconnect from session时数据库用的是not using Real Time Apply，先将standby redo log生成归档日志再应用归档日志。

 

如何使备库用Real Time Apply？

 

将备库重新启到mount状态：

 

 

SQL> shutdown immediate;
ORA-01109: database not open

SQL> startup mount

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

 

这时主库再switch logfile试一下：

SQL>  alter system switch logfile;

System altered.

 

备库的log信息如下：

Thu Aug  1 16:50:33 2013
MRP0: Background Managed Standby Recovery process started (orcl)
Managed Standby Recovery starting Real Time Apply

Thu Aug  1 16:55:08 2013
Recovery of Online Redo Log: Thread 1 Group 4 Seq 91 Reading mem 0
  Mem# 0 errs 0: /u01/app/oracle/oradata/orcl/redo04.log

可以看到直接将standby log给recovery了。

那么这时备库有没有产生归档？实际上是归档了的，可以通过查看归档目录里的文件来验证一下:

SQL> show parameter log_archive_dest_1

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      location=/u01/app/oracle/orada
                                                 ta/orcl/archivelog/ VALID_FOR=
                                                 (ALL_LOGFILES,ALL_ROLES) DB_UN
                                                 IQUE_NAME=10gstandby
log_archive_dest_10                  string
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

[oracle@rhel132 archivelog]$ ls -lth /u01/app/oracle/oradata/orcl/archivelog/
total 72M
-rw-r-----  1 oracle oinstall 5.0K Aug  1 16:55 1_90_793805797.dbf
-rw-r-----  1 oracle oinstall  46K Aug  1 16:55 1_83_793805797.dbf
-rw-r-----  1 oracle oinstall  47K Aug  1 16:55 1_84_793805797.dbf
-rw-r-----  1 oracle oinstall 1.5K Aug  1 16:55 1_85_793805797.dbf
-rw-r-----  1 oracle oinstall 9.0K Aug  1 16:55 1_86_793805797.dbf
-rw-r-----  1 oracle oinstall  33K Aug  1 16:55 1_87_793805797.dbf
-rw-r-----  1 oracle oinstall 5.5K Aug  1 16:55 1_88_793805797.dbf
-rw-r-----  1 oracle oinstall 1.5K Aug  1 16:55 1_89_793805797.dbf
-rw-r-----  1 oracle oinstall  13K Aug  1 16:47 1_82_793805797.dbf
-rw-r-----  1 oracle oinstall 2.0K Aug  1 16:46 1_81_793805797.dbf
-rw-r-----  1 oracle oinstall 658K Aug  1 16:46 1_77_793805797.dbf
-rw-r-----  1 oracle oinstall  24K Aug  1 16:46 1_78_793805797.dbf
-rw-r-----  1 oracle oinstall 313K Aug  1 16:46 1_79_793805797.dbf
-rw-r-----  1 oracle oinstall 8.5K Aug  1 16:46 1_80_793805797.dbf
.....

 

可以看到最新的90号日志。