OS与Oracle

竟然写了史上最快，最具可扩展性的文本导出方法, 模仿上一篇的语调，再写个史上最快，最具可扩展性的文本导入方法应该也是挺有趣的一件事情，试试吧，这或许能意想不到地从另一个角度阐述大数据量文本导入的特点，与大数据量文本导出的共性，与大数据量文本导出的不同，Oracle并行技术的运用。
不过，从另一方面讲，大数据量加载应该是一个比较成熟的技术，厚道一点，还是再用一个副标题吧：大数据量加载最佳实践。OK，开始模仿作文……

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

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

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

SQL Monitor Report是11g推出的一个新特性。如果说11gR1里的SQL Monitor Report已经达到可圈可点的程度，那么11gR2里的SQL Monitor Report可以说已经接近完美了。

这个SQL Monitor Report包含的信息比单纯的Execution Plan可全面多了，基本上，有了这份报告之后，troubleshooting所需要的大部分信息都已经具备了。

这个Report主要包括以下五部分……

Oracle也广泛地使用着Hash算法，Hash Partitioning就是在数据仓库应用中的一个典型例子。Hash Partitioning的一个最大的优势就是实现partition wise join.一个要考虑的问题在于hash partitions数目的选择，一个总的原则是它应该是2的乘方，如4,8,16,32,64,128…另一个要考虑的方面在于硬件的处理能力，对了，就是RAC里面的节点数，还有每个节点CPU Cores的多少。说得再具体一点，就是默认的DOP的大小(默认DOP = 2 * cpu_count * number of nodes in the cluster)。一般而言，把hash partitions的个数设置成默认的DOP是一个推荐的设置值……