| 依據文件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) |
| 從ADDM報表裡所看出來的 總執行次數 * 單次執行時間 = "總運作時間"雖然不長 |
| 但不管嘛!!反正我就是已經提出該重整索引的建議 |
| 將來如果真的出問題,至少我做了該做的事情了 |
| 確定進行重整作業時程之後,前一天我就給了位置及SIZE的資訊 |
| 主要是要告訴AP單位,空間夠你用 |
| 省得做的過程中出現空間不夠的錯誤 |
| 重整後的當天我就再給了一次數據 |
| 底下是我前一天日檢時所收的ADDM數據 |
| 再來就是隔日上班時,進行日檢所收的06:00~中午的ADDM數據 |
| 給出這些數據是告訴AP 單位,我不是要你做白工 |
| 是有它的效益存在的 |
| 為省下一堆解釋的麻煩,作業前後比較的呈現,給AP 看的就是上述兩個截圖,就我自己的工作職責,我還是會再去看其他的數據 |
| 再看看INDEX的大小 |
| 最後我要提醒的是, Analyze index validate structure雖然有online機制,但就我這次的經驗,online 產不出index_stats的數據,如果你的索引很大,那麻煩你收數據時,考量一下是否會對online交易造成影響,到時候出問題,不要來告訴我,是我的文章害了你!!奇怪了..三年前我在11gR2的環境是怎麼做的??寫文章還是有它的好處了,至少未來我還可以回來翻一下我現在的做法 |
