DG备库在APPLY REDO时DISK QUEUE过大的问题

深圳－刀

Windows 2008 + Oracle 10.2.0.4
DG备库在APPLY REDO时Avg. Disk Queue Length马上跳到3000以上，同时，整个OS反应变慢。REDO每个大小50M，APPLY一个大约90秒，对系统的IO进行单独检测又没有发现问题。
请问这种情况正常吗？

Maclean Liu(刘相兵

请上传  standby 上的 alert.log 、 mrp 进程的TRACE

在standby 上运行以下SQL:

show parameter recover

select process,status,client_process,sequence#,block# from v$managed_standby;

深圳－刀

SQL> show parameters recover
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string
db_recovery_file_dest_size           big integer 0
recovery_parallelism                 integer     0
SQL> select process,status,client_process,sequence#,block# from v$managed_standb
y;
PROCESS   STATUS       CLIENT_P  SEQUENCE#     BLOCK#
--------- ------------ -------- ---------- ----------
ARCH      CLOSING      ARCH          29305      94209
ARCH      CLOSING      ARCH          29306      94209
ARCH      CONNECTED    ARCH              0          0
ARCH      CLOSING      ARCH          29300      94209
ARCH      CLOSING      ARCH          29303      94209
RFS       IDLE         LGWR          29304      82406
MRP0      APPLYING_LOG N/A           23066      40917
RFS       IDLE         UNKNOWN           0          0
RFS       IDLE         UNKNOWN           0          0
RFS       IDLE         UNKNOWN           0          0
已选择10行。

Maclean Liu(刘相兵

Managed Standby Recovery not using Real Time Apply
Recovery target incarnation = 2, activation ID = 1346089011
Influx buffer limit = 96971 (50% x 193942)
Successfully allocated 7 recovery slaves
Using 158 overflow buffers per recovery slave


这里 MRP 进程分配了 7个recovery slaves

考虑  手动设置 recovery_parallelism = 1  取消 并行 recovery ，可以一定程度缓解 redo apply 对IO的压力


*** 2012-04-25 22:08:46.229
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ORADATA\ARCHIVE\STD\ARC23033_0766797318.001
*** 2012-04-25 22:12:18.854
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ORADATA\ARCHIVE\STD\ARC23034_0766797318.001

就日志的时间戳来看此standby上 apply一个 ARCHIVELOG的速度较慢， 也可能和慢的I/O有关

建议 还是能 检测一下磁盘IO性能是否存在问题。 因为DG 不能收集AWR快照， 所以性能诊断只能通过动态性能视图获得