Oracle 归档暴涨分析

---

链接： http://blog.itpub.net/28602568/viewspace-1729075/

标题：Oracle 归档暴涨分析

作者： ｌōττéｒｙ ©版权所有[文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.]

---

    近 2 天每天归档产生量≈ 100G ，数据库相关等待事件有 log file sync 、 latch: redo allocation  … 等;

    经挖掘归档分析发现，数据库'RECODE_ERROR_MSG'表每秒记录至少2000条数据，每天至少1T数据量增长；

    且系统层多次达到多个cpu消耗>90%进程 与此表频繁记录有关,直接影响整理数据库和系统性能；

   
    分析表猛增思路/原因
    思路：本次每秒2000数据后台等待时间比较明显且有提示declare job直接看dba_jobs里的存储就发现了问题；
          若明显异常的话，需要确认表猛增原因可以通过user_source过滤RECODE_ERROR_MSG表，再进一步分析存储；

    原因：DB每分钟调用PKG_WMS_Trans_Back.proc_trans_TaskMain存储，存储又调多存储，

          被调用的多存储中包含（出现错误记录到recode_error_msg表）代码；

          存储内操作条目和操作命令较多且恰巧操作语句有问题，引起recode_error_msg记录错误表暴涨，归档暴增；

               

    建议：

       最终解决方案：尽量解决 附件报错部分问题

      紧急解决方案：关闭PKG_WMS_Trans_Back.proc_trans_TaskMain调用所有存储中包含error_msgrecode_error_msg.error_msg%type部分..按需求关闭

                  recode_error_msg 2.6亿表数据需要truncate.

   

        

     详见附件 分析报告.    ‘显示方式：WEB版式视图’--&gt免得换行乱..

      分析报告.docx

  【源于本人邮件】 若有书写错误，表达错误，请指正...

---

此条目发表在  Oracle   分类目录。将固定连接 加入收藏夹。

---

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28602568/viewspace-1729075/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28602568/viewspace-1729075/