小y 黄远邦技术人生（15） ——橙色预警：索引空间泄露导致业务中断

字数 2605阅读 1524评论 0赞 3

最近，我们维护的很多银行客户都收到了来自人民银行4月1日发布的Oracle缺陷风险提示，但文中未提示具体是哪个BUG，以及如何核查自己的系统是否遇到了空间泄漏的BUG。大家都很担心，担心不及时预防可能导致空间激增导致业务中断。许多客户纷纷来电中亦，咨询到底是哪个BUG并将人行4月1日发布的文件转了过来。小亦看完人行发布的文件后，七年前处理的同样的故障浮现在眼前...我们在2010年处理过几起同样的故障，表空间莫名其妙的突然涨到百分之百，导致业务中断，危害之大，触目惊心啊。时过七年，依然有客户在承受空间泄漏的问题，小亦决定打开尘封的回忆，与大家一起去回忆七年前的故事，希望帮到有需要的朋友，文后有预防和核查的方式提供。
**风险提示**
在某些版本较低的Oracle数据库中，可能会出现表空间莫名奇妙的增加。如果你和本文描述的几点都吻合，你可能遇到了Oracle Bug。如果你的数据库版本低于10.2.0.4.3，建议你赶快排查风险。本文末尾会介绍如何确认你的系统是否遭遇这个bug。
**历史故障回放**
2010年12月2日凌晨1点，XX系统生产环境索引表空间XXXIND使用率涨至100%,触发红色告警事件。已经造成业务中断。
检查两个小时的告警结果对比，12月1日凌晨1点表空间free为70，使用率30%，到了12月1日凌晨2点，表空间使用率free为0，使用率达到了100%，这和告警信息吻合。
![1.png](/home/attachment/201708/24/994339_150354377817609.png)

**空间都去哪了**
从以下输出可以看到，表空间大小12月1日只使用了4965M，到了12月2日使用了16561M，短短一天时间使用超过10G。
由于这个表空间是业务表空间，而应用人员反馈这段时间没有大的数据插入动作。那么空间都去哪了？
**一个神奇的视图**
ORACLE数据库提供了一个比较冷僻的视图，WRH$_TABLESPACE_SPACE_USAGE（oracle 10g版本后提供）,该视图记录了每个小时表空间的使用情况。如果表空间使用率满，则会记录表空间满的时间段。
![2.png](/home/attachment/201708/24/994339_150354385248362.png)

根据上述查询结果，可以知道在12月1日20点47分，表空间从使用318064个BLOCK突然涨至1059936个BLOCK。该时间点就是表空间满的时间点。
**创建了大对象？**
检查未发现有新的对象被创建。排除该可能。是否某个对象突然变大呢？
![3.png](/home/attachment/201708/24/994339_150354387268665.png)

**检查表空间大对象**
如果存在表中突然加载了大量数据的情况，那么表空间内的表段、索引段等对象的大小将会变大。因此需要检查该表空间内最占空间的段是哪个。
从上述查询结果可以看到，该表空间内大于1G的段有一个，为XXX_PK索引段。
![4.png](/home/attachment/201708/24/994339_150354390238199.png)

到这里真相一目了然，虽然分析到这里知道谁占用了空间，但是这还远远不够，为什么所有会有如此大的增量，为什么表没有排进TOP segment而索引确实表空间中最大的？难道索引的字段很多？我们继续分析索引怎么了？
**索引怎么了？**
![5.png](/home/attachment/201708/24/994339_150354391756316.png)

可以看到，表的大小只有4G，但是索引超过了12G。这是很不正常的，除非索引在所有字段上创建，否则正常情况下不可能达到这样的大小比例。
**空间泄露？**
检查表字段的个数，发现表中的字段非常多，表的平均行长远大于索引字段+rowid。表实际有将近100列。
![6.png](/home/attachment/201708/24/994339_150354393711198.png)

因此我们有理由相信出现了空间泄漏
**如何检查空间分配**
![7.png](/home/attachment/201708/24/994339_150354397138264.png)

通过oracle自带的dbms_space包，检查最消耗空间的那个索引的空间分配情况
可以看到，索引中的Unformatted Blocks 达到了 740681,远远大于真正占用空间(5600+49427)。
![8.png](/home/attachment/201708/24/994339_150354399446084.png)
![9.jpg](/home/attachment/201708/24/994339_150354400479432.jpg)

也就是说，索引把表空间所有未格式化的block据为己有，但是却未使用。这是空间泄漏的明显表现。
![10.png](/home/attachment/201708/24/994339_150354402669422.png)

监控和判断方法
通过对比Full Blocks和FS2的和Unformatted Blocks的值，两者相差甚远，那么可能遭遇索引空间泄露或者碎片。
并同时对比索引和表的大小，如果索引比表大很多。基本可以确定是bug。
监控方法：
除了监控表空间使用率外，还要监控表空间的周期增量是否有异常。
**确认bug**
以“Unformatted Blocks”为关键字，在ORACLE METALINK BUG库中搜索空间泄漏的相关BUG，可找到多个类似的BUG，其基本BUG均为 5890312。以下是该BUG的详细资料。该BUG在9.2.0.8、10.2.0.3和10.2.0.4版本中出现并被ORACLE确认。该BUG在PSU 10.2.0.4.3和10.2.0.5 PATSET中得到了修复。
解决方案
临时方案：可以临时重建索引，回收空间。
**根本解决方案：**
Ø 安装PSU补丁至10.2.0.4.3
Ø 安装10.2.0.5 PATCHSET
或者升级到更高版本。

数据库

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

小y 黄远邦技术人生（15） ——橙色预警：索引空间泄露导致业务中断

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料