您好,登錄后才能下訂單哦!
承蒙大家的喜愛,我們會一直做下去!
也希望喜歡技術人生系列的朋友們,順手幫轉發一下,您的轉發是我們持續分享的動力。
記得端午節和兄弟們喝酒時,有朋友說,“要不,你們成立一個用戶組吧,這樣更多的朋友可以以一個公益的形式加入到分享的隊伍中,也可以從線上分享發展到線下分享,并且可以到各個城市中去做實戰分享,讓大家可以面對面的交流”;
說的有道理,于是乎,有了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歡樂頌技術大會吧^_^
識別圖中二維碼或者閱讀全文進行報名。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。