写在案例分享前


承蒙大家的喜爱,我们会一直做下去!

也希望喜欢技术人生系列的朋友们,顺手帮转发一下,您的转发是我们持续分享的动力


记得端午节和兄弟们喝酒时,有朋友说,“要不,你们成立一个用户组吧,这样更多的朋友可以以一个公益的形式加入到分享的队伍中,也可以从线上分享发展到线下分享,并且可以到各个城市中去做实战分享,让大家可以面对面的交流”;


说的有道理,于是乎,有了CESOUG,即China Experience Sharing Oracle User Group,中文名为中国经验分享Oracle用户组,希望不同城市有兴趣的朋友一起加入进来成为联合创始人(加小y微信shadow-huang-bj私聊),一起推动运维技术的分享氛围!


再然后,有了第一次线下活动的策划,活动主题是欢乐颂,就是喜欢你---ORACLE

这可能将是你参加的最精彩的一次Oracle实战类技术分享大会!

wKioL1mD1six08AbAAC_PAxWc3Y909.jpg-wh_50


y将邀请国内顶尖的Oracle实战高手一起分享,堪称史上最强阵容,内容绝对让你爽到爆,2017年首届ORACLE欢乐颂技术大会的分享嘉宾包括:

0?wx_fmt=gif

低调行者小y黄远邦

优化高手老猫陈宏义

技术狂人老K周永康

GCS RACExadata顶尖高手高斌

GCS首席技术工程师宋日杰

ACS神秘高手

金牌DBA徐戟(白鳝)

数据恢复高手程飞(惜分飞)

中行总行Oracle专家张海滨

工行总行Oracle专家邓强

以及建行总行和农行总行的Oracle专家

0?wx_fmt=gif

还在犹豫什么呢,快快识别图中二维码进行报名吧!

wKiom1mD1tSyWaePAAAVomxGdoY900.jpg-wh_50

编者注:此问题的难点在于其隐蔽性,有时候故障现象可能不明显。例如表空间使用率瞬间从10%激增到50%时,你并没有察觉,因为没有达到告警阀值,但你却在默默承受着空间泄漏之殇。即使告警了,不明原因的客户也只是扩容表空间来简单粗暴的解决。当这个问题多年后被人行重新提起,我们不要再视而不见了,对于版本匹配的小伙伴们要做好监控和预防工作,也不枉小亦的一篇苦心。

前言

最近,我们维护的很多银行客户都收到了来自人民银行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%,这和告警信息吻合。


wKiom1mD1uazLD80AAAyjM-NHUg445.png-wh_50

空间都去哪了

从以下输出可以看到,表空间大小12月1日只使用了4965M,到了12月2日使用了16561M,短短一天时间使用超过10G。由于这个表空间是业务表空间,而应用人员反馈这段时间没有大的数据插入动作。那么空间都去哪了?

一个神奇的视图

ORACLE数据库提供了一个比较冷僻的视图,WRH$_TABLESPACE_SPACE_USAGE(oracle 10g版本后提供),该视图记录了每个小时表空间的使用情况。如果表空间使用率满,则会记录表空间满的时间段。

wKioL1mD1xrx8_gJAABJYClPqWo553.png-wh_50

根据上述查询结果,可以知道在12月1日20点47分,表空间从使用318064个BLOCK突然涨至1059936个BLOCK。该时间点就是表空间满的时间点。

创建了大对象?

wKioL1mD1y7xnYuMAAAchvIHGKg168.png-wh_50

检查未发现有新的对象被创建。排除该可能。是否某个对象突然变大呢?

检查表空间大对象

如果存在表中突然加载了大量数据的情况,那么表空间内的表段、索引段等对象的大小将会变大。因此需要检查该表空间内最占空间的段是哪个。

wKiom1mD1z7wEvyqAABBuTrPb0E322.png-wh_50

从上述查询结果可以看到,该表空间内大于1G的段有一个,为XXX_PK索引段。


到这里真相一目了然,虽然分析到这里知道谁占用了空间,但是这还远远不够,为什么所有会有如此大的增量,为什么表没有排进TOP segment而索引确实表空间中最大的?难道索引的字段很多?我们继续分析索引怎么了?

索引怎么了?


wKioL1mD10-BzsBrAABDozW_z6U860.png-wh_50


可以看到,表的大小只有4G,但是索引超过了12G。这是很不正常的,除非索引在所有字段上创建,否则正常情况下不可能达到这样的大小比例。

空间泄露?


wKioL1mD12-BCa7EAAA6YpRUIBI515.png-wh_50


检查表字段的个数,发现表中的字段非常多,表的平均行长远大于索引字段+rowid。表实际有将近100列。


因此我们有理由相信出现了空间泄漏


wKioL1mD133AI4FeAABmVP-ebj8015.png-wh_50

如何检查空间分配

通过oracle自带的dbms_space包,检查最消耗空间的那个索引的空间分配情况


wKioL1mD14-Tt5l3AAAuP6TBRrY012.png-wh_50wKiom1mD15mBw-nMAACuyHyLlUw517.jpg-wh_50wKiom1mD16HRiPoBAAAgc1rw0RU636.png-wh_50


可以看到,索引中的Unformatted Blocks 达到了 740681,远远大于真正占用空间(5600+49427)。也就是说,索引把表空间所有未格式化的block据为己有,但是却未使用。这是空间泄漏的明显表现。

监控和判断方法

通过对比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

或者升级到更高版本。

如果你想听到更多的实战案例分享,快快来报名参加2017首届Oracle欢乐颂技术大会吧^_^

wKiom1mD18TA4WKAAAC_PAxWc3Y555.jpg-wh_50

识别图中二维码或者阅读全文进行报名。

wKioL1mD18uBkZ0QAAAVomxGdoY806.jpg-wh_50