f Oracle Index 的重整時機 ~ 迪貝之家

Pages

Oracle Index 的重整時機

依據文件1373415.1 How to Determine When an Index Should be Rebuilt?

照Oracle的說法,要有效能問題,才去進行索引重整的動作!!
哈哈~~~
如果效能問題跑出來的時候,就等著被海K吧!!
那時上頭要檢討的就是,為什麼出現效能問題?
緊接著就是上演AP與DB 兩個單位之爭了~~
從DB Team的觀點來看,AP沒有做好設計,所以交易胃納乘載量就是如此
那AP單位反過來就會challenge 資料庫維護單位,你們沒依照專業給我們建議阿
唉~~ 團隊合作這時候就變成一個宇宙無敵超級大笑話了


我提供一個我在RAC上維護的的Case 吧~~

依據我的每日日檢,撿出來我要給AP Leader 看的數據


給出去的圖,當然是特意整理過的,不然ADDM哪有可能產出兩個時間點的數據

然後再給出(DEL_LF_ROWS/LF_ROWS*100)

index_stats

從ADDM報表裡所看出來的 總執行次數 * 單次執行時間 = "總運作時間"雖然不長
但不管嘛!!反正我就是已經提出該重整索引的建議
將來如果真的出問題,至少我做了該做的事情了
確定進行重整作業時程之後,前一天我就給了位置及SIZE的資訊
主要是要告訴AP單位,空間夠你用
省得做的過程中出現空間不夠的錯誤

重整後的當天我就再給了一次數據
底下是我前一天日檢時所收的ADDM數據


再來就是隔日上班時,進行日檢所收的06:00~中午的ADDM數據

給出這些數據是告訴AP 單位,我不是要你做白工
是有它的效益存在的


為省下一堆解釋的麻煩,作業前後比較的呈現,給AP 看的就是上述兩個截圖,就我自己的工作職責,我還是會再去看其他的數據
index_stats
index_stats

再看看INDEX的大小
最後我要提醒的是, Analyze index validate structure雖然有online機制,但就我這次的經驗,online 產不出index_stats的數據,如果你的索引很大,那麻煩你收數據時,考量一下是否會對online交易造成影響,到時候出問題,不要來告訴我,是我的文章害了你!!奇怪了..三年前我在11gR2的環境是怎麼做的??寫文章還是有它的好處了,至少未來我還可以回來翻一下我現在的做法
alter index validate structure