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

biti_rainy · 发表于 2004-9-20 20:57

最初由 piner 发布
[B]语句调多了，都麻木了

看着我们7000s/2小时的cpu时间，再看看你的cpu时间
两个字，羡慕
开始的时候，也只有1000多，咋就涨的这么快呢？ [/B]

话不能这么说么，逻辑上你们比我们多 4颗么

linux 下 cpu 的利用总是不充分，那也是没办法的事，有些sql不正常load就上去了

betterboy · 发表于 2004-9-20 21:48

biti_rainy斑竹，你QQ号多少？我才学oracle，有些问题想问你，都是一句话就能回答的问题。呵呵

biti_rainy · 发表于 2004-9-20 22:34

最初由 shining_forever 发布
[B]一、select COLUMN_NAME ,ENDPOINT_NUMBER, ENDPOINT_VALUE , ENDPOINT_ACTUAL_VALUE from dba_histograms
where table_name = 'IM_BLACKLIST' and column_name = 'BLACK_ID';
是干什么的？

二、为什么原来的endpoint_value值也差别很大：
而biti却认为“我们发现原来的histograms值分布比较均匀，而昨天分析后的值分布就有一些地方是集中的”，我看两次分析的对应条目的数据差别很小啊？这是如何分析的呢？

-------  这里的value 是根据字符串的值计算出来的hash  value，有好几个value都是一样的，这样若有字符串恰好落在这个值范围内，那么就会被认为占表百分比比较大。  具体的内容，你搜索oracle文档 dba_histograms 有比较详细的介绍

三、关于trace 文件的分析：
SINGLE TABLE ACCESS PATH
Column: BLACK_ID Col#: 2 Table: IM_BLACKLIST Alias: IM_BLACKLIST
NDV: 17069 NULLS: 0 DENS: 1.4470e-03
HEIGHT BALANCED HISTOGRAM: #BKT: 75 #VAL: 75
TABLE: IM_BLACKLIST ORIG CDN: 57267 ROUNDED CDN: 83 CMPTD CDN: 83
Access path: tsc Resc: 38 Resp: 38
这一段是全表扫描的相关信息是嘛？但这段信息中在我看来并没有全表扫描的任何信息，
怎么判断它是全表扫描的相关内容呢？是否这个tsc是FTS的意思？总之这段信息是什么内容基本不懂。
Access path: index (equal)
Index: IM_BLACKLIST_LID_IND
TABLE: IM_BLACKLIST
RSC_CPU: 0 RSC_IO: 65
这是里的两个指标RSC_CPU: 0 RSC_IO: 65 和全表扫描的两个指标tsc Resc: 38 Resp: 38完全不是同一个标准啊？如何类比的？

你可以参考两个文件末尾的
Best so far: TABLE#: 0 CST: 38 CDN: 83 BYTES: 2407
Final:
CST: 38 CDN: 83 RSC: 38 RSP: 38 BYTES: 2407
IO-RSC: 38 IO-RSP: 38 CPU-RSC: 0 CPU-RSP: 0

Join order[1]: IM_BLACKLIST [IM_BLACKLIST]
Best so far: TABLE#: 0 CST: 4 CDN: 3 BYTES: 75
Final:
CST: 4 CDN: 3 RSC: 4 RSP: 4 BYTES: 75
IO-RSC: 4 IO-RSP: 4 CPU-RSC: 0 CPU-RSP: 0

当然，原来曾读过10053的8i的一些文字，有点了解。至于9204的 10053 ，这样简单的文件，直接就可以读出端倪的。很显然最后确定的 cost 分别为 4 /  38  ，参考前文，可以知道落在这里。至于 resc  / rsc_io 这样的名称，是在表扫描和索引扫描中命名方式的差异，都是cost计算的其中一个标准值，只不过这里占了主导而已

比如 cpu-rsp 都是0  ，是因为系统没有引入cpu作为 cost计算的参考值

四、这个histograms是什么概念，为何用analyze table im_blacklist compute statistics;后它会基本消失了呢？SQL解析为何要参考它？

----histograms 读 oracle  document 再说

[/B]

这些东西，难以完全阐述清楚，必须建立在你自己有一定了解的基础上才好交流

shining_forever · 发表于 2004-9-20 23:21

已经非常感谢biti了，还得多学习。

dazhoufei · 发表于 2004-9-21 11:15

很好的实际解决问题方法。值得学习！收藏

yangtingkun · 发表于 2004-9-21 11:37

最初由 biti_rainy 发布
[B]

每天 8/9/10/15/16/17/23  7个整点执行的报告

job  interval

trunc(sysdate) +  decode(to_char(sysdate,'hh24'),8,9,9,10,10,15,15,16,16,17,17,23,32)/24

因为8---10点和 15---17 点是高峰期

这是长期统计观察的依据，不是碰巧 [/B]

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