Oracle DG 备库apply日志 突然变很慢

[gin_91]

如图，在备库查询同步情况，两天前的日志都还没应用。


也并不是完全停止了，还是在缓慢地执行中，只是突然变得很慢。

从主库传日志过来是正常的，日志大概20-50m/个 ，每分钟大概3-4个日志

select * from V$ARCHIVE_GAP; 没有中断日志




请问如何判断问题的原因，还需要查看哪些地方？

[gin_91]

Media Recovery Waiting for thread 1 sequence 104370 Fetching gap sequence in thread 1, gap sequence 104370-104375 Tue Mar 24 10:47:12 2015 Archived Log entry 106125 added for thread 1 sequence 109135 rlc 829578749 ID 0x50e80b7b dest 2: RFS[16]: Opened log for thread 1 sequence 109139 dbid 1357359483 branch 829578749 Tue Mar 24 10:47:16 2015 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 104370-104375 DBID 1357359483 branch 829578749 FAL[client]: All defined FAL servers have been attempted. ------------------------------------------------------------- Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter is defined to a value that is sufficiently large enough to maintain adequate log switch information to resolve archivelog gaps. alert.log出现很多这样的日志 备库 执行 select * from V$ARCHIVE_GAP; 却是空的

[gin_91]

貌似发现问题了 是因为目前的归档日志产生过快 1分钟大概100M 而主从服务器是用外网来通讯的 在不同机房 １０M的光纤 1m/s 的速度 一分钟满速才能传60M 所以造成了备库比主库的差距越来越大 接下来去找找日志产生过大的原因

[小灰狼W]

这个。。。dataguard之间用外网来通讯，不太靠谱吧

[gin_91]

[gin_91]

不能编辑帖子。。。 突然发现备库system表空间只剩0.16% 会不会是因为这个影响了备库应用重做日志的速度

[小灰狼W]

正常来说不会的，备库的表空间不足，主库也是一样。可以查看下备库的alert日志有没有相关信息 另外，备库的apply不会没打开吧 再另外，说句和同步无关的，redo切换过于频繁，考虑增大日志大小

[gin_91]

引用 6 楼 wildwave 的回复:

这个。。。dataguard之间用外网来通讯，不太靠谱吧

因为想要做异地容灾... 问题已经解决了 用oracle 的 logmini 查看了归档日志 SQL> select count(1),substr(sql_redo,1,30) from v$logmnr_contents group by substr(sql_redo,1,30) order by count(1) desc; COUNT(1) SUBSTR(SQL_REDO,1,30) ---------- ------------------------------------------------------------ 93825 update "HPT"."T_CART" set "STA 15 commit; 15 set transaction read write; 1 update "SYS"."JOB$" set "LAST_ 1 update "SYS"."JOB$" set "THIS_ 1 1 insert into "SYSMAN"."MGMT_SYS 是应用程序的代码逻辑问题，导致一直更新购物车表...产生了大量的dml 修复后 oracle的归档开始消停了

[gin_91]

手工方式运行 oracle的 LogMiner 先注册这两个SQL Oracle_home/rdbms/admin/dbmslm.sql Oracle_home/rdbms/admin/dbmslmd.sql exec sys.dbms_logmnr.add_logfile(LogFileName => '/oracle/flash_recovery_area/orcl/archivelog/ARC0000115753_0829578749.0001',Options => dbms_logmnr.new); exec sys.dbms_logmnr.start_logmnr(options=>sys.dbms_logmnr.DICT_FROM_ONLINE_CATALOG); select seg_owner,count(*) from v$logmnr_contents group by seg_owner; select count(1),substr(sql_redo,1,30) from v$logmnr_contents group by substr(sql_redo,1,30) order by count(1) desc; --日志补全,不然redoSql出现 Unsupported SQLREDO SELECT supplemental_log_data_min FROM v$database; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

[wqkjj]

LZ你这个只是治标(扼制源头)不治本，真正碰到大量DML操作，肯怕还是有会有问题。 DG的细节我没有深入研究过，但从我了解的更底层的细节来分析，貌似应该是你的消息已经从缓存消息队列溢出到持久化队列(队列表)了，因此才会速度慢下来，system自由空间也会减小