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

gin_91 2015-03-24 10:49:33
如图,在备库查询同步情况,两天前的日志都还没应用。


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

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

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




请问如何判断问题的原因,还需要查看哪些地方?
...全文
1845 9 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
9 条回复
切换为时间正序
请发表友善的回复…
发表回复
wqkjj 2015-04-22
  • 打赏
  • 举报
回复
LZ你这个只是治标(扼制源头)不治本,真正碰到大量DML操作,肯怕还是有会有问题。 DG的细节我没有深入研究过,但从我了解的更底层的细节来分析,貌似应该是你的消息已经从缓存消息队列溢出到持久化队列(队列表)了,因此才会速度慢下来,system自由空间也会减小
gin_91 2015-03-25
  • 打赏
  • 举报
回复
手工方式运行 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;
gin_91 2015-03-25
  • 打赏
  • 举报
回复
引用 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的归档开始消停了
小灰狼W 2015-03-24
  • 打赏
  • 举报
回复
正常来说不会的,备库的表空间不足,主库也是一样。可以查看下备库的alert日志有没有相关信息 另外,备库的apply不会没打开吧 再另外,说句和同步无关的,redo切换过于频繁,考虑增大日志大小
gin_91 2015-03-24
  • 打赏
  • 举报
回复
不能编辑帖子。。。 突然发现备库system表空间只剩0.16% 会不会是因为这个影响了备库应用重做日志的速度
gin_91 2015-03-24
  • 打赏
  • 举报
回复
小灰狼W 2015-03-24
  • 打赏
  • 举报
回复
这个。。。dataguard之间用外网来通讯,不太靠谱吧
gin_91 2015-03-24
  • 打赏
  • 举报
回复
貌似发现问题了 是因为目前的归档日志产生过快 1分钟大概100M 而主从服务器是用外网来通讯的 在不同机房 10M的光纤 1m/s 的速度 一分钟满速才能传60M 所以造成了备库比主库的差距越来越大 接下来去找找日志产生过大的原因
gin_91 2015-03-24
  • 打赏
  • 举报
回复
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; 却是空的

3,494

社区成员

发帖
与我相关
我的任务
社区描述
Oracle 高级技术相关讨论专区
社区管理员
  • 高级技术社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