數據庫 oracle

寫在案例分享前

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

也希望喜歡技術人生系列的朋友們，順手幫轉發一下，您的轉發是我們持續分享的動力。

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

說的有道理，於是乎，有了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版本後提供）,該視圖記錄了每個小時表空間的使用情況。如果表空間使用率滿，則會記錄表空間滿的時間段。

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

創建了大對象？

檢查未發現有新的對象被創建。排除該可能。是否某個對象突然變大呢？

檢查表空間大對象

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

從上述查詢結果可以看到，該表空間內大於1G的段有一個，為XXX_PK索引段。

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

索引怎麽了？

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

空間泄露？

檢查表字段的個數，發現表中的字段非常多，表的平均行長遠大於索引字段+rowid。表實際有將近100列。

因此我們有理由相信出現了空間泄漏

如何檢查空間分配

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

可以看到，索引中的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歡樂頌技術大會吧^_^

識別圖中二維碼或者閱讀全文進行報名。

橙色預警：索引空間泄露導致業務中斷