极端情况下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 /