寫在案例分享前

成都創(chuàng)新互聯(lián)主營東源網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,手機(jī)APP定制開發(fā),東源h5微信小程序搭建,東源網(wǎng)站營銷推廣歡迎東源等地區(qū)企業(yè)咨詢

承蒙大家的喜愛，我們會一直做下去！

也希望喜歡技術(shù)人生系列的朋友們，順手幫轉(zhuǎn)發(fā)一下，您的轉(zhuǎn)發(fā)是我們持續(xù)分享的動力。

記得端午節(jié)和兄弟們喝酒時，有朋友說，“要不，你們成立一個用戶組吧，這樣更多的朋友可以以一個公益的形式加入到分享的隊(duì)伍中，也可以從線上分享發(fā)展到線下分享，并且可以到各個城市中去做實(shí)戰(zhàn)分享，讓大家可以面對面的交流”;

說的有道理，于是乎，有了CESOUG，即China Experience Sharing Oracle User Group,中文名為中國經(jīng)驗(yàn)分享Oracle用戶組,希望不同城市有興趣的朋友一起加入進(jìn)來成為聯(lián)合創(chuàng)始人(加小y微信shadow-huang-bj私聊),一起推動運(yùn)維技術(shù)的分享氛圍！

再然后，有了第一次線下活動的策劃，活動主題是歡樂頌，就是喜歡你---ORACLE！

這可能將是你參加的最精彩的一次Oracle實(shí)戰(zhàn)類技術(shù)分享大會！

小y將邀請國內(nèi)頂尖的Oracle實(shí)戰(zhàn)高手一起分享，堪稱史上最強(qiáng)陣容，內(nèi)容絕對讓你爽到爆，2017年首屆ORACLE歡樂頌技術(shù)大會的分享嘉賓包括：

低調(diào)行者小y黃遠(yuǎn)邦

優(yōu)化高手老貓陳宏義

技術(shù)狂人老K×××

GCS RAC和Exadata頂尖高手高斌

前GCS首席技術(shù)工程師宋日杰

ACS神秘高手

金牌DBA徐戟（白鱔）

數(shù)據(jù)恢復(fù)高手程飛（惜分飛）

中行總行Oracle專家張海濱

工行總行Oracle專家鄧強(qiáng)

以及建行總行和農(nóng)行總行的Oracle專家

還在猶豫什么呢，快快識別圖中二維碼進(jìn)行報名吧！

編者注：此問題的難點(diǎn)在于其隱蔽性，有時候故障現(xiàn)象可能不明顯。例如表空間使用率瞬間從10%激增到50%時，你并沒有察覺，因?yàn)闆]有達(dá)到告警閥值，但你卻在默默承受著空間泄漏之殤。即使告警了，不明原因的客戶也只是擴(kuò)容表空間來簡單粗暴的解決。當(dāng)這個問題多年后被人行重新提起，我們不要再視而不見了，對于版本匹配的小伙伴們要做好監(jiān)控和預(yù)防工作，也不枉小亦的一篇苦心。

前言

最近，我們維護(hù)的很多×××都收到了來自人民銀行4月1日發(fā)布的Oracle缺陷風(fēng)險提示，但文中未提示具體是哪個BUG，以及如何核查自己的系統(tǒng)是否遇到了空間泄漏的BUG。大家都很擔(dān)心，擔(dān)心不及時預(yù)防可能導(dǎo)致空間激增導(dǎo)致業(yè)務(wù)中斷。許多客戶紛紛來電中亦，咨詢到底是哪個BUG并將人行4月1日發(fā)布的文件轉(zhuǎn)了過來。小亦看完人行發(fā)布的文件后，七年前處理的同樣的故障浮現(xiàn)在眼前...我們在2010年處理過幾起同樣的故障，表空間莫名其妙的突然漲到百分之百，導(dǎo)致業(yè)務(wù)中斷，危害之大，觸目驚心啊。時過七年，依然有客戶在承受空間泄漏的問題，小亦決定打開塵封的回憶，與大家一起去回憶七年前的故事，希望幫到有需要的朋友，文后有預(yù)防和核查的方式提供。

風(fēng)險提示

在某些版本較低的Oracle數(shù)據(jù)庫中，可能會出現(xiàn)表空間莫名奇妙的增加。如果你和本文描述的幾點(diǎn)都吻合，你可能遇到了Oracle Bug。如果你的數(shù)據(jù)庫版本低于10.2.0.4.3，建議你趕快排查風(fēng)險。本文末尾會介紹如何確認(rèn)你的系統(tǒng)是否遭遇這個bug。

歷史故障回放

