数据库的performance是一个长期的监控过程，不能头疼医头，脚疼医脚。
数据库慢一般有三种情况
1。逐渐变慢
2。突然变慢
3。不定时变慢
第一种情况“逐渐变慢”，要建立一个长期的监控机制。比如，写个shell脚本每天的忙时（通常9~10 etc.)定时收集os,network,db的信息，每个星期出report对收集到的信息进行分析。这些数据的积累，可以决定后期的优化决策，并且可以是DBA说服manager采用自己决策的重要数据。DBA的价值，就在每个星期的report中体现。
第二种情况“突然变慢”，也是最容易解决的。先从业务的角度看是DB的使用跟以前有何不同，然后做进一步判断。硬件/网络故障通常也会引起DB性能的突然下降。
第一步: 察看DB/OS/NETWORK的系统log,排除硬件/网络问题
第二步：察看数据库的等待事件，根据等待事件来判断可能出问题的环节。如果,没有等待事件,可以排除数据库的问题.如果有等待时间,根据不同的等待事件,来找引起这些事件的根源.
比如latch free等跟SQL parse有关系的等待事件，OS的表现是CPU的占用率高
db file scattered read等跟SQL disk read有关系的等待时间，OS的表现是iostat可以看到磁盘读写量增加
第三步:察看os的信息, CPU/IO/MEMORY等.
a. Cpu的占用率
CPU占用率与数据库性能不成反比. CPU占用率高,不能说明数据库性能慢. 通常情况,一个优化很好,而且业务量确实很大的数据库, CPU的占用率都会高,而且会平均分布在每个进程上.反过来, CPU的占用率都会高也不代表数据库性能就好,要结合数据库的等待事件来判断CPU占用率高是否合理.
如果某个进程的cpu占用高,肯定是这个进程有问题.如果,不是oracle的进程,可以让application察看是否程序有死循环等漏洞.如果,是oracle的进程,可以根据pid查找oracle数据字典看看这个进程的发起程序,正在执行的sql语句,以及等待事件.然后,不同情况使用不同的方法来解决.
b. IO
排除硬件的IO问题,数据库突然变慢,一般来说,都是一个或几个SQL语句引起的.
如果IO很频繁,可以通过优化disk reads高的TOP SQL来解决.当然这也是解决IO问题的最笨也是最有效的办法.
OS以及存储的配置也是影响IO的一个重要的原因.
比如,最常见的HP-unix下异步IO的问题,如果DBA GROUP没有MLOCK的权限, ORACLE是不使用AIO的.偏偏OS与DB的两方的admin如果配合不够好地话,这个配置就很容易给漏掉了.
c. Memory
第二种情况与memory的关系比较小,只要SGA区配置合理没有变化,一般来说,只要不是Application Memory leak,不会引起突然变慢的现象.
第三种情况“不定时变慢”,是最难解决的.现场出现的问题原因也是五花八门千奇百怪,最重要的是,出现慢的现象时,以最快的速度抓取到最多的信息以供分析.先写好抓取数据的shell脚本,并在现象发生时及时按下回车键:)
