本文分析了一次由于使用CREATE TABLE AS SELECT (CTS)操作引起的大规模数据复制，导致网络拥塞和大量归档日志的问题。在初始创建时未指定NOLOGGING属性，使得数据量高达7000万行，产生了大量的归档记录。解决方案是在执行CTS时添加NOLOGGING选项，然后在操作完成后切换回LOGGING模式。
接到兄弟部门通知，A机房（库a)到B机房（库b)之间的数据库服务器之间的网络带宽异常突增，影响公司对外业务的整体带宽。
一接到通知，作为数据库管理对所涉及的IP还是比较敏感。第一反应就是可能当时主库产生的归档特别多，把归档通过RFS进程到机房B的备库所消耗的带宽。表面上觉得很正常，这是oracle DG所需嘛！ 深入分析才找到了产生大量归档的根本原因：
一、先统计下异常时间短内到底产生了多少归档日志：
HOUR_END_TIME SIZE_MB
------------------- ----------
2014-03-12 17:00:00 1073.14
2014-03-12 18:00:00 21358.794
2014-03-12 19:00:00 297.538
2014-03-12 20:00:00 221.761
2014-03-12 21:00:00 312.922
2014-03-12 22:00:00 233.07
一接到通知，作为数据库管理对所涉及的IP还是比较敏感。第一反应就是可能当时主库产生的归档特别多，把归档通过RFS进程到机房B的备库所消耗的带宽。表面上觉得很正常，这是oracle DG所需嘛！ 深入分析才找到了产生大量归档的根本原因：
一、先统计下异常时间短内到底产生了多少归档日志：
HOUR_END_TIME SIZE_MB
------------------- ----------
2014-03-12 17:00:00 1073.14
2014-03-12 18:00:00 21358.794
2014-03-12 19:00:00 297.538
2014-03-12 20:00:00 221.761
2014-03-12 21:00:00 312.922
2014-03-12 22:00:00 233.07
最低0.47元/天 解锁文章
扫一扫
3028
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
