高手帮忙看看我这个statspack报告

显示全部楼层 · 2005-10-30 17:05:33

这几天晚上用户报访问慢,偶做了statspack放上来,大家提提建议,谢谢

千问 · 2005-10-30 17:05:33

环境:
OS:LINUX ADS4
DB:ORACLE9204
MEMORY:2G
CPU:2

千问 · 2005-10-30 17:05:33

Hard parses:
0.00
0.00
% Non-Parse CPU: 96.03
% SQL with executions>1: 84.72 84.72
从这些指标可以看出你的数据的bind var 用的非常的好，所以在top5事件中也没有关于latch free 的等待事件

千问 · 2005-10-30 17:05:33

从buffer gets 次数最多的SQL语句的执行次数来看，你的系统应该是比较繁忙的OTLP 系统吧，因为SQL 语句被大量的多次执行。建议你着手调整buffer gets 靠前的执行频率很高的那几个SQL语句，查看他们的执行计划，看看index 是否正确使用

千问 · 2005-10-30 17:05:33

没有大问题，主要可能就是commit太频繁。

千问 · 2005-10-30 17:05:33

最初由 rchsh 发布
[B]Hard parses:
0.00
0.00
% Non-Parse CPU: 96.03
% SQL with executions>1: 84.72 84.72
从这些指标可以看出你的数据的bind var 用的非常的好，所以在top5事件中也没有关于latch free 的等待事件

[/B]
可是从Execute to Parse %:0.34Parse CPU to Parse Elapsd %: 86.30 % Non-Parse CPU: 96.03看跟你说的好象不太一样吧。
Execute to Parse %执行分析比率: 100 * (1 - Parses/Executions) = 0.34，低,通常说明数据库性能存在问题
Parse CPU to Parse Elapsd % ：100*（parse time cpu / parse time elapsed）=86.30
那从这两个项上看应该是Parse相对很多。也就是说可能bind方面不够吧。

千问 · 2005-10-30 17:05:33

最初由 lfree 发布
[B]没有大问题，主要可能就是commit太频繁。 [/B]
是因为：
log file sync的等待时间较多，而log file parallel write等待事件的平均等待时间明显很小，说明就是一些其他写日志的机制在commit和rollback操作时引起的等待，而不是I/O引起的等待。
是吗？

千问 · 2005-10-30 17:05:33

自己的一些看法如下:
Response Time:265/33.68%=786.8 S
CPU TIME=265 S
WAIT TIME=786.8-265=503 S
目前系统最大的问题应该是:
1、log file sync 跟db file sequential read 的等待:
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~
% Total
Event
WaitsTime (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time
26533.68
log file sync
19,528 26033.01
db file sequential read
156,382 19925.26
Statistic
Total per Secondper Trans
--------------------------------- ------------------ -------------- ------------
user commits
18,895 10.5
1.0
基本上是每秒中有10次提交。
2、Execute to Parse %:0.34 软解析过多(基本上是解析一次执行一次软解析)

第一个问题的话，跟开发的商量是否有修改业务流程的需要（关键是业务中提交太过频繁导致），关于db file sequential read 的等待的慢慢对索引进行优化。
第二个问题打算增加session_cached_cursors参数来解决。

还有个问题，现在还有疑问：
我的CPU是2，STATSPACK的间隔是30分钟，为什么Response Time:265/33.68%=786.8 S呢？应该是2*30*60=3600 CPU时间才对？？？

千问 · 2005-10-30 17:05:33

最初由 rchsh 发布
[B]Hard parses:
0.00
0.00
% Non-Parse CPU: 96.03
% SQL with executions>1: 84.72 84.72
从这些指标可以看出你的数据的bind var 用的非常的好，所以在top5事件中也没有关于latch free 的等待事件

[/B]
对，公司对bind var这个经验还是理解比较深刻的。。。

千问 · 2005-10-30 17:05:33

最初由 cjf107 发布
[B]
是因为：
log file sync的等待时间较多，而log file parallel write等待事件的平均等待时间明显很小，说明就是一些其他写日志的机制在commit和rollback操作时引起的等待，而不是I/O引起的等待。
是吗？ [/B]
log file sync等待在偶的系统中是commit太频繁了，每秒钟达到10次之多，也许这跟业务有关系（因为必须是oltp系统，所以DML一次基本都是COMMIT一次）