一条sql导致数据库整体性能下降的诊断和解决的全过程

xzh2000

最初由 yangtingkun 发布
[B]

这样控制job时间还是第一次看到。
又学了一招
[/B]

刚才发现, 如果将interval中的那个32去掉后,这个job就会自杀的。
第二天就发现在dba_jobs中不在存在,必须加上32指定下次在第
二天的早上。

yangtingkun

没有32，就到不了下一个8，这个decode就转不起来了。

xzh2000

最初由 yangtingkun 发布
[B]没有32，就到不了下一个8，这个decode就转不起来了。 [/B]

可也不能玩失踪吧,还是以该搞破坏呢！

yangtingkun

哦，decode没有default值的话是不是null啊？如果是null的话，interval＝null，job就结束了。

yangtingkun

SQL> select nvl(decode(3, 2, 5), 0) from dual;

NVL(DECODE(3,2,5),0)
--------------------
                   0

m77m78

这一点我深有感触，我们公司在数据库对象分析之后，原有的好几个程式速度都变慢了。想一想只是对数据库对象进行了分析，为什么会这样？最后把数据库的模式改为RBO，一切都恢复正常了。。。。费解！

zhouyunming

收藏

zf_wu

最初由 biti_rainy 发布
[B]

1：在你们看来，好象我拥有以前的statspack是一个偶然现象？
不，这是必然！ 我每天搜集statspack最主要的功能就是为了  做性能变化对比的！ 当然，要是去给别人tuning 那是另外一回事

2：在 v$sql 中 抓还不如去 v$sqlarea 中抓更方便一些 ，要通过 一系列的 标准去筛选，要观察 sql 的特征，估计每次执行的consistent gets 和执行计划是否合理。然后在没有和以前的对比的情况下，你甚至未必能很快判定今天数据库慢就是因为这条sql导致的，因为有些时候这些sql看起来性能未必是极差，300左右的consistent gets 说不上极差，但是却因为执行次数比较多而对数据库造成了影响。

3：在特定条件下 如何迅速地利用现有条件 诊断并解决问题，本是没有定论的，倚赖于当前的环境。 [/B]

3：在特定条件下 如何迅速地利用现有条件 诊断并解决问题，本是没有定论的，倚赖于当前的环境。[/COLOR]
好!自己负责的数据库平时应收集性能的基准.往往能很快发现问题.
偶然的,则要视情况而定.

yanming1982

good

ggllong

似乎有点高深　看起来都吃力，，基础还差了点。学习。。。。