--最近在优化一个项目,大家给我帮看一下awr报表,给一些建议谢谢!顺便给现在的优化打分.

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

－－－eygle大师关于SQL*Net more data to client
http://www.eygle.com/archives/2008/01/sqlnet_more_data_client.html

--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有关