参数db_lost_write_protect改变时physical standby redo apply的不同表现

kevinlin.ora

test case on : AIX 6.1 ORACLE RESTART 11.2.0.3.4 physical standby database with ASM。主库是AIX 6.1 ORACLE RAC 11.2.0.3.4 with ASM
注：备库侧有2个physical standby database，为了减少影响，全过程关闭了另一个数据库的redo apply，只接收日志。
全部过程中，主库侧：未作任何变动，所有redo日志都是自动切换生成(每个最大512M)，并且db_lost_write_protect=TYPICAL。
备库在之前预留了200多个日志文件，备库侧操作的timeline：

1. 06:40:24 SQL> show parameter lost_write
   
2. 
   
3. NAME                                 TYPE        VALUE
   
4. ------------------------------------ ----------- ------------------------------
   
5. db_lost_write_protect                string      NONE
   
6. 06:40:39 SQL>
   
7. 06:40:39 SQL> !date
   
8. Wed Nov 13 06:40:44 CST 2013
   
9. 
   
10. 06:40:44 SQL> alter database recover managed standby database using current logfile disconnect;
    
11. 
    
12. Database altered.
    
13. 
    
14. Elapsed: 00:00:09.13
    
15. 06:40:54 SQL>
    
16. 06:47:37 SQL> !date
    
17. Wed Nov 13 06:50:54 CST 2013
    
18. 
    
19. 06:50:54 SQL> alter system set db_lost_write_protect=TYPICAL scope=memory;
    
20. 
    
21. System altered.
    
22. 
    
23. Elapsed: 00:00:00.00
    
24. 06:51:06 SQL> !date
    
25. Wed Nov 13 07:02:09 CST 2013
    
26. 
    
27. 07:02:09 SQL> alter system set db_lost_write_protect=NONE scope=memory;
    
28. 
    
29. System altered.
    
30. 
    
31. Elapsed: 00:00:00.01

复制代码

备库侧的redo apply速度：
db_lost_write_protect=NONE时，10分钟约100个(只计了thread 1)
db_lost_write_protect=TYPICAL时，10分钟约5个(只计了thread 1)

db_lost_write_protect=TYPICAL时，等待事件上较显著的区别是Pr0x进程的等待事件一般总是recovery read。IO方面稳定在200M/s左右，不像db_lost_write_protect=NONE时有会一定的起伏。

具体信息如alert日志，pr进程的trace文件，nmon & topas信息以及活动会话等待事件见附件。可以对照操作timeline比较