这个是我昨天的statspack报告,请帮我看看有什么问题?

棉花糖ONE

原帖由 lfree 于 2008-4-9 12:07 发表
也许lz做了直方图分析，
另外不知道换成
force如何。

设置成force,或许library cache的争用能缓解了,就怕出现更严重的问题

dai_zhy

原帖由 棉花糖ONE 于 2008-4-9 12:22 发表


设置成force,或许library cache的争用能缓解了,就怕出现更严重的问题

是呀,我就是担心这个问题!

棉花糖ONE

先找top version_count里的sql,看看是不是相关的表还有柱状图,如果有就把柱状图删了

dai_zhy

原帖由 棉花糖ONE 于 2008-4-9 12:26 发表
先找top version_count里的sql,看看是不是相关的表还有柱状图,如果有就把柱状图删了

为什么要删除呢?
如何删除这个柱状图呢?

[ 本帖最后由 dai_zhy 于 2008-4-9 12:49 编辑 ]

mihawk

原帖由 dai_zhy 于 2008-4-9 11:40 发表
但是我们的应用在监控的时候,很多次出现sql运行比较慢的情况!

单独看statspack中的"SQL ordered by Elapsed"部分, 并没有发现很慢的SQL.
监控的数据库和statspack的是不是同一个数据库啊?

[ 本帖最后由 mihawk 于 2008-4-9 13:22 编辑 ]

dai_zhy

是同一数据库啊

[ 本帖最后由 dai_zhy 于 2008-4-9 13:33 编辑 ]

MecoYoo

在采集有histogram的情况下，cursor_sharing=similiar这个参数的设置依然导致sql不能完全共享，会有很多子指针出现。
similiar ,force 的设置都不是一个长久之计。

lfree

原帖由 dai_zhy 于 2008-4-9 12:13 发表


在diskid上是有索引的,是并且是唯一索引!

不好意思我看错了。

lfree

等外awr计划。

rollingpig

如果 16416.25  sec不算很慢的SQL，那还有慢SQL吗？

原帖由 mihawk 于 2008-4-9 13:20 发表


单独看statspack中的"SQL ordered by Elapsed"部分, 并没有发现很慢的SQL.
监控的数据库和statspack的是不是同一个数据库啊?