我们在日常的管理中, 经常会碰到客户或开发人员反应速度变慢了. 这一类问题常使初级DBA摸不着头脑, 还不如数据库直接报出某个错误, 更直接了当. 下面简单描述一下, 解决这类问题时的一般思路.
如果有人反应速度变慢了, 最有可能影响速度的, 无外乎CPU, 内存和I/O. 在操作系统下,我们可以先使用top命令, 查看一下CPU的占用情况. 在top的输出结果中, 特别要注意第一行中的load average, CPU的负载情况. 如果这里显示的数字大于CPU数, 说明CPU的负载有点高了. 再结合第三行一起看, 如果第三行中, CPU的空闲比例为0, 就说明CPU存在争用. 正常情况下, CPU应该有一定的空闲才好. 如果这里显示空闲为0, 争用CPU的不一定都是Oracle的进程. top的下面显示的进程的列表, 只需看一下占用CPU高的进程是否是Oracle相关的进程, 即可确认此点. 如果运气好, 或许可以直接发现某个进程占用了过多的CPU. 如果将问题定位到了某个进程, 对进一步解决问题, 有很大的帮助.
如果有人反应速度变慢了, 最有可能影响速度的, 无外乎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声明的调优, 可是个大问题, 这篇短短的文章很难表述清楚, 我们到以后的系列实验中再讨论.
ITPUB个人空间1i)N(m
