ORACLE ARCHIVELOG 暴涨

karderax 2018-01-30 03:57:18
加精
最近归档日志突然莫名奇妙的增加了近10倍,之前每天20G左右,从19号开始每天200-300G,了解下来,19号并没有增加其他业务。查了归档日志,每天归档量如下:

19号当日归档情况如下:

从上图可知,从19号下午1点开始,归档日志就开始不正常。
从awr报告来看,都是很正常的业务操作,对比前后报告来看,没有什么异常。请大神们帮忙分析下,罪魁祸首到底是啥?

awr 和 awrdd 两个报告如下:(由于不能上传文件,可单独上传)
...全文
7974 44 打赏 收藏 转发到动态 举报
写回复
用AI写文章
44 条回复
切换为时间正序
请发表友善的回复…
发表回复
karderax 2018-02-07
  • 打赏
  • 举报
回复
[quote=引用 43 楼 minsic78 的回复:] 其实这个日志量即使再增加10倍也不大的,不能为了日志量大而停业务。[/quote 不是因为日志量大而停业务,业务当然不能停,日志严重异常,开发人员确认是他们的存储过程逻辑错误,已经修正,现在日志已恢复正常,谢谢!
minsic78 2018-02-04
  • 打赏
  • 举报
回复
其实这个日志量即使再增加10倍也不大的,不能为了日志量大而停业务。
karderax 2018-02-03
  • 打赏
  • 举报
回复
引用 41 楼 karderax 的回复:
[quote=引用 40 楼 liuzhijian2008x 的回复:] alert日志没有其他错,数据库也没有明显异常的话,bug的可能性比较小。我觉得还是业务量变大了,处理增删改的逻辑增加了,比如这个update 都这么多个版本了。你可以做个这个update语句单个语句一两个小时内的awr报告看看一两个小时执行多少次,是不是业务正常量。关键你之前得awr没有,不好对比。 还有一种就是定时任务啥的维护数据少加了条件,比如我们之前处理一个表数据,循环处理一个update 因为字段大部分都是空的,感觉都是全表扫描(加了条件也是全表),影响不大,就没有加where条件,结果导致归档日志产生超多,性能也慢。
目前解决思路: 1 先把业务数据文件都调成固定大小,并扩大5倍空间。 2 调完后看看效果,不行的话重启下数据库。 3 不行的话,升级数据库,目前版本是11.2.0.1.0 for windows,打算升级到11.2.0.4 for linux,因为之前报内存崩溃的错误,据查是ORACLE的bug所致。 暂不结贴,诚请谅解 谢谢各位的帮助,后续会持续更新情况反馈,敬请关注! [/quote] 通过1、2步的操作,问题依旧。 周末,趁没有闲杂业务,查了占用redo log 较多的会话,如下图: 是dma的job导致,终于感觉有了眉目,顺藤摸瓜,把job逐一停止,终于锁定导致归档日志暴涨的job。停掉后,归档正常。 粗略看了他们的存储过程,用了大量的中间表,很多的插入,修改,删除操作,下周一会同开发人员,要求他们重新建这种中间表,全部建成oracle临时表。 同时给他们的存储过程提出优化建议。 下周结贴,谢谢各位
karderax 2018-02-01
  • 打赏
  • 举报
回复
引用 35 楼 liuzhijian2008x 的回复:
SELECT t.SQL_ID,count(*) FROM v$active_session_history t where t.event like '%Log file switch%' and t.SAMPLE_TIME>sysdate -1 group by sql_id order by count(*) desc;
karderax 2018-02-01
  • 打赏
  • 举报
回复
引用 40 楼 liuzhijian2008x 的回复:
alert日志没有其他错,数据库也没有明显异常的话,bug的可能性比较小。我觉得还是业务量变大了,处理增删改的逻辑增加了,比如这个update 都这么多个版本了。你可以做个这个update语句单个语句一两个小时内的awr报告看看一两个小时执行多少次,是不是业务正常量。关键你之前得awr没有,不好对比。 还有一种就是定时任务啥的维护数据少加了条件,比如我们之前处理一个表数据,循环处理一个update 因为字段大部分都是空的,感觉都是全表扫描(加了条件也是全表),影响不大,就没有加where条件,结果导致归档日志产生超多,性能也慢。
目前解决思路: 1 先把业务数据文件都调成固定大小,并扩大5倍空间。 2 调完后看看效果,不行的话重启下数据库。 3 不行的话,升级数据库,目前版本是11.2.0.1.0 for windows,打算升级到11.2.0.4 for linux,因为之前报内存崩溃的错误,据查是ORACLE的bug所致。 暂不结贴,诚请谅解 谢谢各位的帮助,后续会持续更新情况反馈,敬请关注!
liu志坚 2018-02-01
  • 打赏
  • 举报
回复
alert日志没有其他错,数据库也没有明显异常的话,bug的可能性比较小。我觉得还是业务量变大了,处理增删改的逻辑增加了,比如这个update 都这么多个版本了。你可以做个这个update语句单个语句一两个小时内的awr报告看看一两个小时执行多少次,是不是业务正常量。关键你之前得awr没有,不好对比。 还有一种就是定时任务啥的维护数据少加了条件,比如我们之前处理一个表数据,循环处理一个update 因为字段大部分都是空的,感觉都是全表扫描(加了条件也是全表),影响不大,就没有加where条件,结果导致归档日志产生超多,性能也慢。
karderax 2018-02-01
  • 打赏
  • 举报
回复
引用 38 楼 liuzhijian2008x 的回复:
看看这两个sql及涉及的表? 如果alert日志里面还经常报 检查点未完成 。可以考虑加大redo log 及增加redo组数。
sql涉及的表是业务表 30号将redolog增加到500M,共6组,目前没有报Checkpoint not complete这个错误了。
liu志坚 2018-02-01
  • 打赏
  • 举报
回复
看看这两个sql及涉及的表? 如果alert日志里面还经常报 检查点未完成 。可以考虑加大redo log 及增加redo组数。
liu志坚 2018-01-31
  • 打赏
  • 举报
回复
引用 31 楼 karderax 的回复:
[quote=引用 30 楼 liuzhijian2008x 的回复:] 看alert日志有比较多的检查点未完成,日志切换相关的。你看下这个sql能查到可疑的sql不 SELECT t.SQL_ID,count(*) FROM v$active_session_history t where t.event like '%Log file switch%' group by sql_id order by count(*) desc;
这些SQL是正常的业务操作,之前也是这样的 [/quote] sql是正常业务操作,但是得看执行频率了。 update执行频率多了归档自然也多,数据量大小还没多。 最近一天的count(*) 排序的看下
minsic78 2018-01-31
  • 打赏
  • 举报
回复
可能是你SQL处理的业务数据量不一样了,看看那行排序数据量:
rows per sort,从60+暴增至1400+
karderax 2018-01-31
  • 打赏
  • 举报
回复
引用 30 楼 liuzhijian2008x 的回复:
看alert日志有比较多的检查点未完成,日志切换相关的。你看下这个sql能查到可疑的sql不 SELECT t.SQL_ID,count(*) FROM v$active_session_history t where t.event like '%Log file switch%' group by sql_id order by count(*) desc;
这些SQL是正常的业务操作,之前也是这样的
liu志坚 2018-01-31
  • 打赏
  • 举报
回复
看alert日志有比较多的检查点未完成,日志切换相关的。你看下这个sql能查到可疑的sql不 SELECT t.SQL_ID,count(*) FROM v$active_session_history t where t.event like '%Log file switch%' group by sql_id order by count(*) desc;
karderax 2018-01-31
  • 打赏
  • 举报
回复
引用 28 楼 minsic78 的回复:
[quote=引用 26 楼 karderax 的回复:] 似乎感觉是这个造成的,这个执行次数将近10倍的完整SQL如下: update seg$ set type#=:4, blocks=:5, extents=:6, minexts=:7, maxexts=:8, extsize=:9, extpct=:10, user#=:11, iniexts=:12, lists=decode(:13, 65535, NULL, :13), groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17, 0, NULL, :17), scanhint=:18, bitmapranges=:19 where ts#=:1 and file#=:2 and block#=:3 什么情况会导致这个SQL暴涨呢?
这是oracle内部操作的递归SQL,看上去像是扩展段空间的SQL,看看是不是top 5 event有enq: HW - contention?照理说这种段的扩展速度应该和平常是一致的。 是不是设置了数据文件自动扩展?而不是设置固定大小?如果数据文件自动扩展的话,也许是数据文件自动扩展的幅度每次太小,导致了表段扩展次数增多导致该递归SQL暴涨。[/quote] 没有top 5 event有enq: HW - contention。 目前都是自动扩展,扩展幅度比较乱,有的256,有点64K,有的1M,都太小了。可以试试把数据文件都调为固定大小,再观察下看看。
minsic78 2018-01-31
  • 打赏
  • 举报
回复
引用 26 楼 karderax 的回复:
似乎感觉是这个造成的,这个执行次数将近10倍的完整SQL如下: update seg$ set type#=:4, blocks=:5, extents=:6, minexts=:7, maxexts=:8, extsize=:9, extpct=:10, user#=:11, iniexts=:12, lists=decode(:13, 65535, NULL, :13), groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17, 0, NULL, :17), scanhint=:18, bitmapranges=:19 where ts#=:1 and file#=:2 and block#=:3 什么情况会导致这个SQL暴涨呢?
这是oracle内部操作的递归SQL,看上去像是扩展段空间的SQL,看看是不是top 5 event有enq: HW - contention?照理说这种段的扩展速度应该和平常是一致的。 是不是设置了数据文件自动扩展?而不是设置固定大小?如果数据文件自动扩展的话,也许是数据文件自动扩展的幅度每次太小,导致了表段扩展次数增多导致该递归SQL暴涨。
karderax 2018-01-31
  • 打赏
  • 举报
回复
引用 24 楼 liuzhijian2008x 的回复:
[quote=引用 19 楼 karderax 的回复:] [quote=引用 17 楼 liuzhijian2008x 的回复:] [quote=引用 16 楼 karderax 的回复:] [quote=引用 14 楼 liuzhijian2008x 的回复:] 把awr报告附上来看看吧
给个邮箱吧,发一份给您 [/quote] 251602048@qq.com[/quote] 您好,邮件已发,请查收[/quote] 没收到[/quote] 已重发,请查收。
karderax 2018-01-31
  • 打赏
  • 举报
回复
似乎感觉是这个造成的,这个执行次数将近10倍的完整SQL如下: update seg$ set type#=:4, blocks=:5, extents=:6, minexts=:7, maxexts=:8, extsize=:9, extpct=:10, user#=:11, iniexts=:12, lists=decode(:13, 65535, NULL, :13), groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17, 0, NULL, :17), scanhint=:18, bitmapranges=:19 where ts#=:1 and file#=:2 and block#=:3 什么情况会导致这个SQL暴涨呢?
karderax 2018-01-31
  • 打赏
  • 举报
回复
引用 21 楼 minsic78 的回复:
[quote=引用 20 楼 karderax 的回复:] [quote=引用 18 楼 minsic78 的回复:] 无论update还是insert、delete,都要记redo,这和他们涉及到的表数据量多少没有什么关系,只要DML频繁,哪怕是只更新一条记录,也可以产生大量redo
理解,会有更新,之前也是,业务上没有新变化,每天数据增量没有明显增加,但归档突然增大10倍,这个就很蹊跷[/quote] AWR和之前正常时候同时段的对比下,看看SQL执行次数是不是有突变,每秒的事务数,执行次数等等指标也可以对比下,如果没有做过任何更改,那么应用程序存在与实践相关的BUG的可能性很大[/quote] 很遗憾,由于超过7天,现在已经看不到19号的awr报告了,同时段无法比较,不过之前做过19号13点前后3个小时的对比报告。 其中标红的执行次数确实有将近10倍的增长,但这个不像是正常的业务更新啊,感觉是ORACLE的系统更新? 每秒事务数变化不大
liu志坚 2018-01-31
  • 打赏
  • 举报
回复
引用 19 楼 karderax 的回复:
[quote=引用 17 楼 liuzhijian2008x 的回复:] [quote=引用 16 楼 karderax 的回复:] [quote=引用 14 楼 liuzhijian2008x 的回复:] 把awr报告附上来看看吧
给个邮箱吧,发一份给您 [/quote] 251602048@qq.com[/quote] 您好,邮件已发,请查收[/quote] 没收到
minsic78 2018-01-31
  • 打赏
  • 举报
回复
引用 21 楼 minsic78 的回复:
[quote=引用 20 楼 karderax 的回复:] [quote=引用 18 楼 minsic78 的回复:] 无论update还是insert、delete,都要记redo,这和他们涉及到的表数据量多少没有什么关系,只要DML频繁,哪怕是只更新一条记录,也可以产生大量redo
理解,会有更新,之前也是,业务上没有新变化,每天数据增量没有明显增加,但归档突然增大10倍,这个就很蹊跷[/quote] AWR和之前正常时候同时段的对比下,看看SQL执行次数是不是有突变,每秒的事务数,执行次数等等指标也可以对比下,如果没有做过任何更改,那么应用程序存在与实践相关的BUG的可能性很大[/quote] 实践——>时间
karderax 2018-01-31
  • 打赏
  • 举报
回复
引用 18 楼 minsic78 的回复:
无论update还是insert、delete,都要记redo,这和他们涉及到的表数据量多少没有什么关系,只要DML频繁,哪怕是只更新一条记录,也可以产生大量redo
理解,会有更新,之前也是,业务上没有新变化,每天数据增量没有明显增加,但归档突然增大10倍,这个就很蹊跷
加载更多回复(24)

17,377

社区成员

发帖
与我相关
我的任务
社区描述
Oracle 基础和管理
社区管理员
  • 基础和管理社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

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