承蒙大家的喜爱，我们会一直做下去！
也希望喜欢技术人生系列的朋友们，顺手帮转发一下，您的转发是我们持续分享的动力。
记得端午节和兄弟们喝酒时，有朋友说，“要不，你们成立一个用户组吧，这样更多的朋友可以以一个公益的形式加入到分享的队伍中，也可以从线上分享发展到线下分享，并且可以到各个城市中去做实战分享，让大家可以面对面的交流”;
说的有道理，于是乎，有了CESOUG，即China Experience Sharing Oracle User Group,中文名为中国经验分享Oracle用户组,希望不同城市有兴趣的朋友一起加入进来成为联合创始人(加小y微信shadow-huang-bj私聊),一起推动运维技术的分享氛围！
再然后，有了第一次线下活动的策划，活动主题是欢乐颂，就是喜欢你---ORACLE！
这可能将是你参加的最精彩的一次Oracle实战类技术分享大会！
小y将邀请国内顶尖的Oracle实战高手一起分享，堪称史上最强阵容，内容绝对让你爽到爆，2017年首届ORACLE欢乐颂技术大会的分享嘉宾包括：
低调行者小y黄远邦
优化高手老猫陈宏义
技术狂人老K×××
GCS RAC和Exadata顶尖高手高斌
前GCS首席技术工程师宋日杰
ACS神秘高手
金牌DBA徐戟（白鳝）
数据恢复高手程飞（惜分飞）
中行总行Oracle专家张海滨
工行总行Oracle专家邓强
以及建行总行和农行总行的Oracle专家
还在犹豫什么呢，快快识别图中二维码进行报名吧！
编者注：此问题的难点在于其隐蔽性，有时候故障现象可能不明显。例如表空间使用率瞬间从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%，这和告警信息吻合。
空间都去哪了
从以下输出可以看到，表空间大小12月1日只使用了4965M，到了12月2日使用了16561M，短短一天时间使用超过10G。由于这个表空间是业务表空间，而应用人员反馈这段时间没有大的数据插入动作。那么空间都去哪了？一个神奇的视图
ORACLE数据库提供了一个比较冷僻的视图，WRH$_TABLESPACE_SPACE_USAGE（oracle 10g版本后提供）,该视图记录了每个小时表空间的使用情况。如果表空间使用率满，则会记录表空间满的时间段。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
