mysql表空间增长过快_Oracle表空间增长异常解决又一例

这篇博客探讨了一个Oracle数据库中临时表空间异常增长的问题,问题出现在两个特定时间点。分析发现,问题可能由一条查询最近一周DBtime和DBCPU的SQL语句引起,由于统计信息不准确导致执行计划不佳。解决方法包括收集统计信息以优化执行计划,并修复了CATPROC组件和dbms_stats的状态,使其恢复正常。通过这些操作,SQL语句执行更快且占用的临时表空间显著减少。
摘要由CSDN通过智能技术生成

描述:客户环境某台数据库临时表空间异常增长(日期随机),观察下来可能是下列两个Oracle自身的定时job引起,

时间:2014/01/14  凌晨1点左右

2014/01/08  凌晨4点左右

已知的临时表空间增长时间,和trace文件错误吻合, 请帮忙分析原因,及解决办法。

如需要登录服务器,请电话联系陆耀祺,他将电话告知相关信息。

附件为相关日志,和一个自定义跟踪数据文件大小日志,间隔为1小时。

调查:我们发现客户环境有一条SQL语句的运行导致了临时表空间的异常增长。

这条SQL语句的意思貌似是查询最近一个星期的DB time和DB CPU。

麻烦跟开发确认一下这条语句的作用,是否可以进行优化。

后续调查:

查看dba_registry中CATPROC状态为invalid状态。同时导致在dba_objects中看到收集统计信息的dbms_stats也是invalid状态。

手动运行@?/rdbms/admin/catproc.sql编译一下这个组件(execute DBMS_REGISTRY_SYS.VALIDATE_CATPROC;);

接着重新编译一下dbms_stats这个包

再重新编译上面三个WRH$的三个基表。

原因:问题已经查明,那条SQL语句为SYS用户在晚上执行定时任务时所执行。

之所以占用较大的临时表空间是因为该语句所涉及的三张表:

WRH$_STAT_NAME

WRM$_SNAPSHOT

WRH$_SYS_TIME_MODEL

统计信息不准,导致生成了较差的执行计划。

手工收集统计信息以后,该语句可以很快完成,而且占用临时表空间也很小。

这两个数据库的CATPROC组件(Oracle Database Packages and Types)之前处于INVALID状态,造成dbms_stats存储过程处于不可用状态,因此无法自动收集统计信息。目前dbms_stats已经处于可用状态。

0b1331709591d260c1c78e86d0c51c18.png

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值