晶晶实验十九：解决“我的数据库变慢了”类问题的一般思路

我们在日常的管理中, 经常会碰到客户或开发人员反应速度变慢了. 这一类问题常使初级DBA摸不着头脑, 还不如数据库直接报出某个错误, 更直接了当. 下面简单描述一下, 解决这类问题时的一般思路.
\;C._d3t,y~0       如果有人反应速度变慢了, 最有可能影响速度的, 无外乎CPU, 内存和I/O. 在操作系统下,我们可以先使用top命令, 查看一下CPU的占用情况. 在top的输出结果中, 特别要注意第一行中的load average, CPU的负载情况. 如果这里显示的数字大于CPU数, 说明CPU的负载有点高了. 再结合第三行一起看, 如果第三行中, CPU的空闲比例为0, 就说明CPU存在争用. 正常情况下, CPU应该有一定的空闲才好. 如果这里显示空闲为0, 争用CPU的不一定都是Oracle的进程. top的下面显示的进程的列表, 只需看一下占用CPU高的进程是否是Oracle相关的进程, 即可确认此点. 如果运气好, 或许可以直接发现某个进程占用了过多的CPU. 如果将问题定位到了某个进程, 对进一步解决问题, 有很大的帮助. 但, 大多数时候, CPU的争用已经很高了, 但是在进程列表中, 发现不了某些进程占用过高的CPU. 这时要定位问题, 可能要复杂一些. 我们可以进入Oracle, 查看v$sqlarea或等待事件. 在v$sqlarea视图中, Elapsed_time和CPU_time对了解每条SQL声明的CPU占用情况最有帮助. 其中CPU_TIME是执行SQL声明所耗用的CPU时间. Elapsed_time除实际耗用的CPU时间外, 还要加上等待时间. 如果观察V$SQLAREA没有发现特别耗用CPU的SQL声明. 可以在Statspace报告中对比一下正常时期的数据, 观察一下看有没有某条语句的CPU时间, 执行次数出现异常的变化. 有时, 或许有些SQL的CPU占用不高, 但执行次数却非常的高, 这也可能会成为造成CPU争用的原凶. 解决问题时, 将问题定位的某个确定的地方, 是解决问题的第一步. 这里, 如果可以将问题定位到某条确定的SQL, 距真正的解决问题, 就向前迈了一大步. 关于SQL声明的调优, 可是个大问题, 这篇短短的文章很难表述清楚, 我们到以后的系列实验中再讨论.
)i Gs9{EI:k0       在V$sqlarea视图中,除了上面说过的Elapsed_time力CPU_time两列外, 在了解某条SQL声明的情况时,下面的这些列也很有用:
'OZxY7K0       disk_reads:物理读
?*Ti}1Y${dq0       buffer_gets:逻辑读 ITPUB个人空间1`.g
M4V/]|
      parse_calls:解析次数
1P,cB2A'a0       executions:执行次数 ITPUB个人空间'E]&a7OR5K
      invalidations:无效次数
D0x-xg6{0       Load:加载次数ITPUB个人空间:y5t6W F6C#e%L
      version_count:子游标数      
u yF"x'Jow0       sorts:排序次数ITPUB个人空间-n)y^!N}^3@ \5@
      sharable_mem persistent_mem runtime_mem : SQL声明在共享池中的内存占用情况.ITPUB个人空间3L?O9WHrj^
      除了v$sqlarea视图, 我们还可以查看等待事件, 来了解操作系统中显示CPU争用时, 数据库内部正在等待什么, 是什么让Oracle的各进程忙碌不抑. statspack报告, 也可以帮助我们b了解这方面的信息. ITPUB个人空间$K:czD3DEF2Y9D#i
      cpu空闲为0, 并不一定都意味着有了问题, 空闲为0, 这也说明CPU正在忙着做事情, 没有闲在哪里. 操作系统和数据库总是希望CPU尽可能的繁忙, 设想一下, 如果你请了个佣人, 你也会希望他不断的忙碌着, 不要闲在哪里. 如果他总是闲在哪里, 你会考虑请个佣人是不是多余的. 但是, CPU空闲为0时, 如果同时load average中CPU的负载高于正常水平, 且有增加的迹像时, 就应该加以关注了.
tB{8y2U/{C$b0       除了top外, vmstat也可以帮助了解cpu, 以及内存的情况. vmstat的第一列: r , 显示了正在执行的和等待CPU资源的任务个数. 在CPU栏中id列, 显示了CPU的空闲比例.  和top中的CPU负载一样, r 列中的数字当然还是最好小于或等于CPU数. 除了CPU, 如果vmstat中显示页的交换长期不会0, 哪么, 内存方面一定是出了问题. 我们可以从vmstat 的 memory栏中查看内存的使用情况. 看一下free的内存是否小于平常的水平. Oracle中, SGA的设置不当, 或PGA的使用不当, 最易引起内存问题. 启动一个Oracle会话, 使用show sga命令, 可以看到SGA所占的内存数, 看这个数字没有超过正常的水平. Oracle对PGA的使用, 控制比较少. 过多的连接, 过多的过大的排序, 或过大的包变量, 等等这些情况可以很容易的超过PGA_AGGREGATE_TARGET的限制值. v$process中的PGA_USED_MEM(当前使用的PGA大小), PGA_ALLOC_MEM(分配的PGA大小), PGA_MAX_MEM(最大分配的PGA大小), 这几个列可以观察进程PGA所占内存情况. 也可以在资料视图(V$sysstat, v$sesstat, v$mystat, v$statname)中的session uga memory(会话当前所占UGA), session uga memory max(会话曾经占用UGA的最大数), session pga memory(会话当前所占PGA) , session pga memory max(会话曾经占用PGA的最大数)这几项资料中, 观察到会话PGA占用内存情况.
PMb^/m'I0       除了vmstat外, 要观察内存的使用情况, 还可以使用free命令. 在Linux和UNIX中, Oracle的SGA占用的是IPC的共享内存. 使用ipcs可以显示共享内存的使用情况. 在Linux下, free命令中有个shared项, 在man手册中说明是显示共享内存的大小. 但实际上此项已经不在使用, 将一直是0. 观察共享内存, 还是要通过ipcs . 我们可以通过ipcs -p, 显示出cpid(创建此共享内存的进程ID)和lpid(最后使用此共享内存的进程ID). 在top中，也有一个共享内存列（SHARE），显示进程占用的共享内存。此处的“共享内存”，和IPC的共享内存，也就是Oracle中SGA所占的内存仍不完全一样。因此，观察Oracle的“共享内存”，还是要用ipcs类命令。ITPUB个人空间p AQ
bsH]j:} P(]
      iostat也是一条常用的排故命令, 它的名字代有io字样, 说明这条命令主要用于io方面的调节. 它显示出的也有CPU方面的信息, 不过更主要的还是I/O方面的资料. 查看一下设备的繁忙程度和读/写的速度, 如果在设备很繁忙的情况下, 设备的读/写速度低于正常水平, 这就有可能是设备的问题. 如果不是设备故障, 我们可以通过等待视图进一步监测I/O方面的故障. 有关I/O的调优, 也是一个很大的专题, 我们在以后的系列文章中再一起讨论.
H{ ]#R|0~:dZ0       sar命令有许多选项, 可以实现和上面命令类似的结果, 可以在排故或监控系统时使用. 具体可以参考man.
:DP-K m m9K0 总的来说, 对于"速度变慢"这类问题的解决, 最好是有正常时期的statspack报告, CPU的平均负载, I/O的平均速度, 页交换的数量, 内存的使用数据等等资料. 有时候感觉到"速度变慢"并不一定是真的性能在降低, 而只是人的感觉. 对比正常时期的统计数据, 看差别是否巨大, 这样可以更准确的判断性能是否真的在降低. 而且, 通过对比统计数据, 往往可以更快的定位这类问题发生的原因.
8eO!q6J:O f0 希望这篇文章可以对数据库的初学者有所帮助。同时，这篇文章写的有点苍促，有许多未尽之处，也希望大家多在此基础上补充。