也发产品数据库的analyze之后的故障。

显示全部楼层 · 2009-7-22 09:30:00

db:8.1.7.
os :linux
详细描述：
有2个表t1,t2
t1包含了大约10万条数据，有Id 字段的pk.
t2是一个分区表，按时间分区，每月3个分区，10天一个，并建立了local index，并且一直建到2005年6月份，当然数据是按照日期顺序入库的，也就说是后来的分区都是空的。
在4月7号的时候对之后的所有分区作了
alter index index_name rebuild partition part_Namecompute statistics
从4月10日开始，也就是新的分区开始入数据了，大约有200万条数据，此时的查询异常的慢，之前是10sec，现在1个小时查不出来。下面是执行的语句和没有分析和分析过的分区的执行机会，请大家帮忙分析一下：
sql ：
WHERE a.fx_sj >= TO_DATE ('2005-04-12 08:00:00', 'yyyy-mm-dd hh24:mi:ss')
AND a.fx_sj < TO_DATE ('2005-04-13 08:00:00', 'yyyy-mm-dd hh24:mi:ss')
AND a.id = b.id
GROUP BY b.col2
ORDER BY b.col2;
做了分析的空分区表入数据之后的执行计划：
SELECT STATEMENT, GOAL = CHOOSE
1255
265817
15151569
SORT GROUP BY
1255
265817
15151569
NESTED LOOPS
2
265817
15151569
TABLE ACCESS FULL
PDB_CUSER
t1
2
1636
57260
TABLE ACCESS BY LOCAL INDEX ROWID
PDB_CUSERt2
16248
357456
INDEX RANGE SCAN
PDB_CUSER
t2_INDX
16248

没有分析的分区表查询计划：

SELECT STATEMENT, GOAL = CHOOSE
1437
265899
15156243
SORT GROUP BY
1437
265899
15156243
HASH JOIN
184
265899
15156243
TABLE ACCESS FULL
PDB_CUSER
t1
2
1636
57260
TABLE ACCESS BY LOCAL INDEX ROWID
PDB_CUSER
t2
181
16253
357566
INDEX RANGE SCAN
PDB_CUSER
t2_INDX
2
16253

千问 · 2009-7-22 09:30:00

顶一下，看看。

千问 · 2009-7-22 09:30:00

每天晚上有analyze吗？你第一次analyze时的数据量太少了，可能oracle选择了full table scan了

千问 · 2009-7-22 09:30:00

最初由 d.c.b.a 发布
[B]每天晚上有analyze吗？你第一次analyze时的数据量太少了，可能oracle选择了full table scan了 [/B]
就做了这一次analyze就出事了，现在想知道这样几件事情：
1：hash jion和nested loops的确切含义。hash jion计划始终优于nested loops?
metalink上是这么回答的。
2：作了analyze之后，oracle始终都使用当时产生的计划而不管以后表中记录如何变化？除非再次作analyze?
3：如何恢复到以前的hash join的执行计划啊？

千问 · 2009-7-22 09:30:00

最初由 alantany 发布
[B]
就做了这一次analyze就出事了，现在想知道这样几件事情：
1：hash jion和nested loops的确切含义。hash jion计划始终优于nested loops?
metalink上是这么回答的。
2：作了analyze之后，oracle始终都使用当时产生的计划而不管以后表中记录如何变化？除非再次作analyze?
3：如何恢复到以前的hash join的执行计划啊？ [/B]
?? you can delete the statistics to see ,
analyze table emp delete statistics;

千问 · 2009-7-22 09:30:00

根据你数据库的设置，你分析之后可能已经编程基于cost的执行计划
现在你首先要决定你打算使用基于cost的还是rule的执行计划。
如果是cost的，你就安排的计划，不断的分析；
如果你是基于rule的，那就删掉你分析的结果。

千问 · 2009-7-22 09:30:00

hash jion 在大多数情况下都会优于nested loops，但应该不会有如此大的差距呀。你做的那个执行计划，对资源的消耗也没有差别那么大的。怎么会出现10分钟和一个小时的差距呢？有没有找一下是哪个SQL锁定了资源不释放？

千问 · 2009-7-22 09:30:00

最初由 benny2002 发布
[B]hash jion 在大多数情况下都会优于nested loops，但应该不会有如此大的差距呀。你做的那个执行计划，对资源的消耗也没有差别那么大的。怎么会出现10分钟和一个小时的差距呢？有没有找一下是哪个SQL锁定了资源不释放？ [/B]
应该是执行计划造成的，我只要一强制改变执行计划，
aler session set events '10093 name trace context forever,level 1'
就很快，用的是hash jion,否则就一直处于查询，计划用的是nested loops.
以前也没碰到过这样的事情。

千问 · 2009-7-22 09:30:00

再分析一次看看！