運用系統分析方法解決 11g第一個bug

一分公司應用系統出問題
不少錯誤
ORA-00600: 內部錯誤程式碼, 引數: [19004], [], [], [], [], [], [], []
ORA-00600: 內部錯誤程式碼, 引數: [kcbz_find_bpid_3], [7], [], [], [], [], [], []
搜尋metalink沒有找到相關資訊,找oracle諮詢一下也暫時沒有答案.
時間很緊,遠水解不近渴.決定自己動手解決問題.
提取發生sql看到底有什麼規律,發現sql都是多表join,並較複雜.只集中在幾個表.
在測試環境測試,這些sql,並不會發生問題
測試環境與實際的環境有什麼不同?
結合11g的自動分析表的功能,最大不同在於shared pool,也就說問題很有可能發生執行計劃解析過程.

如此制訂測試方案:
  測試分為如下:
  1.(想起10g曾碰到的bug類似,雖然oracle稱在11g解決)
    對測試環境使用同樣統計資訊收集看問題是否重現.結果問題沒法重現.而且其他很多表連線,也沒有問題.
    --說明與10g ora-600 19004不一樣
  2.改變sql寫法,用兩條sql取代多表join,同時減少sql複雜.結果果然沒有問題
  3.使用hint /*+ rule */避開使用CBO執行計劃,結果沒有問題但效能差.

到這問題大致確定範圍,應是11g bug發生到執行計劃解析過程.發生可能環境:
1.sql都是多表join,並較複雜.
2.使用CBO
解決:改變sql寫法,但要改變應用程式.
進一步分析:是否可以刪除統計資訊解決問題讓優化器使用RBO.這樣就不用做任何改變.
exec dbms_stats.delete_table_stats('owner','table_name');
結果沒有問題但效能差
----這樣問題基本解決,系統繼續正常執行
隨後時間,聚焦統計資訊收集.作為老DBA,自然想起老朋友 analyze.
通過多次測試
analyze table .. estimate statistics sample 5 percent;
就能解決這個問題了.執行計劃也不錯
最後使用11g lock statistics 加以鎖定.
問題解決後的思考:
1.運用系統分析方法,去分析問題,不應囿於DBA;將使分析能力,視野大大擴充套件.
2.11g的自動分析表的功能,要小心使用
3.CBO雖然強大,但問題不少.避免寫相當複雜,而又不優化的sql.可用pl/sql or 一段程式來替代.尤其在OLTP上.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/42376/viewspace-209684/，如需轉載，請註明出處，否則將追究法律責任。