提供的一个小但是非常有用的工具,它通过调
用
OS
自己提供的命令来记录
OS
运行时的一些性能参数,比如
CPU/Memory/Swap/Network IO/Disk IO
相关的信息。
+++
为什么一定要部署
OSW?
OSW
并不是强制要部署的,并且有很多工具可以提供一样的功能,比如说
mrtg, cacti, sar,
nmon, enterprise manger grid control.
但是部署
OSW
有很多好处:
1.
它比较容易部署,并且容易删除。
2.
资源消耗比较小,不管是从
CPU
,内存还是磁盘空间来说。
3.
平时不需要维护,并且在发生问题时可以帮我们迅速定位问题是否发生在
OS
端
数据库是运行在
OS
之上的,如果
OS
发生了异常,那么数据库肯定也会受到影响;如果我们
仅仅从数据库的角度去分析这样的问题时,很难有个好结果
.
在平时的工作中,有一类问题很常见:在过去的某个时间段,数据库发生了一些问题,我们往
往要找到问题的原因(
root cause
),之后才能做某些改动来避免它再次发生。对于这样的问
题,
OSW
是非常有用的,举几个小例子:
1
. 发生的问题并不是由于
OS
的异常引起的。这时候如果我们有在发生问题的时候收集的
OSW
数据,我们就可以立刻排除
OS
方面,把注意力投向
DB/
应用层。
2
. 对于
ORACLE Database Performance
的问题,我们往往第一个方向就是排除
OS
的问
题。
比如
OS
在某个时间段发生了很频繁的
Swapping
,那么内存相关的操作就会受到影响,数据
库性能也会下降,表现在
AWR
中就会发现数据库有
latch/mutex
相关的等待。
3
. 应用在某个时间段响应非常慢。
AWR
显示数据库非常的空闲,
top5
等待事件也都是很正
常;从
CPU
,内存,
Swap, Disk IO
方面看也都很正常。后来发现
OSW
中关于网络的数据显
示,发生问题时有非常多的丢包现象。如果当时没有收集到
OSW
的数据,那么基本上是不可
能找到原因了。
4
. 又比如某些
ORA-04030
的错误或者
CJQ0, P00X, J00X
进程不能启动的问题,如果我们
部署了
OSW
,那么我们就能立刻知道这些错误是不是由于
OS
的内存短缺引起的。
5
. 如果某个
server process
莫名
hung
住,我们可以通过
OSW
的信息来看当时这个进程是
不是出于
suspend
的状态,是不是占用了太多的
CPU/Memory
。
6
. 某些
Listener hung
的问题,我们也需要
OSW
的历史信息来进行下一步的分析。
评论