9i dataguard delay使用要小心

Red Hat Enterprise Linux AS release 4 (Nahant Update 6)

9.2.0.4.0

Media Recovery Delayed for thread 1 seq# 156317 until 05/11/2012 06:30:26

Media Recovery Log /data/oracle9/arch/1_156317.dbf

Fri May 11 06:32:37 2012

Media Recovery Delayed for thread 1 seq# 156318 until 05/11/2012 07:17:37

Media Recovery Log /data/oracle9/arch/1_156318.dbf

Fri May 11 07:19:59 2012

Media Recovery Delayed for thread 1 seq# 156319 until 05/11/2012 08:04:59

Media Recovery Log /data/oracle9/arch/1_156319.dbf

Fri May 11 08:07:14 2012

Media Recovery Delayed for thread 1 seq# 156320 until 05/11/2012 08:52:14

Media Recovery Log /data/oracle9/arch/1_156320.dbf

Fri May 11 08:54:34 2012

Media Recovery Delayed for thread 1 seq# 156321 until 05/11/2012 09:39:34

Media Recovery Log /data/oracle9/arch/1_156321.dbf

Fri May 11 09:42:06 2012

Media Recovery Delayed for thread 1 seq# 156322 until 05/11/2012 10:27:06

Media Recovery Log /data/oracle9/arch/1_156322.dbf

Fri May 11 10:29:19 2012

到主库上去核实发现，备库上刚被应用的归档日志与主库的时间查远不是设置的45分钟，而且越往后时间越长，从上述的应用情况看，倒是前后两个日志应用的时间差刚好是45分钟，这与官方的说法不符！

The DELAY attribute indicates that the archived redo logs at the standby site are not available for recovery until the specified time interval has expired. The time interval is expressed in minutes, and it starts when the redo log is successfully transmitted and archived at the standby site.

When the standby database is in managed recovery mode, redo logs are automatically applied when they arrive from the primary database. However, to protect against the transfer of corrupted or erroneous data from the primary site to the standby site, you might want to create a time lag between archiving a redo log at the primary site and applying that archived redo log at the standby site.

同样的设置在11G是正常的，备库日志应用与主库的时间差等于指定的时间（delay），当然如果在这种情况下9i环境中仍然适用，就是当日志切换的时间间隔总体上大于归档日志延时应用的时间，备库的应用能跟上主库切换的脚步！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/751051/viewspace-731722/，如需转载，请注明出处，否则将追究法律责任。