在維護生產環境時，尤其是負載極高的核心生產環境，我們需要注意的是，你的每一個操作，都可能導致系統負載波動，甚至產生嚴重的性能問題。
原理性文章參考之一：深入內核：Oracle數據庫里SELECT操作Hang解析。
案例分享
?
業務期間DDL操作
2004年某一天下午五點左右，在schema A下一個表上增加一個字段(對于在schema A范圍來說這個字段增加當時不會有問題的)，一加上去，系統load立即狂飆......結果在schema B下有一個包，里面有飲用schema a的這個表，沒check依賴關系以為A和B之間沒有聯系，結果這個包編譯不過去被大量進程嘗試編譯，最后只有殺掉該相關應用所有進程重新連接才恢復。
這次故障導致我們一個無故障最長時間的團隊免費去海南旅游三天的機會喪失。
業務期間DDL操作
剛工作一年的時候，開發了一段腳本就是給賬戶表某個字段修改長度(alter table account_t modify...)，我當時太累了，發了的腳本也沒有說明何時操作，我就直接在生產庫上執行了。可想而知，大部分存儲過程都失效，全省業務暫停2小時，嘿嘿。。。領導之后就給了我“破壞王”的稱號。
業務期間DDL維護
沒有犯過錯的DBA不是好DBA，但經常犯錯的DBA也不是好DBA。
我大的錯誤沒有犯過，只有兩個算是小一點的錯誤。一次是在業務繁忙的時候給一個最基礎的表加一個字段，導致全公司程序停止半個小時;另一次是準備將測試機重啟，結果將生產機給重啟了。
業務期間統計信息收集
客戶業務系統上線后由于存在部分性能問題，我對一個表做了dbms_stats......造成了一個SQL(涉及多個大表)執行計劃改變(性能特差)，主機基本癱瘓了兩個小時。最后給SQL加hint才解決問題。
業務期間索引維護操作
我遇到的嚴重事故：其實也不是人為造成的。Oracle 9i的庫，由于需要move tbs來降低hwm，然后再做alter index rebuild online，腳本連續跑了一個多月都沒事情。某天突然發生問題，alert log中無報錯，應用訪問數據庫效率奇低，查了n多原因，未見異常，但是已經造成業務中斷3小時。得到客戶同意后，做完數據庫全備，中午12點重啟數據庫解決該問題。
事后發現其實在凌晨兩點的時候有一個trc文件生成，看里面一堆的天書代碼，發現一個好像是object id，object果然是被重建索引，估計是rebuild online的時候失敗，到白天業務高峰期間smon還在清理臨時段，因此業務堵塞。
防范建議
1.在高峰期禁止在數據庫中進行DDL操作
DDL操作會導致一系列的SQL重解析、依賴對象失效等數據庫連鎖反應：一旦SQL重解析集中出現，系統必然經歷負荷峰值，如果系統繁忙，可能就此掛起;DDL導致的依賴對象消失，甚至無法通過編譯，可能長時間影響業務系統正常運行。
所以，在生產環境中，應當嚴格禁止高峰期的DDL操作，避免因操作不當或考慮不周帶來的手忙腳亂或數據庫災難。
2.慎重進行統計信息收集和索引創建等操作
統計信息收集和索引調整是優化數據庫的常用手段，可是切記，業務峰值期間的統計信息收集，或者手機之后導致不可預計的執行計劃改變，可能使數據庫瞬間停滯;而貿然添加的索引，也有可能導致其他SQL執行計劃的惡化。
所以，在生產環境中，統計信息的收集或索引增減，都應當非常慎重，避免因為考慮和測試不同帶來額外的麻煩。
以上內容摘錄自蓋國強《OracleDBA手記4數據安全警示錄》。
如何加入"云和恩墨大講堂"微信群
搜索 蓋國強(Eygle)微信號：eeygle，備注：云和恩墨大講堂，即可入群。每周與千人共享免費技術分享，與講師在線討論。返回比特網首頁>>
京公網安備 11010502049343號