极端情况下DG加快恢复速度---在standby端执行,千万不可在primary端调整

Posted yunweiyipai

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了极端情况下DG加快恢复速度---在standby端执行,千万不可在primary端调整相关的知识,希望对你有一定的参考价值。

通常情况下,dg库的硬件资源都是不如主库硬件资源的,一般为主库的1/2,

那么如果主库产生归档过快那么dg库有可能日志应用不过来,可以尝试通过调整一下参数加快归档日志应用;

前方高等!!!

?在standby端执行,千万不可在primary端调整!!

 

1> 

技术图片
 1 alter system set parallel_execution_message_size=32768 scope=spfile;   --默认16384
 2 alter system set filesystemio_options=setall scope=spfile;              --默认 none
 3 alter system set disk_asynch_io=true scope=spfile;                                --默认就是true
 4 alter system set db_lost_write_protect=typical scope=spfile  ;                --默认是full
 5 alter system set db_block_checksum=false scope=spfile ;              --默认是TYPICAL
 6 alter system set DB_BLOCK_CHECKING=false scope=spfile ;            --默认是false
 7 alter system set db_writer_processes=8 scope=spfile;                            --默认是6个
 8 shutdown immediate;
 9 startup nomount;
10 alter database mount standby database;
11 alter database recover managed standby database parallel 4 disconnect from session;  ----并行度根据CPU核数*2设定
技术图片

 

另外shared_pool size过小也会影响应用速度,请遇到DG延迟的时候 可适当根据安装规范检查,防止shared pool过小。(如最小要保证2G以上)

 

2> dg库日志应用性能监控

技术图片
 1 set lines 200 pages 2000
 2 col process format a8
 3 col spid format a8
 4 col event format a50 tru
 5 col SIW format 999999
 6 
 7 select to_char(sysdate,‘DD-MON-YYYY HH24:MI:SS‘) "Current time"
 8  ,s.process
 9  , p.spid
10  , substr(s.program, -6) PROC
11  , s.event
12  , s.p1
13  , s.p2
14  , s.p3
15  , s.seconds_in_wait SIW
16  , s.seq#
17 from v$session s, v$process p
18 where p.addr = s.paddr and (s.program like ‘%MRP%‘ or s.program like ‘%PR0%‘ or s.program like ‘%DBW%‘ or s.program like ‘%CKPT%‘)
19 
20 order by s.process
21 
22 /
技术图片

以上是关于极端情况下DG加快恢复速度---在standby端执行,千万不可在primary端调整的主要内容,如果未能解决你的问题,请参考以下文章

DG archive gap

oracle dg备库实例mounted-standby状态

DG查看恢复进度

IBM Mainframe Assembler 程序在添加 COBOL 调用后显示 CPU 时间和运行时间的极端跳跃。为啥?可以做些啥来加快速度?

DG Cascade Standby

ORACLE Physical Standby 级联备库搭建