OS与Oracle » parallel

史上最快，最具可扩展性的文本导入方法 –大数据量加载最佳实践

Kaya — Sat, 01 May 2010 16:06:22 +0000

Kaya 发表于 os2ora.com

竟然写了史上最快，最具可扩展性的文本导出方法, 模仿上一篇的语调，再写个史上最快，最具可扩展性的文本导入方法应该也是挺有趣的一件事情，试试吧，这或许能意想不到地从另一个角度阐述大数据量文本导入的特点，与大数据量文本导出的共性，与大数据量文本导出的不同，Oracle并行技术的运用。

不过，从另一方面讲，大数据量加载应该是一个比较成熟的技术，厚道一点，还是再用一个副标题吧：大数据量加载最佳实践。OK，开始模仿作文：

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

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

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

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

如果自己实现这种并行机制呢？那也未尝不可，SQL*Loader是Oracle的一个导入文本文件工具，叫做sqlldr，这是一个单进程的工具，不过我们可以在系统中启动多个sqlldr实例，通过指定不同的实例加载不同的文本文件，从而实现并行加载。这里有几点说明一下：

通过把一个表的数据分割成多个文件，可以实现对一个表的并行加载
通过在RAC的多个节点上启动多个sqlldr，可以实现跨节点的并行加载
必须加上parallel=true参数，在每个sqlldr 的参数文件中。

这个方法显而易见的有两个缺点

必须用户自己协调多个sqlldr的运行
如果只有一个数据文件，无法利用多个sqlldr实现并行加载

如果能利用起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中以External Table的形式提供。这是把文本文件映射成Table的一种技术。利用这种技术，我们可以实现把对文本文件的读取操作，转换为对数据表的select操作。

上面提到的就是利用Oracle本身的并行机制实现并行多节点导入数据的主要思路。至于具体的实现，可以直接参考官方文档The ORACLE_LOADER Access Driver，这一章详细解释了外部表的定义与使用。具体的例子可以参考Example: Creating and Loading an External Table Using ORACLE_LOADER。

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

解决方法在于减少对磁盘的IO量，一个马上想到的方法就是对并行进程读出的数据进行压缩。11g中，外部表定义引入了一个新的特性，叫做PREPROCESSOR，它可以实现对外部文件的预先处理，再把处理后得到的数据传送给Oracle内部进行加载。利用这个特性，我们可以实现对压缩文本文件的加载。具体而言，下面是官方文档中提到的一个例子：

Example 14-1 Specifying the PREPROCESSOR Clause

SQL> CREATE TABLE xtab (recno varchar2(2000))
     2    ORGANIZATION EXTERNAL (
     3    TYPE ORACLE_LOADER
     4    DEFAULT DIRECTORY data_dir
     5    ACCESS PARAMETERS (
     6    RECORDS DELIMITED BY NEWLINE
     7    PREPROCESSOR execdir:'zcat'
     8    FIELDS (recno char(2000)))
     9    LOCATION ('foo.dat.gz'))
   10    REJECT LIMIT UNLIMITED;
TABLE created.

假设gzip的压缩率为1:10，于是我们实现了把4GB/s的读取速度下降到400MB/s，另一方面，由于解压缩需要消耗一定的CPU，我们实现了用CPU换取IO的曲线救国。

可以看出，文本导入与文本导出其实存在着很多共性。实现高性能导入/导出的原则是一样的：

充分利用起系统中的CPU与IO资源，直至其中一方成为瓶颈
利用压缩技术消除可能存在的IO瓶颈

另一方面，关于并行技术，它不仅包括大家喜闻乐见的并行Query，并行DML；并行import，并行export其实也是并行技术用于数据仓库场合的重要方面。并行import和并行export，我想会在企业中的ODS系统中发挥重要作用。

史上最快，最具可扩展性的文本导出方法

Kaya — Wed, 21 Apr 2010 08:59:59 +0000

Kaya 发表于 os2ora.com

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

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

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

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

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

SELECT *FROM big_table

设想一下，如果这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，这是一个大部分文件服务器能达到的指标了。同时，我们在导出的同时做了后面我们很可能做的事情，压缩数据以便于减少数据空间或者以利于网络传输。

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

11gR2出色的SQL Monitor Report

