深入理解Oracle的并行执行

1、深入理解Oracle 的并行执行摘要：Oracle并行执行是一种分而治之的方法。执行一个sql 时，分配多个并行进程同时执行数据扫描，连接以及聚合等操作，使用更多的资源，得到更快的sql 响应时间。并行执行是充分利用硬件资源，处理大量数据时的核心技术。 Oracle并行执行是一种分而治之的方法。执行一个sql 时，分配多个并行进程同时执行数据扫描，连接以及聚合等操作，使用更多的资源，得到更快的sql 响应时间。并行执行是充分利用硬件资源，处理大量数据时的核心技术。 在本文中，在一个简单的星型模型上，我会使用大量例子和sql monitor 报告，力求以最直观简单的方式，向读者阐述并行执行的核心

2、内容： Oracle 并行执行为什么使用生产者消费者模型。 如何阅读并行执行计划。 不同的数据分发方式分别适合什么样的场景。 使用partition wise join 和并行执行的组合提高性能。 数据倾斜会对不同的分发方式带来什么影响。 由于生产者-消费者模型的限制，执行计划中可能出现阻塞点。 布隆过滤是如何提高并行执行性能的。 现实世界中，使用并行执行时最常见的问题。术语说明：S： 时间单位秒。 K： 数量单位一千。 M： 数量单位一百万， 或者时间单位分钟。 DoP： Degree of Parallelism， 并行执行的并行度。 QC： 并行查询的 Query Coordinator

3、。 PX 进程： Parallel Execution Slaves。 AAS： Average active session， 并行执行时平均的活动会话数。 分发： pq distribution method， 并行执行的分发方式， 包括 replicate， broadcast， hash 和 adaptive分发等 4 种方式， 其中 adaptive 分发是 12c 引入的的新特性， 我将在本篇文章中一一阐述。 Hash join 的左边： 驱动表， the build side of hash join， 一般为小表。 Hash join 的右边： 被驱动表， the probe

4、side of hash join， 一般为大表。 布隆过滤： bloom filter， 一种内存数据结构， 用于判断一个元素是否属于一个集合。 测试环境和数据Oracle版本为12.1.0.2.2，两个节点的RAC，硬件为ExadataX3-8。这是一个典型的星型模型，事实表lineorder有3亿行记录，维度表part/customer分别包含1.2M和1.5M行记录，3个表都没有进行分区，lineorder大小接近30GB。 js view plaincopyprint?selectownerseg_owner，segment_nameseg_segment_name，round(by

5、tes/，2)SEG_MBfromdba_segmentswhereowner=SIDandsegment_namein(LINEORDER，PART，CUSTOMER)/OWNERSEGMENT_NAMESEGMENT_TYPESEG_MB-SIDLINEORDERTABLE30407.75SIDCUSTOMERTABLE168SIDPARTTABLE120selectowner seg_owner，segment_name seg_segment_name， round(bytes/，2) SEG_MBfrom dba_segments whereowner = SIDand segmen

6、t_name in (LINEORDER，PART，CUSTOMER)/OWNERSEGMENT_NAME SEGMENT_TYPESEG_MB- - - - SIDLINEORDERTABLE30407.75SIDCUSTOMERTABLE168SIDPARTTABLE120本篇文章所有的测试，除非特别的说明，我关闭了12c的adaptive plan特性，参数optimizer_adaptive_features被默认设置为false。Adaptive相关的特性如cardinality feedback，adaptive distribution method，adaptive join都

