Oracle QQ群討論系統效能Tuning話題總結（1）

以下是群中牛牛 愛你如初 老大的一些談話總結。 有一些概念性的東西我會在回覆中寫出來。供大家參考。

應用跟我的反映98%就是慢 , 一般會按照下面步驟進行

1、開啟TOPAS (AIX)，查詢IO CPU情況

2、檢查應用伺服器的情況

一般時候到這裡就會出現2中情況 , 資料庫伺服器CPU很高 或者IO很高

3、查詢RAC節點的日誌和OS的日誌確認不存在OS或者資料庫本身出現了問題 , 比如FSP卡出現問題或者記憶體模組出現問題等等都要先排除

4、檢查儲存日誌

如果檢查OS以後發現CPU與IO都不高，前臺還反映慢，那就開始考慮網路了

5、然後開始著手查資料庫本身與應用的問題了，一般我都會透過排名前幾的程式去查在後臺執行什麼動作 ，由於像我們這些系統執行頻度很高，所以語句的切換是非常快的 ，大部分時間都是花在這裡 。

記得有回，我們的一個節點CPU利用率很高，但是經過對大量語句的分析，每條語句的執行都不會超過0.1S , 而且這些語句都是一閃而過, 這個時候我會特別注意這些語句執行的頻度, 最後發現有個語句每秒執行接近100次 , 你想想即使這個語句每次執行0。01S，那麼一秒種也需要用掉你大量的CPU .

如何查詢每秒執行接近100次, 到v$sqlarea裡去查, 如果繫結過的 , 裡面會記錄一個執行次數 , 你可在2個時間點執行相減下就可以算出來了, 對繫結不好的情況，情況就更復雜了 .

比如前天我們這裡出現的問題, DBA跟我反映說從上午9：40開始，主伺服器的CPU一直攀身從20%一直差不多到80% , 這種情況是屬於比較緊急時刻了, 但是經過對大量語句排查後沒有發現任何異常 , 然後我檢查了下v$session_wait , 發現裡面有少量的LATCH FREE等等 , 我再看看v$sqlarea，發現前天晚上執行的一些大量的非繫結語句存在 , 這個問題就跟10G的記憶體自動管理就有點關係了 , 我一直不很推崇10G的對於SHARED POOL自動管理的能力 , 我曾經做過測試，在10G下和9I下做壓力測試，在相同情形下，都不進行變數的繫結, 9I的效率到後期差不多是10G的30倍 , 10G對於SHARED POOL自動管理是存在缺陷的, 比如他在什麼時候停止申請新記憶體等等應該是沒控制好的 , 沒控制好直接導致SHARED POOL的進出佇列管理也存在了缺陷 ,也就是當SHARED POOL記憶體用了到達一定程度的時候，那麼ORACLE本身對這片記憶體區的管理尤其是在變數繫結不好的時候 , 那代價是極其高的 . 不過這個問題我從沒看到過有人在論壇上提過 , 這個時候有個小巧的解決辦法, 我一般都那麼處理, 果也是相當不錯的 , 一般這個時候我會把SHARED POOL給清空( ) , 我們前2天的問題我把記憶體清掉以後 , CPU馬上下到20% . flush之後，應用語句繫結好 ，雖然所有請求都需要hard phase一次，但是基本沒有大的影響。

接著談談FLUSH的作用？ 舉個例子吧， 例子好理解些 ，舉個排隊的例子，如果一個隊伍裡總共就2個人，只要一個管理員就可以管得好好的 ， 但是如果一個隊伍有2萬個人 ，那需要多少管理員去管理才能管理好這個隊伍呢？實際上就是一個PIN的動作， 因為變數沒綁好， 很多PARSE的時候都要去PIN這個OBJECT， 所以會出現LATCH FREE等帶 ， LATCH可以理解為是一個記憶體保護鎖 ， 一塊記憶體區的資料一個時刻只能被某一個程式讀取佔用 ， 實際上在記憶體區不夠的時候也會出現這種等待時間了

我當時為什麼說懷疑ORACLE在SHARED POOL的管理上是否有問題呢 ,按照一般情況就好比9I的處理方式， 一般時候他的LRU佇列管理是很正常的怎麼進佇列出佇列都有嚴格的規則 .

待續...........