Kaya — Sat, 09 Jan 2010 14:20:28 +0000

Kaya 发表于 os2ora.com

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

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

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

1. 执行计划，包括SQL执行时年actual rows，我们一般根据它与estimate rows的吻合程度判断一个执行计划的正确与否。在10g的时候，一般可以通过hint gather_plan_statistics来让执行计划显示actural rows，而在11g中，不用相关的hint，SQL Monitor Report就能显示这部分信息了。

2. 还是执行计划，不过没有详细的statistics，但是提供了以图形方式进行执行计划的展示。

3. 并行进程在各个节点上的分布情况，还有每个slave进程的资源消耗情况(DB Time, wait events, physical IO, logical IO etc.)

4. SQL对应的数据库活动情况，从这里可以看到SQL的负载特征，如在这里，这条SQL是典型的CPU密集型的SQL。

5. 系统资源利用情况曲线图，包括CPU, IOPS, MBPS, PGA Usage, Temp Usage etc.

可以想像，这个工具将能大幅度提高DBA的工作效率，对于离线分析SQL的执行性能带来了极大的方便。

一个最常提到的问题当然是如何去获取这一份Report，除了通过EM的界面去访问之外，我更趋向于用命令行的方式，这时，有两种选择

1. 如果想在一个SQL执行完之后马上生成SQL Monitor Report，可以简单地调用下面的脚本

SET linesize 300
SET pages 50000
SET long 200000000
SET longchunksize 20000000
SET heading off
SET termout off
SET timing off
SET time off
SET echo off
SET verify off
 
define f=&1
spool &f..html
 
SELECT
DBMS_SQLTUNE.REPORT_SQL_MONITOR(
session_id=>sys_context('userenv','sid'),
report_level=>'ALL',
type=>'active') AS report
FROM dual;
 
spool off

2. 如果想在SQL执行过程中或执行结束后在另一个session捕捉SQL Monitor Report，首先必须得到这个SQL的sql_id，然后就可以利用下面的脚本进行调用了。

SET linesize 300
SET pages 50000
SET long 200000000
SET longchunksize 20000000
SET heading off
SET termout off
SET timing off
SET time off
SET echo off
SET verify off
 
SELECT
DBMS_SQLTUNE.REPORT_SQL_MONITOR(
sql_id=>'&sql_id.',
report_level=>'ALL',
type=>'active') AS report
FROM dual;

如何决定Hash Partitions的数目

Kaya — Wed, 22 Apr 2009 13:14:57 +0000

Kaya 发表于 os2ora.com

Hash也许是计算机科学里的一个重大发明，简单地说，Hash函数实现把一个值映射到相应的buckets里。而Hash函数也在数据仓库领域发挥着举足轻重的作用。

Teradata，一个专注于数据仓库应用的数据库。把并行发挥到极致，它的哲学就在于把任何一个操作都并行化。而并行的基础就在于对数据的Hash分布，通过Hash，实现数据的均匀分布，从而使得并行处理的各个进程能够分担大约相等的任务。

同样地，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是一个推荐的设置值。在这种问题下，CBO一般会找到最好的执行计划，如利用partition-wise join的特性。

下面的执行计划是一个示例，这是一个利用了parition-wise join的例子。这里，DOP的大小等于hash partitions的个数。

---------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |          | 99999 |   976K|   128  (10)| 00:00:02 |       |       |        |      |            |
|   1 |  PX COORDINATOR         |          |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)   | :TQ10000 | 99999 |   976K|   128  (10)| 00:00:02 |       |       |  Q1,00 | P->S | QC (RAND)  |
|   3 |    PX PARTITION HASH ALL|          | 99999 |   976K|   128  (10)| 00:00:02 |     1 |     4 |  Q1,00 | PCWC |            |
|*  4 |     HASH JOIN           |          | 99999 |   976K|   128  (10)| 00:00:02 |       |       |  Q1,00 | PCWP |            |
|   5 |      TABLE ACCESS FULL  | FACT_B   | 99999 |   488K|    12   (9)| 00:00:01 |     1 |     4 |  Q1,00 | PCWP |            |
|   6 |      TABLE ACCESS FULL  | FACT_A   |   995K|  4860K|   112   (7)| 00:00:02 |     1 |     4 |  Q1,00 | PCWP |            |
---------------------------------------------------------------------------------------------------------------------------------
Predicate Information (IDENTIFIED BY operation id):
---------------------------------------------------
   4 - access("A"."PART_COL1"="B"."PART_COL1")

