编者注:此问题的难点在于其隐蔽性,有时候故障现象可能不明显。例如表空间使用率瞬间从10%激增到50%时,你并没有察觉,因为没有达到告警阀值,但你却在默默承受着空间泄漏之殇。即使告警了,不明原因的客户也只是扩容表空间来简单粗暴的解决。当这个问题多年后被人行重新提起,我们不要再视而不见了,对于版本匹配的小伙伴们要做好监控和预防工作,也不枉小亦的一篇苦心。
前言
最近,我们维护的很多银行客户都收到了来自人民银行4月1日发布的Oracle缺陷风险提示,但文中未提示具体是哪个BUG,以及如何核查自己的系统是否遇到了空间泄漏的BUG。大家都很担心,担心不及时预防可能导致空间激增导致业务中断。许多客户纷纷来电中亦,咨询到底是哪个BUG并将人行4月1日发布的文件转了过来。小亦看完人行发布的文件后,七年前处理的同样的故障浮现在眼前...我们在2010年处理过几起同样的故障,表空间莫名其妙的突然涨到百分之百,导致业务中断,危害之大,触目惊心啊。时过七年,依然有客户在承受空间泄漏的问题,小亦决定打开尘封的回忆,与大家一起去回忆七年前的故事,希望帮到有需要的朋友,文后有预防和核查的方式提供。
风险提示
历史故障回放
空间都去哪了
一个神奇的视图
创建了大对象?
检查表空间大对象
如果存在表中突然加载了大量数据的情况,那么表空间内的表段、索引段等对象的大小将会变大。因此需要检查该表空间内最占空间的段是哪个。
从上述查询结果可以看到,该表空间内大于1G的段有一个,为XXX_PK索引段。
到这里真相一目了然,虽然分析到这里知道谁占用了空间,但是这还远远不够,为什么所有会有如此大的增量,为什么表没有排进TOP segment而索引确实表空间中最大的?难道索引的字段很多?我们继续分析索引怎么了?
索引怎么了?
空间泄露?
检查表字段的个数,发现表中的字段非常多,表的平均行长远大于索引字段+rowid。表实际有将近100列。
因此我们有理由相信出现了空间泄漏
如何检查空间分配
监控和判断方法
通过对比Full Blocks和FS2的和Unformatted Blocks的值,两者相差甚远,那么可能遭遇索引空间泄露或者碎片。
并同时对比索引和表的大小,如果索引比表大很多。基本可以确定是bug。
监控方法:
除了监控表空间使用率外,还要监控表空间的周期增量是否有异常。
确认bug
解决方案
临时方案:可以临时重建索引,回收空间。
根本解决方案:
Ø 安装PSU补丁至10.2.0.4.3
Ø 安装10.2.0.5 PATCHSET
或者升级到更高版本。
