数据库变慢，大家都是如何来判断然后解决问题的

nusk

网上也看到了很多文章，但是感觉都是空空而谈，比如说先看锁，到V$LOCKED_OBJECT里面去看，问题是，很多锁都是正常的，过一会会自动解锁的，如何判断哪些锁是不正常的呢？还有就是v$session_wait里面又如何判断，有人教我，说v$session_wait里面的event为enqueue的就是不正常的，这些是什么根据？请斑竹以及高手们指点一下迷津，小弟不甚感激。

dtsjs

这个问题太大了，可以写几本书了。
一般我首先会询问最近作过怎样的变化，有没有大的数据量，再看看oracle日志，看看临时段是否够，等等。

numenhuang

问题涉及的范围很广，可能的原因：
1. 初始数据库的数据量都很小，这样不良的sql语句和索引的问题体现不出来，但是随着时间的积累，数据量逐渐增大，这些问题就会导致系统越来越慢。
2. 服务器的硬件（如内存，磁盘I/O)和ORACLE的系统参数不合理。
3. 用户访问量的增大

最好使用statspack，oracle em等工具监控oracle的使用情况，比如最耗资源的TOP SQL语句，借助这些信息来对系统进行调整。

rollingpig

看看我的签名
数据库总体性能问题，通常通过作statspack report 来分析解决……

z-fh

原帖由 dtsjs 于 2006-10-1 16:43 发表
这个问题太大了，可以写几本书了。
一般我首先会询问最近作过怎样的变化，有没有大的数据量，再看看oracle日志，看看临时段是否够，等等。

呵呵，说的好，写几本书，但最好由书变成几页纸。

弱智

原帖由 dtsjs 于 2006-10-1 16:43 发表
这个问题太大了，可以写几本书了。
一般我首先会询问最近作过怎样的变化，有没有大的数据量，再看看oracle日志，看看临时段是否够，等等。

对于这个问题，有些体会。
PURGE自己处理这样的问题也是这个步骤，比如最近就是因为业务生产库升级，
其中添加了一个业务功能，从数据库来看，无法使用到相关字段索引造成主表全表扫描导致
I/O突然增大，业务办理几乎停顿的尴尬境地。
当查到这个改变以后，索性关闭之解决了问题。