如果hash partitions的个数比DOP还小，可能会出现下面的执行计划:

-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |          | 99999 |   976K|    64  (10)| 00:00:01 |       |       |        |      |            |
|   1 |  PX COORDINATOR             |          |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)       | :TQ10001 | 99999 |   976K|    64  (10)| 00:00:01 |       |       |  Q1,01 | P->S | QC (RAND)  |
|*  3 |    HASH JOIN                |          | 99999 |   976K|    64  (10)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   4 |     PX RECEIVE              |          | 99999 |   488K|     6  (17)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
|   5 |      PX SEND BROADCAST LOCAL| :TQ10000 | 99999 |   488K|     6  (17)| 00:00:01 |       |       |  Q1,00 | P->P | BCST LOCAL |
|   6 |       PX BLOCK ITERATOR     |          | 99999 |   488K|     6  (17)| 00:00:01 |     1 |     4 |  Q1,00 | PCWC |            |
|   7 |        TABLE ACCESS FULL    | FACT_B   | 99999 |   488K|     6  (17)| 00:00:01 |     1 |     4 |  Q1,00 | PCWP |            |
|   8 |     PX BLOCK ITERATOR       |          |   995K|  4860K|    56   (6)| 00:00:01 |     1 |     4 |  Q1,01 | PCWC |            |
|   9 |      TABLE ACCESS FULL      | FACT_A   |   995K|  4860K|    56   (6)| 00:00:01 |     1 |     4 |  Q1,01 | PCWP |            |
-------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (IDENTIFIED BY operation id):
---------------------------------------------------
   3 - access("A"."PART_COL1"="B"."PART_COL1")

如果hash partitions的个数比DOP还大，可能会出现下面的执行计划:

--------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          | 99999 |   976K|   256  (10)| 00:00:04 |       |       |        |      |            |
|   1 |  PX COORDINATOR              |          |       |       |            |          |       |       |        |      |            |
|   2 |   PX SEND QC (RANDOM)        | :TQ10001 | 99999 |   976K|   256  (10)| 00:00:04 |       |       |  Q1,01 | P->S | QC (RAND)  |
|*  3 |    HASH JOIN                 |          | 99999 |   976K|   256  (10)| 00:00:04 |       |       |  Q1,01 | PCWP |            |
|   4 |     PX BLOCK ITERATOR        |          | 99999 |   488K|    23   (5)| 00:00:01 |     1 |     4 |  Q1,01 | PCWC |            |
|   5 |      TABLE ACCESS FULL       | FACT_B   | 99999 |   488K|    23   (5)| 00:00:01 |     1 |     4 |  Q1,01 | PCWP |            |
|   6 |     BUFFER SORT              |          |       |       |            |          |       |       |  Q1,01 | PCWC |            |
|   7 |      PX RECEIVE              |          |   995K|  4860K|   224   (6)| 00:00:03 |       |       |  Q1,01 | PCWP |            |
|   8 |       PX SEND BROADCAST LOCAL| :TQ10000 |   995K|  4860K|   224   (6)| 00:00:03 |       |       |  Q1,00 | P->P | BCST LOCAL |
|   9 |        PX BLOCK ITERATOR     |          |   995K|  4860K|   224   (6)| 00:00:03 |     1 |     4 |  Q1,00 | PCWC |            |
|  10 |         TABLE ACCESS FULL    | FACT_A   |   995K|  4860K|   224   (6)| 00:00:03 |     1 |     4 |  Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (IDENTIFIED BY operation id):
---------------------------------------------------
   3 - access("A"."PART_COL1"="B"."PART_COL1")

如果hash partitions的个数与默认的DOP一致，那当然可以节省很多时间，如果不是呢，而且要修改Hash Partitions的个数其实不是一件很容易的事情，那就只能通过调整DOP来得到一个好的执行计划了。两种方法：

在表一级，通过 alter table parallel
在SQL一级，通过/*+ parallel (table_name, */