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

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

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

Oracle的Data Pump其实就达到了这个目标，在RAC系统中运行Data Pump，通过设置parallel参数，导出作业会在所有RAC节点运行，从而利用起系统可能存在的空闲的CPU资源。不过，Data Pump没有提供导出为文本格式的方法。

如果自己实现这种并行机制呢？那也未尝不可，目前anysql.net上有个类似的工具，叫做sqluldr2，应该就是朝着这个方向在发展。目前作者实现了对海量大表进行自动切片的算法，我想可能下一步的动作应该是在所有的RAC节点上启动多个sqluldr2实例进行导出，衷心希望这个工具能达到更好的性能。

如果能利用起Oracle本身的并行机制，那应该是一件高效并且简单的实现。只要想想Oracle投入了多少人力开发设计并行这个技术，想想并行技术在Oracle版本中的悠久历史，我们会毫不怀疑地相信并行技术的高效性，可扩展性与稳定性。

并行技术的首要设计目标就是把所有可能空闲的系统资源利用起来。例如对于下面一个简单的查询

SELECT *FROM big_table

如果现在的系统有8个节点，每个节点有8个CPU，那么这时Oracle会启动8*8*parallel_threads_per_cpu =128个并行进程。每个进程负责扫描表big_table的1/128了。与串行执行相比，扫描时间理论上会缩小为1/128，“理论上”背后主要的潜台词就是系统没有IO瓶颈了。

设想一下，如果这128个进程在扫描表的同时，把这些数据同时写到文本文件中，这不就是我们所想要的并行文本导出功能吗？关键是找到一个途径，告诉这些并行进程在扫描的同时执行写出数据到文本中这个操作。

这个途径，Oracle中以pipelined table function的形式提供。这是一个PL/SQL函数，我们只要在这个函数里面把每个并行进程接收到的数据通过UTL_FILE.PUT函数写到文本中就达到了我们的目标了。

上面提到的是利用Oracle本身的并行机制实现并行多节点导出数据的主要思路。至于具体的实现，可以直接参考www.oracle-developer.net上的文章：improving performance with pipelined table functions，这篇文章详细解释了pipelined table functions在数据导入和转换（ETL），数据导出方面的杰出贡献，具体地说，数据导出部分的子标题是asynchronous data unloading with parallel pipelined functions。同时，文章提到的脚本应该是能直接下载和运行的。

我们再深入一步，到目前为止，我们应该能够穷尽整个RAC系统所有节点的CPU处理能力，仅仅是“应该”而已。想像一种情况，如果导出文件系统的IO性能很差，不能足够快地消化上面提到的128个并行进程的写入操作，那么瓶颈就会出现在磁盘IO上了。按照我们的经验，128个进程提供接近1GB每秒的写出量还是有可能了。要找到一个文件服务器提供这么高的带宽对于很多数据中心而言还是不现实的。

解决方法在于减少对磁盘的IO量，一个马上想到的方法就是对并行进程写出的数据进行压缩。然后再把压缩后的数据写往磁盘。在Unix系统中，这可能通过文件管道的形式实现：并行进程把数据写入管道文件中，gzip进程通过读取管道文件，对数据进行压缩，然后再把它写入到目标磁盘中。

假设gzip的压缩率为1:10，于是我们实现了把1GB/s的写入下降到100MB/s，这是一个大部分文件服务器能达到的指标了。同时，我们在导出的同时做了后面我们很可能做的事情，压缩数据以便于减少数据空间或者以利于网络传输。

不知道上面的论述能否对得起这篇文章的标题

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

quote begin“

最早接触Linux内核是在大三的时候，那时《操作系统》的课程设计就是进行Linux内核源代码的分析与进程调度的改进。题目是大的有点吓人，特别是对那时一个涉足未深的年轻人看来。不过那时做的事情很简单，认认真真的看了《Linux内核源代码情景分析》的前言部分（主要讲的AT&T汇编语言，内核中一些特殊的编程规则），与进程调度相关的部分，包括进程的管理，进程的切换，进程与中断，软中断，系统调用，进程互斥与同步机制。并画了几张图阐述了进程调度的路线，对spinlock机制进行了深入的剖析。明白了2.4的内核为何是非抢占式内核，进程调度器其实也不是什么神奇的东 东—— 一个函数罢了，啥叫process context。同时，为了完成“进程调度机制的改进”，看了实现可抢占的两个补丁，哦，现在已经整合进2.6了，也怪不得昨天看2.6进程调度的介绍有种似曾相识的感觉。

可以说，那时的分析完全是理论学习。对于内核编程的实践几乎没有。带来的好处最主要的在于提高了对操作系统运行的认识与提高了代码的阅读能力。

