Oracle日常运维之极端情况下DG加快恢复速度--在standby端执行，千万不可在primary端调整

数据与人 2020-12-15

947

Oracle日常运维之极端情况下DG加快恢复速度--在standby端执行，千万不可在primary端调整

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

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

前方高能！！！

在standby端执行，千万不可在primary端调整！！！

1> 参数调整

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

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

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

set lines 200 pages 2000
col process format a8
col spid format a8
col event format a50 tru
col SIW format 999999


select to_char(sysdate,'DD-MON-YYYY HH24:MI:SS') "Current time"
 ,s.process
 , p.spid
 , substr(s.program, -6) PROC
 , s.event
 , s.p1
 , s.p2
 , s.p3
 , s.seconds_in_wait SIW
 , s.seq#
from v$session s, v$process p
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%')
order by s.process
/

往期回顾

MySQL日常运维之 MySQL安装部署（二进制）

MySQL日常运维之 MySQL双主复制+keepalived+haproxy配置（负载均衡）

MySQL日常运维之percona-toolkit工具pt-query-digest命令详解

客官长按关注

吾辈自强不息

oracle

文章转载自数据与人，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Oracle日常运维之极端情况下DG加快恢复速度--在standby端执行，千万不可在primary端调整

评论