2010年12月2日凌晨1點(diǎn)，XX系統(tǒng)生產(chǎn)環(huán)境索引表空間XXXIND使用率漲至100%,觸發(fā)紅色告警事件。已經(jīng)造成業(yè)務(wù)中斷。檢查兩個小時的告警結(jié)果對比，12月1日凌晨1點(diǎn)表空間free為70，使用率30%，到了12月1日凌晨2點(diǎn)，表空間使用率free為0，使用率達(dá)到了100%，這和告警信息吻合。

空間都去哪了

從以下輸出可以看到，表空間大小12月1日只使用了4965M，到了12月2日使用了16561M，短短一天時間使用超過10G。由于這個表空間是業(yè)務(wù)表空間，而應(yīng)用人員反饋這段時間沒有大的數(shù)據(jù)插入動作。那么空間都去哪了？

一個神奇的視圖

ORACLE數(shù)據(jù)庫提供了一個比較冷僻的視圖，WRH$_TABLESPACE_SPACE_USAGE（oracle 10g版本后提供）,該視圖記錄了每個小時表空間的使用情況。如果表空間使用率滿，則會記錄表空間滿的時間段。

根據(jù)上述查詢結(jié)果，可以知道在12月1日20點(diǎn)47分，表空間從使用318064個BLOCK突然漲至1059936個BLOCK。該時間點(diǎn)就是表空間滿的時間點(diǎn)。

創(chuàng)建了大對象？

檢查未發(fā)現(xiàn)有新的對象被創(chuàng)建。排除該可能。是否某個對象突然變大呢？

檢查表空間大對象

如果存在表中突然加載了大量數(shù)據(jù)的情況，那么表空間內(nèi)的表段、索引段等對象的大小將會變大。因此需要檢查該表空間內(nèi)最占空間的段是哪個。

從上述查詢結(jié)果可以看到，該表空間內(nèi)大于1G的段有一個，為XXX_PK索引段。

到這里真相一目了然，雖然分析到這里知道誰占用了空間，但是這還遠(yuǎn)遠(yuǎn)不夠，為什么所有會有如此大的增量，為什么表沒有排進(jìn)TOP segment而索引確實(shí)表空間中最大的？難道索引的字段很多？我們繼續(xù)分析索引怎么了？

索引怎么了？

可以看到，表的大小只有4G，但是索引超過了12G。這是很不正常的，除非索引在所有字段上創(chuàng)建，否則正常情況下不可能達(dá)到這樣的大小比例。

空間泄露？

檢查表字段的個數(shù)，發(fā)現(xiàn)表中的字段非常多，表的平均行長遠(yuǎn)大于索引字段+rowid。表實(shí)際有將近100列。

因此我們有理由相信出現(xiàn)了空間泄漏

如何檢查空間分配

通過oracle自帶的dbms_space包，檢查最消耗空間的那個索引的空間分配情況

可以看到，索引中的Unformatted Blocks 達(dá)到了 740681,遠(yuǎn)遠(yuǎn)大于真正占用空間(5600+49427)。也就是說，索引把表空間所有未格式化的block據(jù)為己有，但是卻未使用。這是空間泄漏的明顯表現(xiàn)。

監(jiān)控和判斷方法

通過對比Full Blocks和FS2的和Unformatted Blocks的值，兩者相差甚遠(yuǎn)，那么可能遭遇索引空間泄露或者碎片。

并同時對比索引和表的大小，如果索引比表大很多?；究梢源_定是bug。

監(jiān)控方法：

除了監(jiān)控表空間使用率外，還要監(jiān)控表空間的周期增量是否有異常。

確認(rèn)bug

以“Unformatted Blocks”為關(guān)鍵字，在ORACLE METALINK BUG庫中搜索空間泄漏的相關(guān)BUG，可找到多個類似的BUG，其基本BUG均為 5890312。以下是該BUG的詳細(xì)資料。該BUG在9.2.0.8、10.2.0.3和10.2.0.4版本中出現(xiàn)并被ORACLE確認(rèn)。該BUG在PSU 10.2.0.4.3和10.2.0.5 PATSET中得到了修復(fù)。

解決方案

臨時方案：可以臨時重建索引，回收空間。

根本解決方案：

安裝PSU補(bǔ)丁至10.2.0.4.3

安裝10.2.0.5 PATCHSET

或者升級到更高版本。

如果你想聽到更多的實(shí)戰(zhàn)案例分享，快快來報名參加2017首屆Oracle歡樂頌技術(shù)大會吧^_^

網(wǎng)站欄目：橙色預(yù)警：索引空間泄露導(dǎo)致業(yè)務(wù)中斷
鏈接地址：http://weahome.cn/article/ijhoee.html