熊貓大俠一次效能診斷優化十一問

                     熊貓大俠一次效能診斷優化十一問

剛才看到  ORA-600 & ORA-7445 by Maclean.Liu帖子：
http://www.itpub.net/thread-1558212-1-1.html
大家蜂擁而至吶喊受精！

我學習了一下，的確本身碰到這麼多的問題，本身不容易
並且能一一記錄在案就更不容易了

但是有些我是這樣看的
碰到這麼多  
不過看了幾篇沒什麼 特別的
不過是 metlink/sr 和bug 說

不過還是有不少學習的地方

授精個人覺得有待商榷

是不是 bug 原因有可能是更深層次的？
是不是問題“想當然”的就這樣？

很多歸於bug 有時候是不嚴謹和科學的
很多想當然的得出結論是輕率的和不科學的

凡事都需要多問個為什麼的
由看熊貓大俠想開去：
比如 我昨晚看到的熊軍的一文：
修改隱含引數_library_cache_advice解決效能問題一例
http://www.laoxiong.net/resolve- ... meter.html#more-857
要是我們說不好問題就定位為shared pool latch結案，還欣欣然的離開
可人家最終會思考到shared pool simulator latch的競爭

個人表示很敬佩人家的這種精神和境界！！

看看此文中熊軍疑惑的“為什麼呢？”————————
從Load profile資料對比來看，應用調整後系統負載有一定的提高，同時每事務邏輯讀也有一定的增加（不足10%）。這會是個問題嗎？


最直觀的，最容易想到的就是，效能問題的出現是否與應用調整有關，如果是，為什麼另一套庫沒有出現問題？
會不會是另一套庫的負載在2個節點都有相對均衡的負擔，而出問題的庫，負載全部集中在1個節點上引起？
客戶是在應用調整幾天後才報告效能問題，這個問題會不會是一個逐漸出現的問題？
如果一開始就有嚴重的效能問題，那麼應該會很快報告。不過中間跨了一個週末，所以對於”逐漸出現問題“的判斷又加了一些難度。
這麼多的效能問題相關的現象中，哪個更貼近問題的原因？
實際上在主機的CPU長期保持在100%左右時，會放大平時的一些輕微的問題，或者引起另一些問題。從等待來看，latch: cache buffers chains和cursor: pin S都會引起CPU的急劇增加，而其他的latch競爭同樣也會引起CPU的上升，雖然上升沒有前者大。到底是SQL執行效率不高引起CPU急劇增加然後引起了shared pool latch等與解析相關的資源爭用還是因為解析相關的問題導致CPU急劇增加引起了cache buffers chains等與SQL執行相關的latch爭用？
或者是2者的共同作用？

雖然效能問題已經解決，但是留下來需要更深入的問題還有：
cursor: pin S這個等待，在shared pool simulator latch爭用時，是如何產生的？
share pool simulator latch的爭用是如何產生的，為什麼之前沒有，是什麼引起的？
是BUG嗎？
如果是BUG又是怎麼觸發的？
實際上後面嘗試將”_library_cache_advice”引數改回為TRUE，但是該效能問題並沒有再次出現。
……

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