OS与Oracle

这个题目有点吓人，不过既然这么说，当然有其强有力的后台做支撑。如果说一句谎言必须用更多的谎言来圆的话，一句真话恐怕也要用更多的真话来阐述，呵呵，且让我慢慢道来。

Oracle上的技术，其实是相当开放的，这里提到的这种文本导出方法，其实在网上已经有人做了很好的论述和实现。只不过本着独乐乐不如众乐乐的想法，在这里再推广一把罢了。

首先明确一点，文本导入到数据库中，或者把数据从数据库中导出为文本格式，这都是极其消耗CPU的操作。所以，导出速度首先取决于系统CPU的运算能力。基于大数据量处理的系统一般都是多节点的RAC系统，于是，文本导出的一个主要议题就是：如何利用起所有RAC节点的所有CPU的运算能力……

周末翻阅了以前写在msn space上的文章，不经意间找到了一篇2006年写的关于Linux内核的文章，那时想不到自己会变成一个Database Performance Engineer，不过里面的一些观点却和现在的工作不谋而合，只不过那时面对的Linux Kernel，现在面对的却是Oracle Database……

上一篇文章提到的那些个工具，主要侧重点在于实时监控，而在我看来，实时监控只是一个监控工具的一个职责而已。就如Linux上的collectl或者nmon一样，我们还需要对这些历史性能数据进行保存，以便于过后进行分析。而且，这也是一个不可或缺的功能，毕竟，DBA不会也不可能24小时盯着屏幕，DBA做的主要事情应该是对历史数据进行分析从而更好的认识数据库的工作状态。

监控工具方面，也有很多实现这方面需求的软件。记得anySQL.net上面就有一个类似的监控工具。通过收集v$sysstat和v$session的数据，再利用图表的方式进行分析。这应该是这类软件的共性。

但有一个”工具”值得大提特提，那就是Oracle自身的AWR。AWR默认一个小时对系统做一次快照，这些快照其实是难得的历史性能数据，Oracle自带的AWR报告，主要是基于两个快照间的分析，因此只能得到一些孤立的数值。如果我们能够更进一步，实现对所有快照数据的分析，我们就能清晰地了解系统过去一段时间（默认AWR保留7天）的工作负载的特征曲线，各种重要指标的变化曲线。我想，这些曲线对于DBA或者决策层而言都是极其有用的……

除了上一篇文章提到的collectl, IBM出品的nmon其实也是一个不错的Linux上的性能监控工具，在写这篇文章时顺带google了nmon一把，惊喜地发现nmon也open source了。还是以sourceforge为根据地，网址是http://nmon.sourceforge.net.

nmon在监控数据与易用性方面几乎与collectl不相上下，对监控单台机器的系统性能还是不错的选择的。

不过，nmon却做出了另一个突出贡献。这就是推出了一个nmon analyser，而且以开放源代码的形式提供，它的目的是实现对nmon产生的历史性能数据的分析，产生一系列的图表。nmon analyser其实就是一个Excel文件，里面嵌套了VBA脚本用来分析nmon产生的文本文件并产生一系列的图形报表。深入地分析这些脚本，你会发现，这个analyser其实是一个极好的框架，很容易利用这个analyser来分析自己的数据，而不局限于nmon产生的文件……

对系统资源的监控，是系统管理者一个必备的任务。从OS角度讲，包括CPU/IO/Network/FS等等，从Database的角度讲，包括Active Sessions/ON CPU/Disks/Top Segments/Top SQL等等。而Database对资源的利用也反映在OS一级上，对OS计算资源的充分均衡利用是我们的目标。那么，如何有效的掌握OS的资源利用情况就成为了一个System Administrator，Database Administrator日常工作的一个重点。
Linux上的常规监控工具主要有top, vmstat, iostat, netstat, sar这些。对这些工具的熟练运用应该能解决大部分问题，不过，这些工具也太散了，学习周期是一个很大的问题。有没有一个包揽所有这些工具的一个超级命令呢？
这就是本文要推荐的一个工具了，collectl，一个开源的sourceforge上的项目，http://collectl.sourceforge.net……