这篇文章主要介绍“怎么理解Oracle的并行执行”,在日常操作中,相信很多人在怎么理解Oracle的并行执行问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”怎么理解Oracle的并行执行”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
术语说明:
S: 时间单位秒。
K: 数量单位一千。
M: 数量单位一百万, 或者时间单位分钟。
DoP: Degree of Parallelism, 并行执行的并行度。
QC: 并行查询的 Query Coordinator。
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 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。
select owner seg_owner, segment_name seg_segment_name, round(bytes/1048576,2) SEG_MB from dba_segments where owner = 'SID' and segment_name in ('LINEORDER','PART','CUSTOMER') / OWNER SEGMENT_NAME SEGMENT_TYPE SEG_MB ------ ------------ ------------ -------- SID LINEORDER TABLE 30407.75 SID CUSTOMER TABLE 168 SID PART TABLE 120
本篇文章所有的测试,除非特别的说明,我关闭了12c的adaptive plan特性,参数optimizer_adaptive_features被默认设置为false。Adaptive相关的特性如cardinality feedback,adaptive distribution method,adaptive join都不会启用。如果检查执行计划的outline数据,你会发现7个优化器相关的隐含参数被设置为关闭状态。事实上,12c优化器因为引入adaptive plan特性,比以往版本复杂得多,剖析12c的优化器的各种新特性,我觉得非常具有挑战性,或许我会在另一篇文章里尝试一下。
select * from table(dbms_xplan.display_cursor('77457qc9a324k',0,’outline’)); ... Outline Data -------------
并行初体验
串行执行
以下sql对customers和lineorder连接之后,计算所有订单的全部利润。 串行执行时不使用parallel hint:
select sum(lo_revenue) from lineorder, customer where lo_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 X3——8,30GB的IO请求在一秒之内处理完成。Celloffload Efficiency等于87%意味着经过存储节点扫描,过滤不需要的列,最终返回计算节点的数据大小只有30GB的13%。
并行执行
使用hint parallel(4),指定DoP=4并行执行同样的sql:
select sum(lo_revenue) from lineorder, customer where lo_custkey = c_custkey;
SQL执行时间为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行),最后返回数据(第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,这是最理想的情况,每个PX进程完成同样的工作量,一直保持活跃。没有串行点,没有并行执行倾斜。
AAS=4,查看活动信息时,为了更好的展示活动信息,注意点掉”CPU Cores”这个复选框。
在Linux系统上显示这四个PX进程。
[oracle@exa01db01 sidney]$ ps -ef | egrep "p00[01]_SSB" oracle 20888 1 4 2014 ? 18:50:59 ora_p000_SSB1 oracle 20892 1 4 2014 ? 19:01:29 ora_p001_SSB1 [oracle@exa01db01 sidney]$ ssh exa01db02 'ps -ef | egrep "p00[01]_SSB"' oracle 56910 1 4 2014 ? 19:01:03 ora_p000_SSB2 oracle 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维度表的行为,是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行),分发’PXSENDBROADCAST’和接收’PXRECEIVE’。执行计划中出现了两组PX进程,除了之前蓝色的多人标志,现在出现了红色的多人标志。此时,SQL的执行顺序为:
4个红色的PX进程扮演生产者角色,扫描维度表customer,把数据通过broadcast的方式分发给每一个扮演消费者的蓝色PX进程。因为DoP=4,每一条被扫描出来的记录被复制了4份,从sqlmonitor的第9行,customer全表扫描返回1。5m行数据,第8行的分发和第7行的接受之时,变成了6m行记录,每个作为消费者的蓝色px进程都持有了一份完整包含所有custome记录的数据,并准备好第5行hashjoin的buildtable。
4个作为消费者的蓝色PX进程,以数据块地址区间为单位扫描事实表lineorder(第10/11行);同时和已经持有的customer表的数据进hashjoin(第5行),然后对满足join条件的数据做预聚合(第4行),因为我们查询的目标是对所有lo_revenue求和,聚合之后每个PX进程只需输出一个总数。
4个蓝色的PX进程反过来作为生产者,把聚合的数据发给消费者QC(第3行和第2行)。由QC对接收到4行记录做最后的聚合,然后返回给用户。
使用broadcast的分发方式,只需要把customer的数据广播给每个消费者。Lineorder的数不需要重新分发。因为lineorder的数据量比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进程,发送的记录数之和为6m行。通过table queue0(TQ_ID=0),每个作为消费者的p000/p001进程,接收了完整的1。5m行customer记录,接收的记录数之和为6m行。
实例1、2上的p000/p0001进程作为生产者,通过table queue1(TQ_ID=1),把聚合的一条结果记录发给作为消费者的QC。QC作为消费者,接收了4行记录。
SELECT dfo_number, tq_id, server_type, instance, process, num_rows FROM V$PQ_TQSTAT ORDER BY dfo_number DESC, tq_id, server_type desc, instance, process; DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS ---------- ---------- -------------- ---------- --------- ---------- 1 0 Producer 1 P002 1461932 1 0 Producer 1 P003 1501892 1 0 Producer 2 P002 1575712 1 0 Producer 2 P003 1460464 1 0 Consumer 1 P000 1500000 1 0 Consumer 1 P001 1500000 1 0 Consumer 2 P000 1500000 1 0 Consumer 2 P001 1500000 1 1 Producer 1 P000 1 1 1 Producer 1 P001 1 1 1 Producer 2 P000 1 1 1 Producer 2 P001 1 1 1 Consumer 1 QC 4 13 rows selected.
那么,以上的输出中,DFO_NUMBER和TQ_ID这两列表示什么意思呢?
DFO代表Data Flow Operator,是执行计划中可以并行执行的操作。一个QC代表一棵DFO树(tree),包含多个DFO;同一个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编号,代表了不同的数据分发。通过table queue,我们可以理解Oracle并行执行使用生产者-‐消费者模型的本质:
同一棵DFO树中,最多只有两组PX进程。每个生产者进程都存在一个和每个消费者进程的连接,每个PX进程和QC都存在一个连接。假设DoP=n,连接总数为(n*n+2*n),随着n的增长,连接总数会爆炸型增长。Oracle并行执行设计时,采用生产者和消费者模型,考虑到连接数的复杂度,每个DFO最多只分配两组PX进程。假设DoP=100时,两组PX进程之间的连接总数为10000。假设可以分配三组PX进程一起完成并行执行计划,那么三组PX之间连接总数会等于1百万,维护这么多连接,是一个不可能的任务。
同一棵DFO树中,两组PX进程之间,同一时间只存在一个活跃的数据分发。如果执行路径很长,数据需要多次分发,两组PX进程会变换生产者消费者角色,相互协作,完成所有并行操作。每次数据分发,对应的tablequeue的编号不同。一个活跃的数据分发过程,需要两组PX进程都参与,一组为生产者发送数据,一组为消费者接收数据。因为一个DFO里最多只有两组PX进程,意味着,PX进程之间,同一时间只能有一个活跃的数据分发。如果PX进程在执行计划中需要多次分发数据,可能需要在执行计划插入一些阻塞点,比如BUFFERSORT和HASHJOINBUFFERED这两个操作,保证上一次的数据分发完成之后,才开始下一次分发。在后面的章节,我将会说明这些阻塞点带来什么影响。这个例子中,tablequeue0和1可以同时工作是因为:tablequeue0是两组PX进程之间的链接,tablequeue1为PX进程和QC之间的连接,tablequeue0与tablequeue1是相互独立的,因此可以同时进行。
PX进程之间或者与QC的连接至少存在一个(单节点下至多三个,RAC环境下至多四个)消息缓冲区用于进程间数据交互,该消息缓冲区默认在Largepool中分配(如果没有配置Largepool则在Sharedpool中分配)。多个缓冲区是为了实现异步通信,提高性能。
每个消息缓冲区的大小由参数parallel_execution_message_size控制,默认为16k。
当两个进程都在同一个节点的时候,通过在Largepool(如果没有配置Largepool则Sharedpool)中传递和接收消息缓冲进行数据交互。当两个进程位于不同节点时。通过RAC心跳网络进行数据交互,其中一方接收的数据需要缓存在本地Largepool(如果没有配置Largepool则Sharedpool)里面。
小结
为了说明并行执行的生产者--消费者模型是如何工作的,我使用了broad cast分发,QC分配两组PX进程,一组为生产者,一组为消费者。QC和PX进程之间,两组PX进程之间通过table queue进行数据分发,协同完成整个并行执行计划。视图V$PQ_TQSTAT记录了并行执行过程中,数据是如何分发的。通过对DFO,table queue的描述,我阐述生产者-‐消费者模型的工作原理和通信过程,或许有些描述对你来说过于突然,不用担心,后面的章节我会通过更多的例子来辅助理解。
如何阅读并行执行计划
Table queue 的编号代表了并行执行计划中,数据分发的顺序。理解执行计划中的并行操作是如何被执行的,原则很简单:跟随Tablequeue的顺序。
通过sqlmonitor报告判断sql的执行顺序,需要结合name列的tablequeue名字比如:TQ10000(代表DFO=1,tablequeue0),:TQ10001(代表DFO=1,tablequeue1),还有PX进程的颜色,进行确定。
下面的例子为dbms_xplan。display_cursor 的输出。对于并行执行计划,会多出来三列:
1. TQ列:为Q1:00或者Q1:01,其中Q1代表第一个DFO,00或者01代表tablequeue的编号。
a. ID7~9的操作的TQ列为Q1,00,该组PX进程,作为生产者首先执行,然后通过broadcast 的分发方式,把数据发给消费者。
b. ID10~11,3~6的操作的TQ列为Q1,01,该组PX进程作为消费者接受customer的数据之后,扫描lineorder,hashjoin,聚合之后,又作为生产者通过tablequeue2把数据发给QC。
2. In-‐out 列:表明数据的流动和分发。
• PCWC:parallelcombinewithchild。
• PCWP:parallelcombinewithparent。
• P-‐>P: paralleltoparallel。
• P-‐>S: paralleltoSerial。
3. PQDistribute 列:数据的分发方式。此执行计划中,我们使用了broadcast 的方式,下面的章节
我会讲述其他的分发方式。
HASH分发方式, 两次数据分发
除了broadcast分发方式,另一种常见的并行分发方式为hash。为了观察使用hash分发时sql的 执行情况,我对sql使用pq_distributehint。
select sum(lo_revenue) from lineorder, customer where 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。这就是为什么SQL执行时间和dbtime变长的原因。此时,SQL的执行顺序为:
红色的PX进程作为生产者,并行扫描customer(第8~9行),对于连接键c_custkey运用函数,根据每行记录的hash值,通过tablequeue0,发给4个蓝色消费者的其中一个(第7行)。Hash分发方式并不会复制数据,sqlmonitor报告的第6~9行,actualrows列都为1.5m。
红色的PX进程作为生产者,并行扫描li neorder(第12~13行),对于连接键lo_custkey运用同样的dhash函数,通过tablequeue1,发给4个蓝色消费者的其中一个(第11行)。同样的hash函数保证了customer和lineorder相同的连接键会发给同一个消费者,保证hashjoin结果的正确。因为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行记录做最后的聚合, 然后返回给用户(第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进程保持活跃。
SELECT dfo_number, tq_id, server_type, instance, process, num_rows FROM V$PQ_TQSTAT ORDER BY dfo_number DESC, tq_id, server_type desc, instance, process; DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS ---------- ---------- -------------- ---------- --------- ---------- 1 0 Producer 1 P002 299928364 1 0 Producer 1 P003 299954384 1 0 Producer 2 P002 300188788 1 0 Producer 2 P003 299951708 1 0 Consumer 1 P000 300005811 1 0 Consumer 1 P001 300005811 1 0 Consumer 2 P000 300005811 1 0 Consumer 2 P001 300005811 1 1 Producer 1 P000 1 1 1 Producer 1 P001 1 1 1 Producer 2 P000 1 1 1 Producer 2 P001 1 1 1 Consumer 1 QC 4 13 rows selected.
select sum(lo1.lo_revenue) from lineorder_hash42 lo1, lineorder_hash42 lo2 where lo1.lo_orderkey = lo2.lo_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。
• 发送的记录数:1500000= 365658+364899+375679+393764
• 接收的记录数:1500000= 374690+374924+375709+374677
2. 实例1、2上的p002/p0003进程作为生产者,平均扫描lineorder的1/4记录,通过table queue1(TQ_ID=1) ,发给作为消费者的p000/p001进程。发送和接收的lineorder 记录之和都为300005811。
• 发送的记录数:300005811= 74987629+75053393+74979748+74985041
• 接收的记录数:300005811= 74873553+74968719+75102151+75061388
3. 实例1、2上的p000/p0001进程作为生产者,通过tablequeue2(TQ_ID=2),把聚合的一条结果记 录发给作为消费者的QC。QC作为消费者,接收了4行记录。
SELECT dfo_number, tq_id, server_type, instance, process, num_rows FROM V$PQ_TQSTAT ORDER BY dfo_number DESC, tq_id, server_type desc, instance, process; DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS ---------- ---------- ---------------- ---------- --------- ---------- 1 0 Producer 1 P002 365658 1 0 Producer 1 P003 364899 1 0 Producer 2 P002 375679 1 0 Producer 2 P003 393764 1 0 Consumer 1 P000 374690 1 0 Consumer 1 P001 374924 1 0 Consumer 2 P000 375709 1 0 Consumer 2 P001 374677 1 1 Producer 1 P002 74987629 1 1 Producer 1 P003 75053393 1 1 Producer 2 P002 74979748 1 1 Producer 2 P003 74985041 1 1 Consumer 1 P000 74873553 1 1 Consumer 1 P001 74968719 1 1 Consumer 2 P000 75102151 1 1 Consumer 2 P001 75061388 1 2 Producer 1 P000 1 1 2 Producer 1 P001 1 1 2 Producer 2 P000 1 1 2 Producer 2 P001 1 1 2 Consumer 1 QC 4 21 rows selected.
小结
数组大小m,可以把错误判断的几率控制在很小的范围之内。
我们观察hash分发时sql的并行执行过程。Hash分发与broadcast最大的区分在于对hashjoin的两边都进行分发。这个例子中,对lineorder的hash分发会增加明显的dbcpu。下一节,我将使用另一个例子,说明hash分发适用的场景。
Replicate,Broadcast和Hash的选择
我们已经测试过replicate,broadcast,和hash这三种分发方式。
Replicate :每个PX进程重复扫描hashjoin的左边,buffercache被用来缓存hashjoin左边的小表,减少重复扫描所需的物理读。相对于broadcast分发,replicate方式只需一组PX进程。但是replicate不能替换broadcast分发。因为repli cate仅限于hashjoin左边是表的情况,如果 hashjoin的左边的结果集来自其他操作,比如join或者视图,那么此时无法使用replicate。
Broadcast分发:作为生产者的PX进程通过广播的方式,把hashjoin左边的结果集分发给每 个作为消费者的PX进程。一般适用于hashjoin左边结果集比右边小得多的场景,比如星型模型。
Hash分发的本质:把hashjoin的左边和右边(两个数据源),通过同样hash函数重新分发,切 分为N个工作单元(假设DoP=N),再进行join ,目的是减少PX进程进行join操作时,需要连接的数据量。Hash分发的代价需要对hashjoin的两边都进行分发。对于customer连接lineorder的例子,因为维度表customer的数据量比事实表lineorder小得多,对customer进行replicate或者broadcast分发显然是更好的选择,因为这两种方式不用对lineorder进行重新分发。如果是两个大表join的话,join操作会是整个执行计划的瓶颈所在,hash分发是唯一合适的方式。为了减低join的代价,对hashjoin左边和右边都进行hash分发的代价是可以接受的。
Hash分发,有时是唯一合理的选择
我们使用lineorder上的自连接来演示,为什么有时hash分发是唯一合理的选择。测试的SQL如 下:
select sum(lo1.lo_revenue) from lineorder lo1, lineorder lo2 where lo1.lo_orderkey = lo2.lo_orderkey;
SQL执行时间为2.4分钟,dbtime为10.5分钟。
优化器默认选择hash分发方式,执行计划为14行,结构与之前的Hash分发的例子是一致的。不 同的是,第5行的hash join消耗了73%的db time,使用了9GB的临时表空间,表空间的IO占12%的db time。大约15%的db time用于Lineorder的两次hash分发和接收,相对上一个例子的占38%比例,这两次HASH分发的整体影响降低了一倍多。
红色的PX进程为实例1、2上的p002/p003进程,蓝色的PX进程为p000/p001进程。作为生产者的红色PX进程占总db time的15%左右。
SQL执行开始,对lineorder两次hash分发时,AAS大于4,分发完成之后,只有蓝色的PX进程进行 hash join操作,AAS=4。
从V$PQ_TQSTAT视图可以确认,对于lineorder的存在两次分发,通过table queue0和1,作为消费者的4个PX进程接收到的两次数据是一样的,保证重新分发不会影响join结果的正确性。每个蓝色PX 进程需要hash join的左边和右边均为3亿行数据的1/4,通过hash分发,3亿行记录连接3亿行记录的工作平均的分配四个独立PX进程各自处理,每个PX进程处理75M行记录连接75M行记录。
SELECT dfo_number, tq_id, server_type, instance, process, num_rows FROM V$PQ_TQSTAT ORDER BY dfo_number DESC, tq_id, server_type desc, instance, process; DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS ---------- ---------- -------------- ---------- --------- ---------- 1 0 Producer 1 P002 75055725 1 0 Producer 1 P003 74977459 1 0 Producer 2 P002 74995276 1 0 Producer 2 P003 74977351 1 0 Consumer 1 P000 74998419 1 0 Consumer 1 P001 74995836 1 0 Consumer 2 P000 74976974 1 0 Consumer 2 P001 75034582 1 1 Producer 1 P002 74986798 1 1 Producer 1 P003 74985268 1 1 Producer 2 P002 74984883 1 1 Producer 2 P003 75048862 1 1 Consumer 1 P000 74998419 1 1 Consumer 1 P001 74995836 1 1 Consumer 2 P000 74976974 1 1 Consumer 2 P001 75034582 1 2 Producer 1 P000 1 1 2 Producer 1 P001 1 1 2 Producer 2 P000 1 1 2 Producer 2 P001 1 1 2 Consumer 1 QC 4 21 rows selected.
使用 broadcast 分发,糟糕的性能
对于lineorder,lineorder的自连接, 如果我们使用broadcast分发,会出现什么情况呢?我们测试一下:
select 15 sum(lo1.lo_revenue) from lineorder lo1, lineorder lo2 where lo1.lo_orderkey = lo2.lo_orderkey;
使用broadcase分发,SQL的执行时间为5.9分钟,db time为23.8分钟。相比hash分发,执行时间和 db time都增加了接近1.5倍。
红色的PX进程作为生产者,对lineorder进行并行扫描之后,3亿行记录通过tablequeue0广播给4个作为消费者的蓝色PX进程(第6~9行),相当于复制了4份,每个蓝色的PX进程都接收了3亿行记录.这次broadcast分发消耗了11%的db time,因为需要每行记录传输给每个蓝色PX进程,消耗的db cpu比使用hash分发时两次hash分发所消耗的还多。
第5行的hash join的所消耗的临时表空间上升到27GB,临时表空间IO占的db time的38%。因为每个蓝色PX进程进行hash join的数据变大了,hash join的左边为3亿行数据,hash join的右边为3亿行记录的1/4.
蓝色PX进程为消费者负责hash join,所消耗的db time都大幅增加了。
hash join时,临时表空间读等待事件’direct path read temp’明显增加了。
V$PQ_TQSTAT的输出中,实例1、2上的p000/p001进程作为消费者,都接收了3亿行数据,造成后续hash join的急剧变慢。Broadcast分发对hash join左边进行广播的机制,决定了它不适合hash join两边都为大表的情况。
SELECT dfo_number, tq_id, server_type, instance, process, num_rows FROM V$PQ_TQSTAT ORDER BY dfo_number DESC, tq_id, server_type desc, instance, process; DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS ---------- ---------- -------------- ---------- --------- ---------- 1 0 Producer 1 P002 299928364 1 0 Producer 1 P003 299954384 1 0 Producer 2 P002 300188788 1 0 Producer 2 P003 299951708 1 0 Consumer 1 P000 300005811 1 0 Consumer 1 P001 300005811 1 0 Consumer 2 P000 300005811 1 0 Consumer 2 P001 300005811 1 1 Producer 1 P000 1 1 1 Producer 1 P001 1 1 1 Producer 2 P000 1 1 1 Producer 2 P001 1 1 1 Consumer 1 QC 4 13 rows selected.
小结,Broadcast和Hash分发的陷阱
通过前一节和本节的例子,我们知道,如果选择了不合理的分发方式,SQL执行时性能会明显下降
对于broadcast分发:只对hash join的左边进行分发,但是采用广播分发,hash join时左边的数据量并没有减少,如果hash join左边的包含大量数据,并行对hash join性能改善有限。对大量数据的broadcast分发也会消耗额外的db cpu,比如本节中lineorder自连接的例子。Replicate 同理。
对于hash分发:对hash join的两边都进行分发,使每个PX进程进行hash join时,左边和右边的数据量都为原始的1/N,N为并行度。Hash分发的潜在陷阱在于:
•两次分发,尤其对大表的分发,可能带来明显的额外开销,比如前一节customer连接lineorder 的例子。使用Partition wise join可以消除分发的需要,后面会举例说明。
•如果数据存在倾斜,连接键上的少数值占了大部分的数据,通过hash分发,同一个键值的记录会分发给同一个PX进程,某一个PX进程会处理大部分数据的hash join,引起并行执行倾斜。我会在后面的章节说明这种情况和解决方法。
SQL解析时,优化器会根据hash join左边和右边估算的cardinality,并行度等信息,选择具体何种分发方式。维护正确的统计信息,对于优化器产生合理的并行执行计划是至关重要的。
Partition Wise Join,消除分发的额外开销
无论对于broadcast或者hash分发,数据需要通过进程或者节点之间通信的完成传输,分发的数据越多,消耗的db cpu越多。并行执行时,数据需要分发,本质上是因为Oracle采用share---everything的集中存储架构,任何数据对每个实例的PX进程都是共享的。为了对hash join操作分而治之,切分为N个独立的工作单元(假设 DoP=N),必须提前对数据重新分发,数据的分发操作就是并行带来的额外开销。
使用full或者partial partition wise join技术,可以完全消除分发的额外开销,或者把这种开销降到最低。如果hash join有一边在连接键上做hash分区,那么优化器可以选择对分区表不分发,因为hash分区已经对数据完成切分,这只需要hash分发hash join的其中一边,这是partial partition wise join。如果hash join的两边都在连接键上做了hash join分区,那么每个PX进程可以独立的处理对等的hash分区, 没有数据需要分发,这是full partition wise join。hash分区时,hash join的工作单元就是对等hash分区包含的数据量,应该控制每个分区的大小,hash join时就可能消除临时表空间的使用,大幅减少所需的PGA。
Partition Wise Join,不需要数据分发。
如果在lineorder的列lo_orderkey上做hash分区,分区数为32个。每个分区的大小接近1G。
SEGMENT_NAME SEG_PART_NAME SEGMENT_TYPE SEG_MB ------------------ --------------- -------------------- ---------- LINEORDER_HASH32 SYS_P3345 TABLE PARTITION 960 LINEORDER_HASH32 SYS_P3344 TABLE PARTITION 960 ... LINEORDER_HASH32 SYS_P3315 TABLE PARTITION 960 LINEORDER_HASH32 SYS_P3314 TABLE PARTITION 960 ---------- 30720 32 rows selected.
使用lo_orderkey 连接时,lineorder不需要再分发。我们继续使用自连接的sql,演示full partition wise join。
select sum(lo1.lo_revenue) from lineorder_hash42 lo1, lineorder_hash42 lo2 where lo1.lo_orderkey = lo2.lo_orderkey;
此时sql执行时间为1.6分钟,dbtime 6分钟;不分区使用hash分发时,执行时间为2.4分钟,db time 10.5 分钟。使用Partition Wise join快了三分之一。执行计划中只有一组蓝色的PX进程,不需要对数据进行分发。因为lineorder_hash42的3亿行数据被切分为32个分区。虽然并行度为4,每个PX进程hash join时,工作单元为一对匹配的hash分区,两边的数据量都为3亿的1/32。更小的工作单元,使整个hash join消耗的临时表空间下降为 448MB。每个PX进程消耗8对hash分区,可以预见,当我们把并行度提高到8/16/32,每个PX进程处理的hash分区对数,应该分别为4/2/1,sql执行时间会线性的下降。
蓝色的PX进程为、的p000/p001进程。每个PX进程消耗的db time是平均的,每个PX进程均处理了8对分区的扫描和hash join。
AAS绝大部分时间都为4。
唯一的数据连接为tablequeue0,每个PX进程向QC发送一行记录。
SELECT dfo_number, tq_id, server_type, instance, process, num_rows FROM V$PQ_TQSTAT ORDER BY dfo_number DESC, tq_id, server_type desc, instance, process; DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS ---------- ---------- ------------- ---------- ---------- ---------- 1 0 Producer 1 P000 1 1 0 Producer 1 P001 1 1 0 Producer 2 P000 1 1 0 Producer 2 P001 1 1 0 Consumer 1 QC 4 5 rows selected
当DoP大于分区数时,Partition Wise Join不会发生
当并行执行的DoP大于hash分区数时,partition wise join不会发生,这时优化器会使用 broadcast local的分发。使用DoP=64执行同样的sql:
select sum(lo1。lo_revenue) from lineorder_hash42 lo1, lineorder_hash42 lo2 where lo1。lo_orderkey = lo2。lo_orderkey
DoP=64,查询执行时间为15秒,db time为11.3分钟。
执行计划中出现了两组PX进程。优化器选择对hash join的右边进行broadcast local分发。如果hash join的左边比较小的话,broadcast local会发生在hash join的左边。因为DoP是分区数的两倍,hash join两边的lineorder_hash74的每个分区,由2个PX进程共同处理。处理一对匹配分区的两个蓝色的PX进程和两个红色的PX进程,会处在同一个实例上。数据只会在同一个实例的PX进程之间,不会跨实例传输,降低数据分发成本,这是broadcast local的含义。SQL的执行顺序如下:
以数据库地址区间为单位,蓝色的PX进程并行扫描hash join左边的lineorder_hash42(第7行),因为DoP是分区数的两倍,每个分区由两个蓝色PX进程共同扫描,这两个PX进程在同一个实例上。每个蓝色的PX进程大约扫描每个分区一半的数据,大约4.7M行记录,并准备好第5行hash join的build table。
红色的PX进程并行扫描hash join右边的lineorder_hash42,每个红色的PX进程大概扫描4.7M行记录,然后tablequeue0,以broadcast local的方式,分发给本实例两个红色的PX进程(数据分发时,映射到本实例某些PX进程,避免跨节点传输的特性,称为slaves mapping,除了broadcast local,还有hash local,random local等分发方式)。通过broadcast local分发,数据量从300M行变成600M行。
每个蓝色的PX进程通过tablequeue0接收了大概9.4M行数据,这是整个匹配分区的数据量。然后进行hash join,以及之后的聚合操作。每个蓝色的PX进程hash join操作时,左边的数据量为lineorder_hash42的1/64(=1/DoP),右边的数据为lineorder_hash42的1/32(=1/分区数)。如果继续提高DoP,只有hash join左边的数据量减少,右边的数据量并不会减少; 同时,更多的PX进程处理同一个分区,会提高broadcast分发成本。所以当DoP大于分区数时,并行执行的随着DoP的提高,扩展性并不好。
查看一个蓝色的PX进程,实例1p005进程的执行信息,可以确认hash join的左边为lineorder_hash42的1/64,hash join的右边为lineorder_hash42的1/32。
小结
数据仓库设计时,为了取得最佳的性能,应该使用partition wise join和并行执行的组合。在大表最常用的连接键上,进行hash分区,hash join时使优化器有机会选择partition wise join。Range-hash或者list-hash是常见的分区组合策略,一级分区根据业务特点,利用时间范围或者列表对数据做初步的切分,二级分区使用hash分区。查询时,对一级分区裁剪之后,优化器可以选择partition wise join。
设计partition wise join时,应该尽可能提高hash分区数,控制每个分区的大小。Partition wise join时,每对匹配的分区由一个PX进程处理,如果分区数据太多,可能导致join操作时使用临时空间,影响性能。另一方面,如果分区数太少,当DoP大于分区数时,partition wise join会失效,使用更大的DoP对性能改善非常有限。
数据倾斜对不同分发方式的影响
数据倾斜是指某一列上的大部分数据都是少数热门的值(Popular Value)。Hash join时,如果hash join的右边连接键上的数据是倾斜的,数据分发导致某个PX进程需要处理所有热门的数据,拖长sql执行时间,这种情况称为并行执行倾斜。如果优化器选择了hash分发,此时join两边的数据都进行hash分发,数据倾斜会导致执行倾斜。同值记录的hash值也是一样的,会被分发到同一PX进程进行hash join。工作分配不均匀,某个不幸的PX进程需要完成大部分的工作,消耗的db time会比其他PX进程多,SQL执行时间会因此被明显延长。对于replicate或者broadcast分发,则不存在这种执行倾斜的风险,因为hash join右边(一般为大表)的数据不用进行分发,PX进程使用基于数据块地址区间或者基于分区的granule,平均扫描hash join右边的数据,再进行join操作。
为了演示数据倾斜和不同分发的关系,新建两个表,customer_skew包含一条c_custkey=-1 的记录,lineorder_skew 90%的记录,两亿七千万行记录lo_custkey=-1。
sid@SSB> select count(*) from customer_skew where c_custkey = -1; COUNT(*) ---------- 1 sid@SSB> select count(*) from customer_skew; COUNT(*) ---------- 1500000 sid@SSB> select count(*) from lineorder_skew where lo_custkey = -1; COUNT(*) ---------- 270007612 sid@SSB> select count(*) from lineorder_skew; COUNT(*) ---------- 21 300005811
Replicate方式,不受数据倾斜的影响
测试sql如下:
select sum(lo_revenue) from lineorder_skew, customer_skew where lo_custkey = c_custkey;
SQL执行时间为23秒,db time为1.5m。优化器默认的执行计划选择replicate的方式,只需分配一组PX进程,与broadcast分发的方式类似。每个蓝色的PX进程重复扫描customer,并行扫描lineorder_skew时,是采用基于地址区间的granule为扫描单位,见第7行的’PX BLOCK ITERATOR’。
4个蓝色的PX进程消耗的db time是平均的,对于replicate方式,lineorder_skew的数据倾斜并没有造成4个PX进程的执行倾斜。
当优化器使用replicate方式时,可以通过执行计划中outline中的hint PQ_REPLICATE确认。以下部分dbms_xplan。display_cursor输出没有显示,只显示outline数据。
select * from table(dbms_xplan.display_cursor('77457qc9a324k',0,’outline’)); Plan hash value: 4050055921 ... Outline Data -------------
Hash分发,数据倾斜造成执行倾斜
通过hint使用hash分发,测试sql如下:
select sum(lo_revenue) from lineorder_skew, customer_skew where lo_custkey = c_custkey;
使用hash分发,SQL执行时间为58秒,dbtime 2.1分钟。对于replicate时sql执行时间23秒,dbtime 1.5分钟。有趣的是,整个sql消耗的db time只增加了37秒,而执行时间确增加了35秒,意味着所增加的dbtime并不是平均到每个PX进程的。如果增加的dbtime平均到每个PX进程,而且并行执行没有倾斜的话,那么sql执行时间应该增加37/4,约9秒,而不是现在的35秒。红色的PX 进程作为生产者,分别对customer_skew和lineorder_skew 完成并行扫描并通过tablequeue0/1,hash分发给蓝色的PX进程。对lineorder_skew的分发,占了45%的db cpu。
实例2的蓝色PX进程p001消耗了57.1秒的dbtime,sql执行时间58秒,这个PX进程在sql执 行过程中一直是活跃状态。可以预见,lineorder_skew所有lo_custkey=-1的数据都分发到这个进程处理。而作为生产者的红色PX进程,负责扫描lineorder_skew并进行分发,它们的工作量是平均的。
大部分时候AAS=2,只有实例2的p001进程不断的从4个生产者接收数据并进行hash join。
从V$PQ_TQSTAT视图我们可以确认,对hash join右边分发时,通过tablequeue1,作为消费者的实例2的P001,接收了两亿七千多万的数据。这就是该PX进程在整个sql执行过程中一直保持活跃的原因。
SELECT dfo_number, tq_id, server_type, instance, process, num_rows FROM V$PQ_TQSTAT ORDER BY dfo_number DESC, tq_id, server_type desc, instance, process; DFO_NUMBER TQ_ID SERVER_TYPE INSTANCE PROCESS NUM_ROWS ---------- ---------- ------------- ---------- ---------- ---------- 1 0 Producer 1 P004 375754 1 0 Producer 1 P005 365410 1 0 Producer 2 P003 393069 1 0 Producer 2 P004 365767 1 0 Consumer 1 P002 375709 1 0 Consumer 1 P003 374677 1 0 Consumer 2 P001 374690 1 0 Consumer 2 P002 374924 1 1 Producer 1 P004 75234478 1 1 Producer 1 P005 74926098 1 1 Producer 2 P003 74923913 1 1 Producer 2 P004 74921322 1 1 Consumer 1 P002 7497409 1 1 Consumer 1 P003 7467378 1 1 Consumer 2 P001 277538575 1 1 Consumer 2 P002 7502449 24 1 2 Producer 1 P002 1 1 2 Producer 1 P003 1 1 2 Producer 2 P001 1 1 2 Producer 2 P002 1 1 2 Consumer 1 QC 4 21 rows selected.
12c的sqlmonitor报告作了增强,并行执行倾斜时,包含了消耗最大的PX进程的采样信息。在plan statistics页面,下拉菜单选择’Parallel Server 3(instance 2,p001)’, 从执行计划的第10行,‘PX RECEIVE’,以及Actual Rows列的数据278M,也可以确认实例2的p001进程接收了两亿七千多万数据。
小节
对于实际的应用,处理数据倾斜是一个复杂的主题。比如在倾斜列上使用绑定变量进行过滤,绑定变量窥视(bind peeking)可能造成执行计划不稳定。本节讨论了数据倾斜对不同分发方式的带来影响:
通常,replicate或者broadcast分发不受数据倾斜的影响。
对于hash分发,hash join两边连接键的最热门数据,会被分发到同一PX进程进行join操作,容易造成明显的并行执行倾斜。
12c引入adaptive分发,可以解决hash分发时并行执行倾斜的问题。我将在下一篇文章” 深入理解Oracle的并行执行倾斜(下)”演示adaptive分发这个新特性。
HASH JOIN BUFFERED,连续hash分发时执行计划中的阻塞点
到目前为止,所有的测试只涉及两个表的连接。如果多于两个表,就需要至少两次的hash join,数据分发次数变多,生产者消费者的角色可能互换,执行计划将不可避免变得复杂。执行路径变长,为了保证并行执行的正常进行,执行计划可能会插入相应的阻塞点,在hash join时,把符合join条件的数据缓存到临时表,暂停数据继续分发。本节我使用一个三表连接的sql来说明连续hash join时,不同分发方式的不同行为。
使用Broadcast分发,没有阻塞点。
测试三个表连接的sql如下,加入part表,使用hint让优化器两次hash join都使用broadcast分发。Replicate SQL查询性能类似。
select sum(lo_revenue) from lineorder, customer, part where lo_custkey = c_custkey and lo_partkey = p_partkey;
SQL执行时间为42秒,dbtime为2.6分钟。
AAS=(sql db time)/(sql 执行时间)=(2.6*60)/42=3.7,接近4,说明4个PX进程基本一直保持活跃。
执行计划是一颗完美的右深树,这是星型模型查询时执行计划的典型形式。生产者对两个维度进行broadcast分发,消费者接受数据之后准备好两次hash join的build table, 最后扫描事实表,并进行hash join。我们通过跟随table queue顺序的原则,阅读这个执行计划。
红色PX进程作为生产者并行扫描part,通过tablequeue0广播给每个蓝色的消费者PX进程 (第7~9行)。每个蓝色的PX进程接收part的完整数据(第6行),1.2M行记录,并准备好第5行hash join的build table。
红色PX进程作为生产者并行扫描customer,通过tablequeue1广播broadcast给每个蓝色的 消费者PX进程(第12~14行)。每个蓝色的PX进程接收customer的完整数据(第11行),1.5M行记录,并准备好第10行hash join的build table。
蓝色的PX进程并行扫描事实表lineorder,对每条符合扫描条件(如果sql语句包含对lineorder的过滤条件)的3亿行记录,进行第10行的hash join,对于每一条通过第10行的 hash join的记录,马上进行第5行的hash join,接着再进行聚合。从sql monitor报告的 Timeline列信息,对lineorder的扫描和两个hash join操作是同时进行的。执行计划中没有阻塞点,数据在执行路径上的流动不需要停下来等待。大部分的db cpu消耗在两次hash join操作。最优化的执行计划,意味着经过每个hash join的数据越少越好。对于这类执行计划,你需要确保优化器把最能过滤数据的join,放在最接近事实表的位置执行。
连续hash分发,执行计划出现阻塞点
使用以下hints,强制SQL使用hash分发。
select sum(lo_revenue) from lineorder, customer, part where lo_custkey = c_custkey and lo_partkey = p_partkey;
SQL执行时间为1.5分钟,dbtime为8.1分钟。相对于增加了14GB的IO操作。
连续两次hash join都使用HASH分发,每次hash join左右两边都需要分发,PX进程之间发生4次数据分发。执行计划中最显著的地方来自第12行的HASH JOIN BUFFERED,这是一个阻塞性的操作。下面,我们依然通过跟随table queue顺序的原则,阅读执行计划,并解析为什么出现HASH JOIN BUFFERED这个阻塞操作,而不是一般的HASH JOIN。
1. 蓝色的PX进程作为生产者,并行扫描customer,通过tablequeue0,hash分发给作为消费者的红色PX进程(第14~16行)。每个红色的PX进程接收了1/4的customer的数据(第13行), 大约为370k行记录,并准备好第12行‘HASH JOIN BUFFERED’的build table。与broadcast分发区别的是,此时执行计划是从第16行,扫描靠近lineorder的customer开始的,而不是从第一个没有’孩子’的操作(第9行扫描part)开始的。这是hash分发和串行执行计划以及broadcast分发不同的地方。
2. 蓝色的PX进程作为生产者,并行扫描lineorder,通过tablequeue1,hash分发作为消费者的红色PX进程(第18~20行)。每个红色PX进程接收了1/4的lineorder数据(第17行),大约75M行记录。每个红色PX进程在接收通过tablequeue1接收数据的同时,进行第12行的hash join,并把join的结果集在PGA中作缓存,使数据暂时不要继续往上流动。如果结果集过 大的话,需要把数据暂存到临时空间,比如我们这个例子,用了7GB的临时空间。你可以理解为把join的结果集暂存到一个临时表。那么,为什么执行计划需要在这里插入一个阻塞点,阻止数据继续往上流动呢?
这里涉及生产者消费者模型的核心:同一棵DFO树中,最多只能有两组PX进程,一个数据分发要求两组PX进程协同工作; 这意味着同一时刻,两组PX进程之间,最多只能存在一个活跃的数据分发,一组作为生产者发送数据,一组作为消费者接收数据,每个PX进程只能扮演其中一种角色,不能同时扮演两种角色。当红色的PX进程通过tablequeue1向蓝色的PX进程分发lineorder数据,同时,蓝色的PX进程正在接收lineorder数据,并进行hash join。观察timeline列的时间轴信息,第12,17~20行是同时进行的。 但是此时红色的PX进程不能反过来作为生产者,把hash join的结果分发给蓝色进程,因为此时有两个限制:
• 蓝色的PX进程作为生产者,正忙着扫描lineorder;此时,无法反过来作为消费者,接收来自红色PX进程的数据。
• 第5行hash jon操作的build table还没准备好,这时表part甚至还没被扫描。
所以Oracle需要在第12行hash join这个位置插入一个阻塞点,变成HASH JOIN BUFFER操作,把join的结果集缓存起来。当蓝色的PX进程完成对lineorder的扫描和分发,红色的PX进程完成第12行的hash join并把结果完全暂存到临时空间之后。Tablequeue2的数据分发就开始了。
3. 红色的PX进程作为生产者,并行扫描part,通过tablequeue2,分发给作为消费者的蓝色PX进程(第7~9行)。每个蓝色PX进程接收了1/4的part数据(第6行),大概300k行记录,并准备好第5行hash join的build table。
4. 红色的PX进程作为生产者,把在第12行”HASH JOIN BUFFERED”操作,存在临时空间的对于customer和lineorder连接的结果集,读出来,通过table queue 3,分发给蓝色的PX进程(第11~12行)。“HASH JOIN BUFFERED”这个操作使用了7GB的临时空间,写IO7GB,读IO 7GB,IO总量为 14GB。
5. 每个蓝色的PX进程作为消费者,接收了大约75M行记录。对于通过tablequeue3接收到的 数据,同时进行第5行的hash join,并且通过join操作的数据进行第4行的聚合操作。当tablequeue3上的数据分发结束,每个蓝色的PX进程完成hash join和聚合操作之后,再把各自的聚合结果,一行记录,通过tablequeue4,分发给QC(第3~5行)。QC完成最后的聚合,返回给客户端。
小结
因为使用星型模型测试,这个例子使用Broadcast分发或者replicate才是合理的。实际应用中,连续的hash分发并不一定会出现HASH JOIN BUFFERED这个阻塞点,如果查询涉及的表都较小,一般不会出现HASH JON BUFFERED。即使执行计划中出现BUFFER SORT,HASH JOIN BUFFERED等阻塞操作,也不意味着执行计划不是最优的。如果sql性能不理想,HASH JOIN BUFFERED操作消耗了大部分的CPU和大量临时空间,通过sql monitor报告,你可以判断这是否是合理的:
检查estimated rows和actual rows这两列,确定优化器对hash Join左右两边cardinality估算是否出现偏差,所以选择hash分发。
同样检查hash join操作的estimated rows和actual rows这两列,优化器对hash join结果集cardinality的估算是否合理。优化器会把hash join的两边视为独立事件,对join结果集cardinality的估算可能过于保守,estimate rows偏小。对于星型模型的一种典型情况:如果多个维度表参与连接,执行路径很长,一开始维度表的分发方式为broadcast,事实表不用分发,经过几次join之后,结果集cardinality下降很快,后续hash join两边的estimated rows接近,导致优化器选择hash分发。
通过检查每个join所过滤的数据比例,确定优化器是否把最有效过滤数据的join最先执行,保证在执行路径上流动的数据量最少。
Hash join和布隆过滤
布隆过滤在并行执行计划中的使用非常普遍,我将在本章节解释这一数据结构及其作用。 从11.2版本开始,串行执行的sql也可以使用布隆过滤。
关于布隆过滤
布隆过滤是一种内存数据结构,用于判断某个元素是否属于一个集合。布隆过滤的工作原理图2如下:
引用自维基百科:http://en.wikipedia.org/wiki/Bloom_filter
如图,布隆过滤是一个简单的bit数组,需要定义两个变量:
1. m:数组的大小,这个例子中,m=18.
2. k:hash函数的个数,这个例子中,k=3,
一个空的布隆过滤所有bit都为0。增加一个元素时,该元素需要经过三个hash函数计算, 得到3个hash值,把数组中这三个位置都置为1。集合{x,y,z}的3个元素,分布通过三次hash计算,把数组9个位置设置为1。判断某个元素是否属于一个集合,比如图中的w, 只需对w进行三次hash计算产生三个值,右边的位置在数组中不命中,该位置为0,可以确定,w不在{x,y,z}这个集合。由于存在hash碰撞,布隆过滤的判断会过于乐观(false positive),可能存在元素不属于{x,y,z},但是通过hash计算之后三个位置都命中,被错误认定为属于{x,y,z}。根据集合元素的个数,合理的设置数组大小m,可以把错误判断的几率控制在很小的范围之内。
布隆过滤对hash join性能的改进
布隆过滤的优势在于使用的很少内存,就可以过滤大部分的数据。如果hash join的左边包含过滤条件,优化器可能选择对hash join左边的数据集生成布隆过滤,在扫描hash join右边时使用这个布隆布隆作为过滤条件,第一时间把绝大部分不满足join条件数据排除。减少数据分发和join操作所处理的数据量,提高性能。
使用布隆过滤时的性能
使用布隆过滤时的性能对customer使用c_nation=’CHINA’条件,只计算来自中国地区的客户订单的利润总和。我们观察使用布隆过滤和不使用布隆过滤时性能的差别。
select sum(lo_revenue) from lineorder, customer where lo_custkey = c_custkey and c_nation = 'CHINA';
SQL执行时间为1秒,dbtime为7.9 秒。优化器默认选择replicate的方式。执行计划中多了JOIN FILTER CREATE和JOIN FILTER USE这两个操作。SQL的执行顺序为每个PX进程重复扫描customer表(第7行),对符合c_nation=’CHINA’数据集,60K(240K/4)行记录,在c_custkey列生成布隆过滤:BF0000(第6行JOIN FILTER CREATE)。在扫描lineorder时使用这个布隆过滤(第8行JOIN FILTER USE)。虽然lineorder总行数为300M,sql没有过滤条件,只使用布隆过滤,扫描之后只返回28M行记录,其他272M行记录被过滤掉了。每个PX进程在hash join操作时,只需处理60K行customer记录和7M(28M/4)行lineorder记录的连接,大大降低join操作的成本。对于Exadata,Smart Scan支持布隆过滤卸载到存储节点,存储节点扫描lineorder时,使用布隆过滤排除272M行记录,对于符合条件的数据,把不需要的列也去掉。Cell offload Efficiency=98%,意味着只有30GB的2%从存储节点返回给PX进程。如果不使用布隆过滤,Cell Offload Efficieny不会高达98%,我们将在下个例子看到。对于非Exadata平台,由于没有Smart Scan特性,数据的过滤操作需要由PX进程完成,布隆过滤的效果不会这么明显。12C的新特性Database In-‐memory,支持扫描列式存储的内存数据时,使用布隆过滤。
执行计划中出现第10行对LINEORDER的扫描时,使用了布隆过滤条件:SYS_OP_BLOOM_FILTER(:BF0000,"LO_CUSTKEY")
不使用布隆过滤时的性能
接着,我们通过hint NO_PX_JOIN_FILTER,禁用布隆过滤,观察此时的sql执行性能。
select sum(lo_revenue) from lineorder, customer where lo_custkey = c_custkey and c_nation = 'CHINA';
SQL执行时间为9秒,dbtime为33.7秒。比使用布隆过滤时,性能下降明显。优化器依然选择replicate的方式,执行计划中没有PX JOIN CREATE和PX JOIN USE操作。db time增加为原来4倍的原因:
当PX扫描lineorder时,返回300M行记录。没有布隆过滤作为条件,每个PX进程需要从存储节点接收75M行记录。
进行第5行的hash join操作时,每个PX进程需要连接60k行customer记录和75M行lineorder记录。Join操作的成本大幅增加。
由于没有布隆过滤,Cell Offload Efficiency下降为83%。
HASH分发时布隆过滤的生成,传输,合并与使用
我们通过hint强制使用hash分发,观察此时sql执行计划中布隆过滤的生成和使用。
select sum(lo_revenue) from lineorder, customer where lo_custkey = c_custkey and c_nation = 'CHINA';
此时sql执行时间为4秒,db time为19.4秒。执行计划第6行为JOIN FILTER CREATE; 第13行为JOIN FILTER USE。此例,PX 进程分布在多个RAC两个实例,Hash分发时涉及布隆过滤的生成,传输,合并和使用,较为复杂,具体过程如下:
布隆过滤的产生:4个蓝色的PX进程作为消费者,通过tablequeue0,接收红色的PX进程hash分发的customer数据,每个蓝色的PX进程接收15K行记录。接收customer记录的同时,实例1的两个蓝色PX进程在SGA共同生成一个布隆过滤,假设为B1; 实例2的两个蓝色PX进程在SGA共同生成一个布隆过滤,假设为B2。因为位于SGA中,布隆过滤B1对于实例1的 两个红色的PX进程是可见的,同样,B2对于实例2的两个红色PX进程也是可见的。
布隆过滤的传输:当红色的PX进程完成对hash join左边customer的扫描,就会触发布隆过滤B1/B2的传输。实例1的红色PX进程把B1发给实例2的蓝色PX进程; 实例2的红色PX进程把B2发给实例1的蓝色PX进程。
布隆过滤的合并:实例1的蓝色PX进程合并B1和接收到的B2; 实例2的蓝色PX进程合并B2和接收到的B1。合并之后,实例1和2产生相同布隆过滤。
布隆过滤的使用:实例1和2的4个红色的PX进程作为生产者,并行扫描lineorder时使用 合并之后的布隆过滤进行过滤。Lineorder过滤之后为49M行记录,此时的布隆过滤似乎没有replicate时的有效。Cell Offloadload Efficiency为97%。
如果并行执行只在一个实例,则红色的PX进程不需要对布隆过滤进行传输,蓝色的PX进程也无需对布隆过滤进行合并。
因为hash join的成本大大降低了,对于lineorder 49M行记录的hash分发,成为明显的平均,占53%的db time。
小结
本节阐述了布隆过滤的原理,以及在Oracle中的一个典型应用:对hash join性能的提升。布隆过滤的本质在于把hash join的连接操作提前了,对hash join右边扫描时,就第一时间把不符合join条件的大部分数据过滤掉。大大降低后续数据分发和hash join操作的成本。不同的分布方式,布隆过滤的生成和使用略有不同:
对于broadcast分发和replicate,每个PX进程持有hash join左边的完整数据,对连接键生成一个完整的布隆过滤,扫描hash join右边时使用。如果sql涉及多个维度表,维度表全部使用broadcast分发,优化器可能对不同的维度表数据生成多个的布隆过滤,在扫描事实表时同时使用。
对于hash分发,作为消费者的PX进程接收了hash join左边的数据之后,每个PX进程分别对各自的数据集生成布隆过滤,再广播给作为生产者的每个PX进程,在扫描hash join右边时使用。
真实世界中,优化器会根据统计信息和sql的过滤条件自动选择布隆过滤。通常使用布隆过滤使都会带来性能的提升。某些极端的情况,使用布隆过滤反而造成性能下降,两个场景:
当hash join左边的数据集过大,比如几百万行,而且连接键上的唯一值很多,优化器依然选择使用布隆过滤。生成的布隆过滤过大,无法在CPU cache中完整缓存。那么使用布隆过滤时,对于hash join右边的每一行记录,都需要到内存读取布隆过滤做判断,导致性能问题。
如果Join操作本身无法过滤数据,使用布隆过滤时hash join右边的数据都会命中。优化器可能无法意识到join操作无法过滤数据,依然选择使用布隆布隆。如果hash join右边数据集很大,布隆过滤可能会消耗明显的额外cpu。
并行执行计划中典型的串行点
现实世界中,由于使用不当,并行操作无法并行,或者并行执行计划效率低下,没有获得期望的性能提升。本节举几个典型例子。
在sql中使用rownum,导致出现PX SEND 1 SLAVE操作,所有数据都需要分发到一个PX进,以给每一行记录赋值一个唯一的rownum值,以及BUFFER SORT等阻塞操作。
使用用户自定义的pl/sql函数,函数没有声明为parallel_enable,导致使用这个函数的sql无法并行。
并行DML时,没有enable parallel dml,导致DML操作无法并行。
Rownum,导致并行执行计划效率低下
在’数据倾斜对不同分发方式的影响’小节中,我们新建一个表lineorder_skew把lineorder的lo_custkey列90%的值修改为-1。因为lo_custkey是均匀分布的,我们可以通过对lo_custkey列求模,也可以通过对rownum求模,把90%的数据修改为-1。使用如下的case when语句:
1. case when mod(lo_orderkey, 10) > 0 then -1 else lo_orderkey end lo_orderkey
2. case when mod(rownum, 10) > 0 then -1 else lo_orderkey end lo_orderkey
通过以下的建表sql来测试两种用法时的sql执行性能,并行度为16。
create table lineorder_skew1 parallel 16 as select case when mod(lo_orderkey, 10) > 0 then -1 else lo_orderkey end lo_orderkey, lo_linenumber, lo_custkey, lo_partkey, lo_suppkey, lo_orderdate, lo_orderpriority, lo_shippriority, lo_quantity, lo_extendedprice, lo_ordtotalprice, lo_discount, lo_revenue, lo_supplycost, lo_tax, lo_commitdate, lo_shipmode, lo_status from lineorder;
不使用rownum时,create table执行时间为1分钟,db time为15.1分钟。QC只分配了一组 PX进程,每个蓝色的PX进程以基于数据块地址区间为单位,并行扫描lineorder表,收集统计信息,并加载到lineorder_skew1表。没有数据需要分发,每个PX进程一直保持活跃,这是最有效率的执行路径。
大部分时间,AAS=16。
使用rownum时,create table执行时间为22.3分钟,db time为38.4分钟。SQL的执行时间为使用lo_orderkey时的22倍。
执行计划中出现两组PX进程,PX SEND 1 SLAVE和BUFFER SORT两个操作在之前的测试没有出现过。根据跟随table queue顺序的原则,我们来阅读这个执行计划:
蓝色的PX进程并行扫描lineorder,通过tablequeue0把所有数据分发给一个红色的PX进程 (第10~12行)。因为rownum是一个伪列,为了保证每一行记录拥有一个唯一行号,对所有数据的rownum赋值这个操作只能由一个进程完成,为rownum列赋值成为整个并行执行计划的串行点。这就是出现PX SEND 1 SLAVE操作,性能急剧下降的原因。这个例子中,唯一活跃的红色PX进程为实例1 p008进程。Lineorder的300M行记录都需要发送到实例1 p008进程进行rownum赋值操作,再由这个进程分发给16个蓝色的PX进程进行数据并行插入操作。
实例1 p008进程接收了16个蓝色PX进程分发的数据,给rownum列赋值(第8行count操作)之后,需要通过tablequeue1把数据分发给蓝色的PX进程。但是因为通过tablequeue0的数据分发的还在进行,所以执行计划插入一个阻塞点BUFFER SORT(第7行),把rownum赋值之后的数据缓存到临时空间,大小为31GB。
Tablequeue0的数据分发结束之后,实例1 p008把31GB数据从临时空间读出,通过tablequeue1分发给16个蓝色的PX进程进行统计信息收集和插入操作
红色的PX进程只有实例1 p008是活跃的。消耗了16.7分钟的db time。对于整个执行计划而言,两次数据分发也消耗了大量的db cpu。通过Table queue 0把300M行记录从16个蓝色的PX进程分发给1个红色的 PX 进程。通过Table queue 1把300M行记录从1个红色的PX进程分发给16个蓝色的PX进程。
虽然DoP=16,实际AAS=1.5,意味着执行计划效率低下。
现实世界中,在应用中应该避免使用rownum。Rownum的生成操作会执行计划的串行点,增加无谓的数据分发。对于使用rownum的sql,提升并行度往往不会改善性能,除了修改sql代码,没有其他方法。
自定义PL/SQL函数没有设置parallel_enable,导致无法并行
Rownum会导致并行执行计划出现串行点,而用户自定义的pl/sql函数,如果没有声明为parallel_enable,会导致sql只能串行执行,即使用hint parallel指定sql并行执行。我们来测试一下,创建package pk_test,包含函数f,返回和输入参数一样的值。函数的声明中没有parallel_enable,不支持并行执行。
create or replace package pk_test authid current_user as function f(p_n number) return number; end; / create or replace package body pk_test as function f(p_n number) return number as l_n1 number; begin select 0 into l_n1 from dual; return p_n - l_n1; end; end; /
以下例子中在where语句中使用函数pk_test.f,如果在select列表中使用函数pk_test.f,也会导致执行计划变成串行执行。
select count(*) from customer where c_custkey = pk_test.f(c_custkey);
查询执行时间为54秒,db time也为54秒。虽然我们指定使用Dop=4并行执行,执行计划实际是串行的。
在函数的声明时设置parallel_enable,表明函数支持并行执行,再次执行sql。
create or replace package pk_test authid current_user as function f(p_n number) return number parallel_enable; end; / create or replace package body pk_test as function f(p_n number) return number parallel_enable as l_n1 number; begin select 0 into l_n1 from dual; return p_n - l_n1; end; end; /
此时查询的执行时间为12秒,db time为46.4秒。并行执行如期发生,并行度为4。
除非有特殊的约束,创建自定义pl/sql函数时,都应该声明为parallel_enable。pl/sql函数声明时没有设置parallel_enable导致无法并行是一个常见的问题,我曾在多个客户的系统中遇到。在11g中,这种情况发生时,执行计划中可能会出现PX COORDINATOR FORCED SERIAL操作,这是一个明显的提示; 或者你需要通过sql monitor报告定位这种问题。仅仅通过dbms_xplan。display_cursor检查执行计划是不够的,这种情况执行计划的note部分,还是会显示DoP=4。
并行DML,没有enable parallel dml,导致DML操作无法并行。
这是ETL应用中常见的问题,没有在session级别enable或者force parallel dml,导致dml操作无法并行。使用customer的1.5M行数据演示一下。
建一个空表customer_test:
create table customer_test as select * from customer where 1=0;
我们使用并行直接路径插入的语句作为例子。分别执行两次insert,第一次没有enable parallel dml,insert语句如下:
insert into customer_test select * from customer;
Insert语句执行时间9秒。虽然整个语句的并行度为4,但是执行计划中,第2行直接路径插入操作LOAD AS SELECT是串行执行的。
此时执行计划的Note部分会显示PDML没有启用:
Note ----- - PDML is disabled in current session
启用parallel dml之后,重新执行insert语句。
alter session enable parallel dml;
此时insert语句执行时间为3秒,执行计划中第三行,LOAD AS SELECT操作是可以并行的。
到此,关于“怎么理解Oracle的并行执行”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!