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号日志。