摘要:《Flush Shared Pool》
2009/8/4
已經好幾天公司的重要程式一直被反應載入資料緩慢，有經驗的程式設計師都知道，
"慢" 是一個很主觀的感受，且牽涉的因素有很多，舉些比較粗淺的例子，
可能與使用者的操作方式、程式的寫法、OS的環境、網路的環境及品質、資料庫的狀態有關，
如果是多層次的架構，還牽涉到中間層的環境。
這次一如往常，先假設所有外在環境因素都沒問題，因為只有程式不斷的在改版，
所以從程式著手，調整SQL的語法，直到調無可調...
程式的部份，自覺已經盡力了，在這情形下也不能隨意改變程式的作法架構，
而且這些調整過後的SQL，理應很快的有所反應，但是在程式的表現總是顯得資料庫回應的速度有所瓶頸。
假設沒有其它外在因素的干擾，將SQL 自 Client送到Database的流程想了一下，
SQL -> Database -> Shared Pool 找相同的執行紀劃 -> 如果找不到就重新 Parse -> Buffer Cache 找有沒有已載入的block -> 如果沒有就會作 Physical Disk Read
加上最近在看statspack 的報告，有一項指標引起我的注意，就是 Execute to Parse % ，這是指SQL執行的次數與Parse次數的百分比，
遂將這幾天系統尖峰時刻的報告都跑一份出來比較，果然這兩天的數值表現都不是很好，據Google大神表示這百分比最好不要低於 20%，
我相信接近 20% 也不會是太好的結果吧! 看來系統 Parse 的次數有點不正常，難不成是 Shared_Pool 太小? 但是沒辦法調，因為所有的資源都用上了，
沒有更多餘的記憶體可以配置。
再加上前一陣子有讀到一篇Shared Pool內執行計劃的存放，似乎有提到破碎的記憶體空間會影響執行計劃的存放。
我猜想這也許是造成 Parse 次數過於頻繁的主因。
所以在 8/4 8:45 執行下列指令，將shared pool 清掉。
ALTER SYSTEM FLUSH SHARED_POOL;
很慶幸的在 9:00 ~ 10:00 的STATSPACK REPORT 中得到我想要的結果。
將結果列在下方，跟大家分享這次的經驗。
8/4(二) 7:00~8:00 Execute to Parse %: 24.23
8/4(二) 8:00~9:00 Execute to Parse %: 24.04
8/4(二) 9:00~10:00 Execute to Parse %: 64.15
8/3(一) 7:00~8:00 Execute to Parse %: 22.94
8/3(一) 8:00~9:00 Execute to Parse %: 22.08
8/3(一) 9:00~10:00 Execute to Parse %: 20.72
7/28(二) 7:00~8:00 Execute to Parse %: 40.82
7/28(二) 8:00~9:00 Execute to Parse %: 36.65
7/28(二) 9:00~10:00 Execute to Parse %: 30.26
7/27(一) 7:00~8:00 Execute to Parse %: 37.55
7/27(一) 8:00~9:00 Execute to Parse %: 31.19
7/27(一) 9:00~10:00 Execute to Parse %: 31.33