7、不会启用。如果检查执行计划的outline数据，你会发现7个优化器相关的隐含参数被设置为关闭状态。事实上，12c优化器因为引入adaptive plan特性，比以往版本复杂得多，剖析12c的优化器的各种新特性，我觉得非常具有挑战性，或许我会在另一篇文章里尝试一下。 js view plaincopyprint?select*fromtable(dbms_xplan.display_cursor(77457qc9a324k,0,outline);.OutlineData-/*+BEGIN_OUTLINE_DATAIGNORE_OPTIM_EMBEDDED_HINTSOPTIMIZER_FEATU

8、RES_ENABLE(12.1.0.2)DB_VERSION(12.1.0.2)OPT_PARAM(_optimizer_use_feedbackfalse)OPT_PARAM(_px_adaptive_dist_methodoff)OPT_PARAM(_optimizer_dsdir_usage_control0)OPT_PARAM(_optimizer_adaptive_plansfalse)OPT_PARAM(_optimizer_strans_adaptive_pruningfalse)OPT_PARAM(_optimizer_gather_feedbackfalse)OPT_PARA

9、M(_optimizer_nlj_hj_adaptive_joinfalse)OPT_PARAM(optimizer_dynamic_sampling11)ALL_ROWSEND_OUTLINE_DATA*/select * from table(dbms_xplan.display_cursor(77457qc9a324k,0,outline);.Outline Data-/*+BEGIN_OUTLINE_DATAIGNORE_OPTIM_EMBEDDED_HINTSOPTIMIZER_FEATURES_ENABLE(12.1.0.2)DB_VERSION(12.1.0.2)OPT_PARA

10、M(_optimizer_use_feedback false)OPT_PARAM(_px_adaptive_dist_method off)OPT_PARAM(_optimizer_dsdir_usage_control 0)OPT_PARAM(_optimizer_adaptive_plans false)OPT_PARAM(_optimizer_strans_adaptive_pruning false)OPT_PARAM(_optimizer_gather_feedback false)OPT_PARAM(_optimizer_nlj_hj_adaptive_join false)OP

11、T_PARAM(optimizer_dynamic_sampling 11)ALL_ROWSEND_OUTLINE_DATA*/并行初体验串行执行以下sql对customers和lineorder连接之后，计算所有订单的全部利润。 串行执行时不使用parallel hint： js view plaincopyprint?select/*+monitor*/sum(lo_revenue)fromlineorder,customerwherelo_custkey=c_custkey;select /*+ monitor */sum(lo_revenue)fromlineorder, custom

12、erwherelo_custkey = c_custkey;串行执行时，sql执行时间为1.5分钟，dbtime为1.5分钟。执行计划有5行，一个用户进程工作完成了对customer，lineorder两个表的扫描，hashjoin，聚合以及返回数据的所有操作。此时AAS(average active sessions)为1，sql执行时间等于db time。几乎所有的dbtime都为db cpu，72%的cpu花在了第二行的hash join操作。因为测试机器为一台Exadata X38，30GB的IO请求在一秒之内处理完成。Celloffload Efficiency等于87%意味着经过存

13、储节点扫描，过滤不需要的列，最终返回计算节点的数据大小只有30GB的13%。并行执行使用hint parallel(4)，指定DoP=4并行执行同样的sql： js view plaincopyprint?select/*+monitorparallel(4)*/sum(lo_revenue)fromlineorder,customerwherelo_custkey=c_custkey;select /*+ monitor parallel(4)*/sum(lo_revenue)fromlineorder, customerwherelo_custkey = c_custkey;SQL执行时间

14、为21s，db time为1.4分钟。DoP=4，在两个实例上执行。执行计划从5行增加为9行，从下往上分别多了PXBLOCKITERATOR， SORTAGGREGATE， PXSENDQC(RANDOM) 和 PXCOORDINATOR 这四个操作。其中3到8行的操作为并行处理，sql的执行顺序为：每个PX进程扫描维度表customer(第6行)，以数据块地址区间作为单位(第7行)扫描四分之一的事实表lineorder(第8行)，接着进行hash join(第5行)，然后对连接之后的数据做预先聚合(第4行)，最后把结果给QC(第三行)。QC接收数据(第2行)之后，做进一步的汇总(第1行)，最

15、后返回数据(第0行)。SQL执行时间比原来快了4倍，因为最消耗时间的操作，比如对lineorder的全表扫描，hashjoin和聚合，我们使用4个进程并行处理，因此最终sql执行时间为串行执行的1/4。另一方面，dbtime并没有明显下降，并行时1.4m，串行时为1.5m，从系统的角度看，两次执行消耗的系统资源是一样的。 DoP=4时，因为没有涉及数据的分发(distribution)，QC只需分配一组PX进程，四个PX进程分别为实例1和2的p000/p0001。我们可以从系统上查看这4个PX进程。每个PX进程消耗大致一样的db time，CPU和IO资源。AAS=4，这是最理想的情况，每个P

16、X进程完成同样的工作量，一直保持活跃。没有串行点，没有并行执行倾斜。AAS=4，查看活动信息时，为了更好的展示活动信息，注意点掉”CPU Cores”这个复选框。 在Linux系统上显示这四个PX进程。 js view plaincopyprint?oracleexa01db01sidney$ps-ef|egrepp0001_SSBoracle20888142014?18:50:59ora_p000_SSB1oracle20892142014?19:01:29ora_p001_SSB1oracleexa01db01sidney$sshexa01db02ps-ef|egrepp0001_SSBo

17、racle56910142014?19:01:03ora_p000_SSB2oracle56912142014?18:53:30ora_p001_SSB2oracleexa01db01 sidney$ ps -ef | egrep p0001_SSBoracle 20888 1 4 2014 ? 18:50:59 ora_p000_SSB1oracle 20892 1 4 2014 ? 19:01:29 ora_p001_SSB1oracleexa01db01 sidney$ ssh exa01db02 ps -ef | egrep p0001_SSBoracle 56910 1 4 2014

18、 ? 19:01:03 ora_p000_SSB2oracle 56912 1 4 2014 ? 18:53:30 ora_p001_SSB2小结本节的例子中，DoP=4，并行执行时分配了4个PX进程，带来4倍的性能提升。SQL monitor报告包含了并行执行的总体信息和各种细节，比如QC，DoP，并行执行所在的实例，每个PX进程消耗的资源，以及执行SQL时AAS。生产者-消费者模型在上面并行执行的例子中，每个px进程都会扫描一遍维度表customer，然后扫描事实表lineorder进行hash join。这时没有数据需要进行分发，只需要分配一组px进程。这种replicate维度表的行为

19、，是12c的新特性，由参数_px_replication_enabled控制。更常见情况是并行执行时，QC需要分配两组PX进程，互为生产者和消费者协同工作，完成并行执行计划。架构图1如下： Broadcast分发，一次数据分发为了举例说明两组px进程如何协作的，设置_px_replication_enabled为false。QC会分配两组PX进程，一组为生产者，一组为消费者。见下图，此时sql执行时间为23s，执行时间变慢了2s，dbtime仍为1.5分钟。 最大的变化来自执行计划，现在执行计划有12行。增加了对customer的并行扫描 PXBLOCKITERATOR (第8行)，分发PXS

20、ENDBROADCAST和接收PXRECEIVE。执行计划中出现了两组PX进程，除了之前蓝色的多人标志，现在出现了红色的多人标志。此时，SQL的执行顺序为： 4个红色的PX进程扮演生产者角色，扫描维度表customer，把数据通过broadcast的方式分发给每一个扮演消费者的蓝色PX进程。因为DoP=4，每一条被扫描出来的记录被复制了4份，从sqlmonitor的第9行，customer全表扫描返回1。5m行数据，第8行的分发和第7行的接受之时，变成了6m行记录，每个作为消费者的蓝色px进程都持有了一份完整包含所有custome记录的数据，并准备好第5行hashjoin的buildtable

21、。 4个作为消费者的蓝色PX进程，以数据块地址区间为单位扫描事实表lineorder(第10/11行);同时和已经持有的customer表的数据进hashjoin(第5行)，然后对满足join条件的数据做预聚合(第4行)，因为我们查询的目标是对所有lo_revenue求和，聚合之后每个PX进程只需输出一个总数。 4个蓝色的PX进程反过来作为生产者，把聚合的数据发给消费者QC(第3行和第2行)。由QC对接收到4行记录做最后的聚合，然后返回给用户。 使用broadcast的分发方式，只需要把customer的数据广播给每个消费者。Lineorder的数不需要重新分发。因为lineorder的数据量

22、比customer大的多，应该避免对lineorder的数据进行分发，这种执行计划非常适合星型模型的数据。 观察sql monitor报告中Parallel标签下的信息，红色的PX进程为实例1、2上的p002/p003进程，蓝色的PX进程为p000/p001进程，因为蓝色的PX进程负责扫描事实表lineorder，hash join和聚合，所以消耗几乎所有的db time。 生产者-消费者模型工作原理并行查询之后，可以通过视图V$PQ_TQSTAT，验证以上描述的执行过程。实例1、2上的p002/p003进程作为生产者，几乎平均扫描customer的1/4记录，把每一条记录广播给4个消费者PX

23、进程，发送的记录数之和为6m行。通过table queue0(TQ_ID=0)，每个作为消费者的p000/p001进程，接收了完整的1。5m行customer记录，接收的记录数之和为 6m行。 实例1、2上的p000/p0001进程作为生产者，通过table queue1(TQ_ID=1)，把聚合的一条结果记录发给作为消费者的QC。QC作为消费者，接收了4行记录。 js view plaincopyprint?SELECTdfo_number,tq_id,server_type,instance,process,num_rowsFROMV$PQ_TQSTATORDERBYdfo_numberD

24、ESC,tq_id,server_typedesc,instance,process;DFO_NUMBERTQ_IDSERVER_TYPEINSTANCEPROCESSNUM_ROWS-10Producer1P00210Producer1P00310Producer2P00210Producer2P00310Consumer1P00010Consumer1P00110Consumer2P00010Consumer2P00111Producer1P000111Producer1P001111Producer2P000111Producer2P001111Consumer1QC413rowssel

25、ected.SELECTdfo_number, tq_id, server_type, instance, process, num_rowsFROMV$PQ_TQSTATORDER BYdfo_number DESC, tq_id, server_type desc, instance, process;DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS- - - - - -1 0 Producer 1 P002 1 0 Producer 1 P003 1 0 Producer 2 P002 1 0 Producer 2 P003 1

26、 0 Consumer 1 P000 1 0 Consumer 1 P001 1 0 Consumer 2 P000 1 0 Consumer 2 P001 1 1 Producer 1 P000 11 1 Producer 1 P001 11 1 Producer 2 P000 11 1 Producer 2 P001 11 1 Consumer 1 QC 413 rows selected.那么，以上的输出中，DFO_NUMBER和TQ_ID这两列表示什么意思呢?DFO代表Data Flow Operator，是执行计划中可以并行执行的操作。一个QC代表一棵DFO树(tree)，包含多个D

27、FO;同一个QC中所有并行操作的DFO_NUMBER是相同的，此例中，所有DFO_NUMBER为1。执行计划包含多个QC的例子也不少见，比如使用unionall的语句，unionall每个分支都是独立的DFO树，不同的DFO树之间可以并行执行。本篇文章仅讨论执行计划只有一个QC的情况。 TQ代表table queue，用以PX进程之间或者和QC通信连接。以上执行计划中，table queue0为PX进程之间的连接，table queue1为PX进程和QC之间的连接。生产者通过table queue分发数据，消费者从tablequeue接收数据。不同的table queue编号，代表了不同的数据

28、分发。通过table queue，我们可以理解Oracle并行执行使用生产者-消费者模型的本质： 同一棵DFO树中，最多只有两组PX进程。每个生产者进程都存在一个和每个消费者进程的连接，每个PX进程和QC都存在一个连接。假设DoP=n，连接总数为(n*n+2*n)，随着n的增长，连接总数会爆炸型增长。Oracle并行执行设计时，采用生产者和消费者模型，考虑到连接数的复杂度，每个DFO最多只分配两组PX进程。假设DoP=100时，两组PX进程之间的连接总数为10000。假设可以分配三组PX进程一起完成并行执行计划，那么三组PX之间连接总数会等于1百万，维护这么多连接，是一个不可能的任务。 同一棵

29、DFO树中，两组PX进程之间，同一时间只存在一个活跃的数据分发。如果执行路径很长，数据需要多次分发，两组PX进程会变换生产者消费者角色，相互协作，完成所有并行操作。每次数据分发，对应的tablequeue的编号不同。一个活跃的数据分发过程，需要两组PX进程都参与，一组为生产者发送数据，一组为消费者接收数据。因为一个DFO里最多只有两组PX进程，意味着，PX进程之间，同一时间只能有一个活跃的数据分发。如果PX进程在执行计划中需要多次分发数据，可能需要在执行计划插入一些阻塞点，比如BUFFERSORT和HASHJOINBUFFERED这两个操作，保证上一次的数据分发完成之后，才开始下一次分发。在后

30、面的章节，我将会说明这些阻塞点带来什么影响。这个例子中，tablequeue0和1可以同时工作是因为：tablequeue0是两组PX进程之间的链接，tablequeue1为PX进程和QC之间的连接，tablequeue0与tablequeue1是相互独立的，因此 可以同时进行。 PX进程之间或者与QC的连接至少存在一个(单节点下至多三个，RAC环境下至多四个)消息缓冲区用于进程间数据交互，该消息缓冲区默认在Largepool中分配(如果没有配置Largepool则在Sharedpool中分配)。多个缓冲区是为了实现异步通信，提高性能。 每个消息缓冲区的大小由参数parallel_execut

31、ion_message_size控制，默认为16k。 当两个进程都在同一个节点的时候，通过在Largepool(如果没有配置Largepool则Sharedpool)中传递和接收消息缓冲进行数据交互。当两个进程位于不同节点时。通过RAC心跳网络进行数据交互，其中一方接收的数据需要缓存在本地Largepool(如果没有配置Largepool则Sharedpool)里面。 小结为了说明并行执行的生产者-消费者模型是如何工作的，我使用了broad cast分发，QC分配两组PX进程，一组为生产者，一组为消费者。QC和PX进程之间，两组PX进程之间通过table queue进行数据分发，协同完成整个并

32、行执行计划。视图V$PQ_TQSTAT记录了并行执行过程中，数据是如何分发的。通过对DFO，table queue的描述，我阐述生产者-消费者模型的工作原理和通信过程，或许有些描述对你来说过于突然，不用担心，后面的章节我会通过更多的例子来辅助理解。如何阅读并行执行计划Table queue 的编号代表了并行执行计划中，数据分发的顺序。理解执行计划中的并行操作是如何被执行的，原则很简单：跟随Tablequeue的顺序。 通过sqlmonitor报告判断sql的执行顺序，需要结合name列的tablequeue名字比如：TQ10000(代表DFO=1，tablequeue0)，：TQ10001(代

33、表DFO=1，tablequeue1)，还有PX进程的颜色，进行确定。下面的例子为dbms_xplan。display_cursor 的输出。对于并行执行计划，会多出来三列： 1.TQ列：为Q1：00或者Q1：01，其中Q1代表第一个DFO，00或者01代表tablequeue的编号。a. ID79的操作的TQ列为Q1，00，该组PX进程，作为生产者首先执行，然后通过broadcast 的分发方式，把数据发给消费者。 b. ID1011，36的操作的TQ列为Q1，01，该组PX进程作为消费者接受customer的数据之后，扫描lineorder，hashjoin，聚合之后，又作为生产者通过ta

34、blequeue2把数据 发给QC。 2. In-out 列：表明数据的流动和分发。 PCWC：parallelcombinewithchild。 PCWP：parallelcombinewithparent。 P-P： paralleltoparallel。 P-S： paralleltoSerial。3.PQDistribute 列：数据的分发方式。此执行计划中，我们使用了broadcast 的方式，下面的章节 我会讲述其他的分发方式。 HASH分发方式， 两次数据分发除了broadcast分发方式，另一种常见的并行分发方式为hash。为了观察使用hash分发时sql的 执行情况，我对sq

35、l使用pq_distributehint 。 js view plaincopyprint?select/*+monitorparallel(4)leading(customerlineorder)use_hash(lineorder)pq_distribute(lineorderhashhash)*/sum(lo_revenue)fromlineorder,customerwherelo_custkey=c_custkey;select /*+ monitor parallel(4) leading(customer lineorder) use_hash(lineorder) pq_dis

36、tribute(lineorder hash hash) */ sum(lo_revenue)from lineorder, customerwhere lo_custkey = c_custkey;使用hash分发方式时，sql的执行时间为29s，dbtime为2.6m。相对于broadcast方式，sql的执行时间和dbtime都增加了大约40%。执行计划如下，执行计划为14行，增加了对lineorder的hash分发，第11行的PXSENDHASH对3亿行数据通过hash函数分发，第10行的PXRECEIVE通过tablequeue1接收3亿行数据，这两个操作消耗了38%的dbcpu。这

37、就是为什么SQL执行时间和dbtime变长的原因。此时，SQL的执行顺序为：红色的PX进程作为生产者，并行扫描customer(第89行)，对于连接键c_custkey运用函数，根据每行记录的hash值，通过table queue0，发给4个蓝色消费者的其中一个(第7行)。Hash分发方式并不会复制数据，sql monitor报告的第69行，actual rows列都为1.5m。 红色的PX进程作为生产者，并行扫描li neorder(第1213行)，对于连接键l o_custkey运用同样的 dhash函数，通过tablequeue1 ，发给4个蓝色消费者的其中一个(第11行)。同样的has

38、h函数保证了customer和li neorder相同的连接键会发给同一个消费者，保证hashj oin结果的正确。因为3亿行数据都需要经过hash函数计算，然后分发(这是进程间的通信，或者需要通过RAC心跳网络通信)，这些巨大的额外开销，就是增加38% cpu的原因。 4个蓝色的PX进程作为消费者接收了customer的1.5M行记录(第 6 行)，和lineorder的3亿行记录(第10行)，进行hash join(第5行)，预聚合(第4行)。4个蓝色的PX进程反过来作为生产者，通过table queue2，把聚合的数据发给消费者QC(第3 行和第2行)。由QC对接收到4行记录做最后的聚合

39、， 然后返回给用户(第1和0行)。 观察sql monitor报告中Parallel标签下的信息，红色的px进程为实例1、2上的p002/p003进程，蓝色的PX进程为p000/p001进程。作为生产者的红色PX进程负责扫描事实表lineorder，对3亿行数据进行hash分发，占了超过1/3的db time。 因为涉及3亿行数据的分发和接收，作为生产者的红色PX进程和作为消费者的蓝色PX进程需要同时活跃，SQL monitor报告中的activity信息显示大部分时间，AAS超过并行度4，意味这两组PX进程同时工作。不像replicate或者broadcast分发时，AAS为4，只有一组PX

40、进程保持活跃。 js view plaincopyprint?SELECTdfo_number,tq_id,server_type,instance,process,num_rowsFROMV$PQ_TQSTATORDERBYdfo_numberDESC,tq_id,server_typedesc,instance,process;DFO_NUMBERTQ_IDSERVER_TYPEINSTANCEPROCESSNUM_ROWS-10Producer1P00210Producer1P00310Producer2P00210Producer2P00310Consumer1P00010Consum

41、er1P00110Consumer2P00010Consumer2P00111Producer1P000111Producer1P001111Producer2P000111Producer2P001111Consumer1QC413rowsselected.SELECTdfo_number, tq_id, server_type, instance, process, num_rowsFROMV$PQ_TQSTATORDER BYdfo_number DESC, tq_id, server_type desc, instance, process;DFO_NUMBER TQ_ID SERVE

42、R_TYPE INSTANCE PROCESS NUM_ROWS- - - - - -1 0 Producer 1 P002 1 0 Producer 1 P003 1 0 Producer 2 P002 1 0 Producer 2 P003 1 0 Consumer 1 P000 1 0 Consumer 1 P001 1 0 Consumer 2 P000 1 0 Consumer 2 P001 1 1 Producer 1 P000 11 1 Producer 1 P001 11 1 Producer 2 P000 11 1 Producer 2 P001 11 1 Consumer

43、1 QC 413 rows selected.js view plaincopyprint?select/*+monitorparallel(4)*/sum(lo1.lo_revenue)fromlineorder_hash32lo1,lineorder_hash32lo2wherelo1.lo_orderkey=lo2.lo_orderkey;select /*+ monitor parallel(4)*/sum(lo1.lo_revenue)fromlineorder_hash32 lo1, lineorder_hash32 lo2wherelo1.lo_orderkey = lo2.lo

44、_orderkey;并行查询之后，通过视图V$PQ_TQSTAT，进一步验证以上描述的执行过程。并行执行过程涉及3个tablequeue0/1/2，V$PQ_TQSTAT包含21行记录。1.实例1、2上的p002/p003进程作为生产者，平均扫描customer的1/4记录，然后通过tablequeue0(TQ_ID=0)，发给作为消费者的p000/p001进程。发送和接收的customer记录之和都为 1.5m。 发送的记录数：= + 接收的记录数：= +2. 实例1、2上的p002/p0003进程作为生产者，平均扫描lineorder的1/4记录，通过table queue1(TQ_ID=

45、1) ，发给作为消费者的p000/p001进程。发送和接收的lineorder 记录之和都为。 发送的记录数：= + 接收的记录数：= +3.实例1、2上的p000/p0001进程作为生产者，通过tablequeue2(TQ_ID=2)，把聚合的一条结果记 录发给作为消费者的QC。QC作为消费者，接收了4行记录。 js view plaincopyprint?SELECTdfo_number,tq_id,server_type,instance,process,num_rowsFROMV$PQ_TQSTATORDERBYdfo_numberDESC,tq_id,server_typedesc,

46、instance,process;DFO_NUMBERTQ_IDSERVER_TYPEINSTANCEPROCESSNUM_ROWS-10Producer1P00210Producer1P00310Producer2P00210Producer2P00310Consumer1P00010Consumer1P00110Consumer2P00010Consumer2P00111Producer1P00211Producer1P00311Producer2P00211Producer2P00311Consumer1P00011Consumer1P00111Consumer2P00011Consum

47、er2P00112Producer1P000112Producer1P001112Producer2P000112Producer2P001112Consumer1QC421rowsselected.SELECTdfo_number, tq_id, server_type, instance, process, num_rowsFROMV$PQ_TQSTATORDER BYdfo_number DESC, tq_id, server_type desc, instance, process;DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_RO

48、WS- - - - - -1 0 Producer 1 P002 1 0 Producer 1 P003 1 0 Producer 2 P002 1 0 Producer 2 P003 1 0 Consumer 1 P000 1 0 Consumer 1 P001 1 0 Consumer 2 P000 1 0 Consumer 2 P001 1 1 Producer 1 P002 1 1 Producer 1 P003 1 1 Producer 2 P002 1 1 Producer 2 P003 1 1 Consumer 1 P000 1 1 Consumer 1 P001 1 1 Con

49、sumer 2 P000 1 1 Consumer 2 P001 1 2 Producer 1 P000 11 2 Producer 1 P001 11 2 Producer 2 P000 11 2 Producer 2 P001 11 2 Consumer 1 QC 421 rows selected.小结数组大小m，可以把错误判断的几率控制在很小的范围之内。 我们观察hash分发时sql的并行执行过程。Hash分发与broadcast最大的区分在于对hashjoin的 两边都进行分发。这个例子中，对lineorder 的hash分发会增加明显的dbcpu 。下一节，我将使用另一个例子，说明

50、hash分发适用的场景。 Replicate，Broadcast和Hash的选择我们已经测试过replicate，broadcast，和hash这三种分发方式。Replicate ：每个PX进程重复扫描hashjoin 的左边，buffercache 被用来缓存hashjoin 左边的小表，减少重复扫描所需的物理读。相对于broadcast 分发，replicate 方式只需一组PX进程。但是repli cate不能替换br oadcast分发。因为repli cate仅限于hashj oin左边是表的情况，如果 hashjoin的左边的结果集来自其他操作，比如j oin或者视图，那么此时无法

51、使用repli cate。 Broadcast分发：作为生产者的PX进程通过广播的方式，把hashjoin左边的结果集分发给每 个作为消费者的PX进程。一般适用于hashjoin 左边结果集比右边小得多的场景，比如星型模型。 Hash分发的本质：把hashjoin的左边和右边(两个数据源)，通过同样hash函数重新分发，切 分为N个工作单元(假设DoP=N)，再进行join ，目的是减少PX进程进行join 操作时，需要连接的数据量。Hash分发的代价需要对hashjoin 的两边都进行分发。对于customer连接li neorder的例子，因为维度表customer的数据量比事实表li neorder小得多，对customer进行repli cate或者broadcast 分发显然是更好的选择，因为这两种方式不用对lineorder 进行重新分发。如果是两个大表join 的话，join操作会是整个执行计划的