需要上传附件的可以上传到百度网盘，并在帖子里给出共享地址

http://pan.baidu.com/s/1pJA9v0B 请大神帮忙分析下。

1、Execute to Parse比较低
2、bug
建议通过静态sql等方法减少软解析，10.2.0.3.0bug也比较多，有时会出现查询v$视图及质量比较差的sql语句将触发bug，导致latch: library cache，latch: shared pool

NUM_CPUS 24
Elapsed: 12.35 (mins)
DB Time: 78.87 (mins)
这样算起来负载并不大呀。
从library cache 统计信息看sakarea 和TABLE/PROCEDURE的reload比较多，发生问题的时候是否有大的程序加载
Library Cache Activity
"Pct Misses" should be very low
Namespace Get Requests Pct Miss Pin Requests Pct Miss Reloads Invali- dations
BODY 181 0.55 458 1.09 3 0
CLUSTER 6 0.00 6 0.00 0 0
INDEX 55 0.00 228 0.44 1 0
SQL AREA 39,582 12.86 173,062 5.14 430 4
TABLE/PROCEDURE 703 6.83 18,255 1.04 52 0
TRIGGER

能否跑一下同awr 报告的ash report

1.Top 5 Timed Events 中排在第一位的是latch: library cache ，占了51.5%，wait class是Concurrency。
说明你的数据库被应用大量频繁，调度。(在Load Profile中User calls:Per Second：877.64，Per Transaction：84.54也体现出来了)。其中SQL版本太多或者软解析太多都可能导致shared pool latch和library cache latch的争用。
我的总结是您的sql语句需要改进，减少软解析使用。以及需要使用存储过程或者函数去减少频繁调用。以及更换高一级的数据库版本。
2.网络等待时间较长，会影响数据的传递。建议您检查一下网络配置以及网卡网线的使用。
3.在Shared Pool Statistics中发现Memory Usage 处于 66.39-64.96%，目前Shared Pool设置为15,344M，有点设置Shared Pool 过大，建议设置为13,824 M， 让Memory Usage 处于 75%-90%之间。
以上是我不成熟意见，希望能帮到您。

建议是 ashrpti 打印一份等待类型为 Concurrency 的报告，找到Concurrency 类等待的TOP SQL

latch: library cache 等待估计与 SQL 游标高版本有关系