AWR分析。（shared_pool，sga_size大小設定）

Execute to Parse 
指標反映了執行解析比 其公式為 1-(parse/execute) , 目標為100% 及接近於只 執行而不解析 
在oracle中解析往往是執行的先提工作，但是通過遊標共享 可以解析一次 執行多次， 執行解析可能分成多種場景： 
1.hard coding => 硬編碼程式碼 硬解析一次 ，執行一次， 則理論上其執行解析比 為 1:1 ，則理論上Execute to Parse =0 極差，且soft parse比例也為0% 
2.繫結變數但是仍軟解析=》 軟解析一次，執行一次 ， 這種情況雖然比前一種好 但是執行解析比(這裡的parse，包含了軟解析和硬解析)仍是1:1， 理論上Execute to Parse =0 極差， 但是soft parse比例可能很高 
3. 使用 靜態SQL、動態繫結、session_cached_cursor、open cursors等技術實現的 解析一次，執行多次， 執行解析比為N:1， 則 Execute to Parse= 1- (1/N) 執行次數越多 Execute to Parse越接近100% ，這種是我們在OLTP環境中喜聞樂見的！ 通俗地說 soft parse反映了軟解析率， 而軟解析在oracle中仍是較昂貴的操作， 我們希望的是解析1次執行N次，如果每次執行均需要軟解析，那麼雖然soft parse%=100% 但是parse time仍可能是消耗DB TIME的大頭。 Execute to Parse反映了 執行解析比，Execute to Parse和soft parse% 都很低 那麼說明卻是沒有繫結變數 ， 而如果 soft parse% 接近99% 而Execute to Parse 不足90% 則說明沒有執行解析比低， 需要通過 靜態SQL、動態繫結、session_cached_cursor、open cursors等技術減少軟解析。

 

————————————————————————————————————————————————————————————————

 

估測shared_pool大小。

 

SELECT 'Shared Pool' component,shared_pool_size_for_estimate estd_sp_size,
estd_lc_time_saved_factor parse_time_factor,
CASE 
WHEN current_parse_time_elapsed_s + adjustment_s < 0 
THEN 0 
ELSE 
current_parse_time_elapsed_s + adjustment_s 
END response_time 
FROM (SELECT shared_pool_size_for_estimate,shared_pool_size_factor,
estd_lc_time_saved_factor,a.estd_lc_time_saved,
e.VALUE/100 current_parse_time_elapsed_s,
c.estd_lc_time_saved - a.estd_lc_time_saved adjustment_s FROM v$shared_pool_advice a,
(SELECT * FROM v$sysstat WHERE NAME = 'parse time elapsed') e,
(SELECT estd_lc_time_saved FROM v$shared_pool_advice WHERE shared_pool_size_factor = 1) c);

因為自己搭建的環境和老師使用的環境不同，所以結果也有所差別
自己的結果如下

COMPONENT ESTD_SP_SIZE PARSE_TIME_FACTOR RESPONSE_TIME
----------- ------------ ----------------- -------------
Shared Pool 64 .9871 23.3
Shared Pool 76 .9943 18.3
Shared Pool 88 .9986 15.3
Shared Pool 100 1 14.3
Shared Pool 112 1 14.3
Shared Pool 124 1 14.3
Shared Pool 136 1 14.3
Shared Pool 148 1 14.3
Shared Pool 160 1 14.3
Shared Pool 172 1 14.3
Shared Pool 184 1 14.3
Shared Pool 196 1 14.3
Shared Pool 208 1 14.3

13 rows selected.

結果中
COMPONENT(元件)列為shared Pool
ESTD_SP_SIZE列
為假設shared Pool的大小值
RESPONSE_TIME列
為sql語句反應時間
是預測到的一個sql語句解析花費的平均時間

shared pool設的值不同，預測花費的時間可能會有改變

結果中 shared pool為64M 一個sql語句解析花費的時間為23.3
為76M 響應時間為18.3
為88M 響應時間為15.3
為100M 響應時間為14.3
總體隨著預設的ESTD_SP_SIZE值的增加
相應的響應時間在減少
這是好事

但是ESTD_SP_SIZE增加到一定程度以後
上例為
Shared Pool 100 1 14.3
Shared Pool 112 1 14.3
隨著空間的增加
RESPONSE_TIME的數值就不變了

這樣shared pool設到
RESPONSE_TIME值穩定後的第一個值就可以了
這裡是100M
在我的軟硬體環境設為100M就可以了。

我的實驗系統使用的虛擬機器沒有負載反應的不太真實
而且從實踐中可以看到
從資料庫剛啟動開始
隨著oracle資料庫執行時間的增加
預測得到的最佳sharedpool的大小值會一步步增加。
因為隨著執行時間增長資料庫負載會增大
相同sharedpool大小造成的響應時間會變長，
而且最佳大小的值也在增大。
就是這個預測值是在變化的。

實際通過這個sql語句取出相關的值以後
一般的取
PARSE_TIME_FACTOR
的值從1開始(後面的值一般都是1)對應的ESTD_SP_SIZE資料
就是我們應該設的

這是sharedpool單獨設的方法

——————————————————————————————————————————————————————

估測sga_target大小。

 

查詢sga_target建議的大小。
SELECT (
(SELECT SUM(value) FROM V$SGA) -
(SELECT CURRENT_SIZE FROM V$SGA_DYNAMIC_FREE_MEMORY)
) "SGA_TARGET"
FROM DUAL;

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