当前位置:Gxlcms > mysql > Oracle表空间增长异常解决又一例

Oracle表空间增长异常解决又一例

时间:2021-07-01 10:21:17 帮助过:49人阅读

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

描述:客户环境某台数据库临时表空间异常增长(日期随机),观察下来可能是下列两个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已经处于可用状态。

Oracle 表空间异常增长过快解决方法

Oracle教程:实例故障恢复

Linux-6-64下安装Oracle 12C笔记

在CentOS 6.4下安装Oracle 11gR2(x64)

Oracle 11gR2 在VMWare虚拟机中安装步骤

Debian 下 安装 Oracle 11g XE R2

本文永久更新链接地址:

linux

人气教程排行