+++ 为什么一定要部署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的历史信息来进行下一步的分析。
7． Login Storm问题：客户的数据库系统突然变慢，从应用端，数据库的ASH,AWR报告中没有发现任何异常。但是通过OSW的ps的输出发现，在发生问题时, oracle 的server process比平时多了上千个。
实际上，OSW对于我们分析问题是非常有帮助的。如果当前OS上并没有部署任何的监控软件，那么强烈建议DBA来部署OSW。很多重要的生产环境都部署了OSW，在有关于DB Performance的问题时，他们往往会先提交OSW的输出。
+++ 大家对部署OSW的顾虑往往是：
1． 生产环境已经正常运行了很久了，基于稳妥的考虑，不能随便安装软件
2． OSW会不会带来副作用
OSW的工作机制是每隔一段时间调用OS提供的一些工具，比如ps, vmstat, netstat, mpstat, top;然后把这些工具的输出打印到文件里。 它不可避免的会消耗CPU, Disk IO, Disk Space, Memory；但是这些消耗的资源都是非常少的，在大部分的系统里都是可以忽略的。只有在某些极端情况下，部署OSW才会带来负面影响：系统已经是非常的忙，CPU使用率在90%以上；磁盘的free space已经没有了。所以大家的顾虑在大部分的情况下都是不必要的，部署OSW是没有什么风险的。
+++ 下面讲一下如何在UNIX/LINUX上安装/部署OSW:
1. 从文档301137.1上下载OSW
2. 随便放在某个地方（/tmp除外），然后解压缩。不需要用root权限
$ tar xvf osw.tar
3. 启动
$ nohup ./startOSWbb.sh 60 48 gzip &
这个命令的含义是，启动OSW，然后每隔60秒收集一下信息，总共保留最近的48小时的数据（历史数据会被自动清除），保留的数据是以gzip格式压缩的。
4. 如何关闭？
$ ./stopOSWbb.sh
收集的信息会存放在archive目录下。
怎么样？简单吧？至于如何解析这些数据还有OSW的一些高级用法，且听下回分解。