回头去看这段往事，总觉得存在着有所改进的地方。

现在看来，内核是啥呢？只是一个比较大的软件项目，可以拿它与Eclipse相比，或者mplayer相比，或者就是与任何一个开源软件处于同层次的东西，只是它更具复杂性，涉及到的软件与硬件的东西更全面罢了。

或者说，经过这几年对开源项目的接触，对软件项目的参与，Linux内核在我心目中的神秘感已然消失，Eclipse在软件架框方面应该可以算出类拔萃，EFI在BIOS这一层上也实现了新的可扩展的和良好的设备管理模型，而Linux在操作系统的层次上也应该是一个典范，值得去学习，去揣摩，去玩味。

2.6内核之于2.4内核，无疑是前进了一大步，进程调度，设备管理等等方面都形成了更良好的framework。同时也涌现出了好多优秀的传道士及其杰作，如《Linux Kernel Development Second Edition》《Linux Device Driver Third Edition》。我更想把这些带有浓厚实践性质的书籍当做进入Linux 内核世界的一个极佳的“切入点”。想起Eclipse世界一本与此类似的书《contributing to eclipse》，一个提倡的规则就是“MONKEY SEE/MONKEY DO RULE Always start by copying the structure of a similar plug-in.”。从内核中学习内核，增强内核，应该是内核编程的一个原则。

不可否认地，“情景分析”是《Linux内核源代码情景分析》的一个亮点，为过去乏味的Linux内核源代码阅读注入了一丝亮色。可是，不管怎样，这还是一个静态的过程，我更期望能从一个动态的系统中获取关于她的内幕与运作规律。

所以，如果能够设想出一些观测内核运行的切入点，并藉此实现对内核机制的动态掌握，真真切切感知内核的运行，有时更能得出一些独具特色的结论进而做出更进一步的改进。

例如对内核调度机制的分析，有以下几个简单的问题：一秒钟内内核大概会做多少次进程切换。系统一般会存在着哪些进程，哪些系统因素会显著地加剧进程切换的次数。这些进程的运行与时间存在着怎样的分布关系（即进程与时间的函数关系）。通过在内核代码中加入相应的进行统计的代码，就可以画出这种函数图出来。再通过对它的分析，就更能从中发现出一些共性东西，数学性的东西，改进的空间。

内核中的调试机制，是与内核打交道首当其冲的问题，也是进行窥探内核的途径。做为一个工具，是实现此种学习的一个必经之路。如printk，如proc文件系统等。

而实践的过程，就是一个发现问题的过程，bottom halves有几种机制，softirq, workqueue, tasklet,他们之间有哪些区别，timer的实现有哪些，在进行实践的过程中，必定会碰到这些问题，并会主动地去寻找这类问题的答案，最后的结果就是自己编写的代码能够良好的运行于内核之中。

这里有另一问题，在内核中是否可以调用一般的系统调用？如open,close,read等等。会存在什么问题？又当如何解决？呵呵，当一个一个的问题被你解决之后，与Linux内核之间的接触又亲密了一层。

从实践中来，到实践中去吧。

当从一个业余者的角度来看Linux内核时，我想，有趣才是最好的导师，寓学于乐吧。

“quote end

遗憾的是，自从做完了研究生的毕业论文之后，就基本上不去做Linux Kernel相关的东西了，但从现在一个Database Performance Engineer的观点看，那时的一些想法和现在的工作还是有一些共性的。比如从一个动态的系统中获取关于她的内幕与运作规律; 通过在内核代码中加入相应的进行统计的代码，就可以画出这种函数图出来,再通过对它的分析，就更能从中发现出一些共性东西，数学性的东西，改进的空间; 内核中的调试机制，是与内核打交道首当其冲的问题，也是进行窥探内核的途径,做为一个工具，是实现此种学习的一个必经之路。如printk，如proc文件系统等。

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

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

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

对这些曲线进行部分展示的，就是Enterprise Manager了。在Performance这个Tab里面，可以选择按Historical浏览的方式。这其实就是对AWR Repository里的数据进行查询。不过EM只提供对一天时间跨度的drill down，所提供的曲线也比较有限，归纳起来，11g里EM提供的主要曲线有：

1. Average Active Sessions – 7 Day View
2. Host: Runnable Processes  – 1 Day
3. Average Active Sessions – 1 Day
4. Logon/Transaction Rate – 1 Day
5. Physical Reads/Redo Size Rate – 1 Day
6. Latency For Synchronous Single Block Reads – 1 Day
7. I/O Megabytes per Second by I/O Function – 1 Day
8. I/O Request per Second by I/O Function – 1 Day
9. Sessions of Parallel Execution – 1 Day
10. Active Sessions of Services – 1 Day

