awr診斷分析之二

--最近在最佳化一個專案,大家給我幫看一下awr報表,給一些建議謝謝!順便給現在的最佳化打分.

http://www.itpub.net/thread-1768702-1-1.html

 

－－－eygle大師關於SQL*Net more data to client

--biti和dba notes大師關於sql*net more data to client
http://www.itpub.net/thread-181654-1-1.html

Top 5 Timed Events

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
CPU time    5,100    73.7 
SQL*Net more data to client  6,171,597  1,569  0  22.7 Network
log file sync  96,426  78  1  1.1 Commit
db file sequential read  14,441  73  5  1.1 User I/O
LGWR wait on LNS  97,249  53  1  .8 Network

由上可知SQL*Net more data to client佔比為22.7%,判斷是否網路出現問題

 

Load Profile

Per Second Per Transaction
Parses:  1,856.54  65.81
Hard parses:  2.42  0.09

Executes:  1,843.14  65.34
Transactions:  28.21 

由上可知解析與執行基本相同

Instance Efficiency Percentages (Target 100%)

Execute to Parse %:  -0.73 Latch Hit %:  99.92
Parse CPU to Parse Elapsd %:  30.45 % Non-Parse CPU:  98.83
同上佐證

可知解析比執行還多；解析過多了

 

Library Cache Activity
"Pct Misses" should be very low
Namespace Get Requests Pct Miss Pin Requests Pct Miss Reloads Invali- dations
BODY 1,085 0.00 22,654 0.01 2 0
CLUSTER 41 0.00 83 0.00 0 0
INDEX 3 0.00 26 0.00 0 0
SQL AREA 2,225,475 87.55 6,763,280 0.12 7,307 65
TABLE/PROCEDURE 6,432 1.03 110,464 0.33 170 0
TRIGGER 290 0.00 15,849 0.01 1 0

由上可知sql area pct miss達到87.55%,有些高了，說明共享池有些小可以考慮把sql keep

 

Instance Activity Statistics
也要看
比如：行連結和行遷移

 

補充一下
Execute to Parse %: -0.73 ，
而且
Parses: 1,856.54 65.81
Executes: 1,843.14 65.34
解析次數和執行次數差不多，說明沒有使用一次解析多次執行，這個需要在應用程式端的配置作些改變。

每秒21萬次邏輯讀，還是比較高的。SQL*Net more data to client出現的原因，和邏輯讀高有關聯。
假設網路一次只能傳送5K字，如果一次讀，讀了5K位元組，讀5K，傳送5K，相關網路的等待事件是sql*net message to clinet。
如果一次讀，讀了10K位元組，而網路一次只能傳送5K字，要分兩次傳送，會出現一次SQL*Net more data to client,一次sql*net message to clinet。
如果想減少SQL*Net more data to client，可以在sqlnet.ora中新增DEFAULT_SDU_SIZE=32k。
其實本質上還是邏輯讀太多了，看看SQL，能否減少邏輯讀。

 

小結：1,關注load profile的每秒產生的邏輯讀，一般在了10w比較高，可以結合

               sql 部分，最佳化下,減去邏輯讀

            2,logical read與sql*net more data client有關