写这个帖子，就是告诫朋友们不要轻易analyze表和索引

66cities · 发表于 2008-1-11 12:42

写这个帖子，就是告诫朋友们不要轻易analyze表和索引。

上周去客户那里，做日常寻检，好心为他们的数据analyze一下。结果，本来好好的语句变得很慢，一般半个小时跑完的批量处理，结果跑了4、5个小时。

因为没有做别的系统上的改动，那么肯定是因为analyze后导致。本来基于RBO的优化，因为有了统计结果，oracle开始了CBO，语句执行变成了FULL SCAN。

客户很生气！我呢，别提了，郁闷极度了呀。

不得已删除了统计数据，有些表的批处理倒是好了，但又出现了其他表的新的超长时间SQL，不知怎么办了。这些表都是800万~1000万的表。

原先的统计数据是imp时oracle自动做的，以后客户没有做过，我analyze前也没有备份统计数据。

所以：

经验有以下，不要轻易analyze，如果analyze前做好原始的统计数据备份，事先和开发人员做好沟通主要是问清什么表参与批处理，大致有什么语句。

现在这个问题还没有解决，我的名声在客户那里算是一栽到底了！

郁闷。

我太冒失了，兄弟们别学我呀！

d.c.b.a · 发表于 2008-1-11 12:45

早知道了.

也帮别人处理过这种后事, 整个用户analyze的.

66cities · 发表于 2008-1-11 12:46

你是怎么解决的？能说一下吗？

谢了

xiaodong_1567 · 发表于 2008-1-11 12:49

来学习

alantany · 发表于 2008-1-11 12:50

我一个兄弟也做过这样stupid的事情，8i的时候，正常是不分析的，走RBO，结果那小子有一天发神经了，对一个刚建好的分区作分析，由于每天的入库量很大，数据变化非常大，导致用户查询异常的慢。
被我扣了半个月的工资

d.c.b.a · 发表于 2008-1-11 12:53

解决的方法是

1, 能回到从前吗? 如恢复statistics信息
2, 找出现在跑得不好的SQL, 调调吧.

jsy_0711 · 发表于 2008-1-11 12:53

同情，是不是表关联太多造成的，也感谢lz提供经验分享

Toms_zhang · 发表于 2008-1-11 12:55

通过这个教训，我希望你能在如下几个方面进一步学习，不要白白浪费一个"教训",所谓吃一堑长一智嘛。

1）如何改变统计信息以及相关的注意事项
2）哪些操作会导致执行计划异常或引起hard parse
3）哪些参数影响执行计划，该怎么调整
4）如何跟踪执行计划的计算过程
5）如何保持执行计划的稳定
6）对一个多用户高并发的OLTP，如何规范的书写SQL
7）如何应对执行计划异常的case

还有很多深的东西，先把这些搞明白吧.

祝你好运

jsy_0711 · 发表于 2008-1-11 12:55

加提示救一下呢？

paulyibinyi · 发表于 2008-1-11 12:55

呵呵,要对症下药

[Tips] 写这个帖子，就是告诫朋友们不要轻易analyze表和索引

回复 #2 d.c.b.a 的帖子