网络上实现类似功能的软件好象不多(知道的朋友请多comment一下)，不过，碰巧也找到了一个，叫做ONDATAPERF。通过用户上传一系列的Statspack或者AWR报告，最后据说会产生一个类似这个链接的ONDATAPERF report。这个报告里面的图表看起来还是很酷的，随便抓一个ASH的例子。

当然，唯一的缺点是这是一个付费服务。

其实，要自己实现类似的功能或者更全面的图表也不是很难的一件事情。可以考虑参考nmon的Analyser，做一个专门针对AWR Repository的Analayser出来。这应该是挺有意义，挺有先驱性的一件事情。要真有这个工具，说不定可以和这个ONDATAPERF 竞争一番呢!

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

nmon在监控数据与易用性方面几乎与collectl不相上下，对监控单台机器的系统性能还是不错的选择的。不过，nmon没有如collectl一样的网络接口，如果用来它实时监控几十台机器，可能要开几十个窗口，这基本上是不可能的事情。

下面是nmon官方网站最新版本的一个截图：

不过，nmon却做出了另一个突出贡献。这就是推出了一个nmon analyser，而且以开放源代码的形式提供，它的目的是实现对nmon产生的历史性能数据的分析，产生一系列的图表。

以图表分析性能数据的作用是很明显的。密密麻麻的数字，也许只有经过一定的聚合计算，人们才能大致地了解数据的含义，说得忽悠人一点，那就是数据挖掘。不过，聚合计算有个问题，就是会把系统可能出现的瓶颈掩盖掉，举个Jonathan Lewis打过的比方，一个人头部放在寒冰里，脚放在烈火中，按平均值理论，这个人会感觉得很舒服。而利用图形的方式对数据进行描述，就不会导致数据的丢失，而且会使数据特征一目了然。

还是一个来自官方网站上nmon analyser分析结果的一个截图：

nmon analyser其实就是一个Excel文件，里面嵌套了VBA脚本用来分析nmon产生的文本文件并产生一系列的图形报表。深入地分析这些脚本，你会发现，这个analyser其实是一个极好的框架，很容易利用这个analyser来分析自己的数据，而不局限于nmon产生的文件。举个例子，可以用nmon analyser来产生由collectl产生的文件。这当然需要对nmon analyser的脚本做一定的改写，下面是一个例子：

这里可能要做更深一步的说明，无论是nmon或者collectl，都提供了一种把它们做为后台daemon进程对系统进行监控并产生监控日志的功能。这些监控日志就可以被用于对系统的历史性能的分析。collectl甚至还做了一个功能，根据用户指定的时间跨度，自动地从日志里面抽取出这段时间里的历史数据。analyser的作用就在于分析这些日志，并产生相应的分析报告和图表。

因此，从某种程度上说，nmon anlayser为我们提供了一个框架，利用这个框架，我们可以利用起Excel强大的数据分析与绘图功能，实现对文本文件数据的自动处理。这才是本文要说明的最终结论。

对系统资源的监控，是系统管理者一个必备的任务。从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。

先摆摆架构图

三种模式：

Interactive Mode: This is the default and in this mode data is read from /proc and passes through analyze.

Record Mode: Data passes from /proc the same way as Interactive Mode but instead of going through the Analyze function it written it to a file.

Playback Mode: Here collectl works virtually identical to Interactive Mode except instead of reading data from /proc it reads it from a file.

另一个摩登的，独此一家的，现成的特性是支持socket发送数据，这对于一个有几十台以上机器的cluster来说简直就是一个福音。可以通过另一个命令接收整个cluster里面所有机器实时发送过来的数据，通过一个屏幕显示出来，这对于掌握整个cluster的工作状态是极其方便的。

对于一般的机房来说，虽然机房里的所有机器不是一般意义上的cluster，但是也可以在所有机器上安装collectl,然后把性能信息实时发送到一个监控机器，实现grid control。当然，这里指的是安装了Linux操作系统的机器。

collectl支持的性能数据种类应该是最全的一个，包括IO/CPU/Network/NFS/Infiniband/Lustre/Process/Slabs等等。

最后贴一个collectl在Exadata上的一个应用，监控所有的8个数据库节点还有14个cell节点。

看起来Exadata V1的IO已经很强劲，对否？

collectl有一个工具colmux可以实现上面的类似功能，是collectl作者的另一个开源项目，叫Collectl Utilities(http://collectl-utils.sourceforge.net/)。

如果对上图监控方式感兴趣的朋友可以用邮件的方式和我进一步联系。