oracle - 为什么即使禁用并行 DML 和并行 DDL 也会创建并行 session

Question

我在合并查询中有一个 PARALLEL(a,8) 提示。我的服务器有 4 个 CPU 和 oracle 11.2.0.3.0 - 64 位

执行合并查询时我 已禁用 并行 DDL 和 DML
-in v$session 创建了 8 个 session 。

执行合并查询时我 启用 并行 DDL 和 DML
-in v$session 创建了 16 个 session 。

为什么会这样？对此有什么解释吗？

另外，我注意到如果启用了并行 DDL 和 DML

对于 PARALLEL(a,2) :总共创建了 4 个 session

对于 PARALLEL(a,4) :总共创建了 8 个 session

对于 PARALLEL(a,8) :总共创建了 16 个 session

更改 session 禁用并行查询；
更改 session 禁用并行 DML；
更改 session 禁用并行 DDL；

合并/*+ Parallel(a,8) */BIGTABLE_1 a
使用 BIGTABLE_2 b
开(a.KEY = b.KEY)
匹配后更新
SET a.Value1 = b.value1;

此外，在 10g 文档中，我阅读了这个

The default mode of a session is DISABLE PARALLEL DML. When parallel DML is disabled, no DML will be executed in parallel even if the PARALLEL hint is used.

https://docs.oracle.com/cd/B19306_01/server.102/b14223/usingpe.htm#CACCBEJC

提前致谢

Answer 1

READ 和 WRITE 并行性并不总是联系在一起。
alter session disable parallel dml;仅禁用语句的 WRITE 部分的并行性。 READ 部分可能仍会并行运行。因为这是一个 MERGE操作，并行提示请求读取和写入并行性。此外，并行提示覆盖 alter session disable parallel query; ，即使它没有覆盖 alter session disable parallel dml; .

并行服务器的数量将是所请求的并行度的两倍以支持 producer and consumer operations ，以充分利用互操作并行性。对结果进行分组或排序的查询将使用两倍的线程。在某些情况下，即使没有明确的 GROUP BY 也可能发生这种情况。或 ORDER BY因为某些操作可能隐含地需要排序。

sample 表

create table bigtable_1(key number, value1 number);
create table bigtable_2(key number, value1 number);

并行读写

请注意 PX COORDINATOR用于操作 #1。当该步骤高于 MERGE这意味着写作是并行完成的。

rollback;
alter session enable parallel dml;
alter session enable parallel query;
explain plan for merge /*+ parallel(a,8) */ into bigtable_1 a using bigtable_2 b
  on (a.key = b.key) when matched then update set a.value1 = b.value1;
select * from table(dbms_xplan.display(format => 'basic'));

Plan hash value: 827272579

------------------------------------------------------
| Id  | Operation                       | Name       |
------------------------------------------------------
|   0 | MERGE STATEMENT                 |            |
|   1 |  PX COORDINATOR                 |            |  <-- PARALLEL WRITE
|   2 |   PX SEND QC (RANDOM)           | :TQ10003   |
|   3 |    MERGE                        | BIGTABLE_1 |
|   4 |     PX RECEIVE                  |            |  <-- PARALLEL READ
|   5 |      PX SEND HYBRID (ROWID PKEY)| :TQ10002   |
|   6 |       VIEW                      |            |
|   7 |        HASH JOIN BUFFERED       |            |
|   8 |         BUFFER SORT             |            |
|   9 |          PX RECEIVE             |            |
|  10 |           PX SEND HASH          | :TQ10000   |
|  11 |            TABLE ACCESS FULL    | BIGTABLE_2 |
|  12 |         PX RECEIVE              |            |
|  13 |          PX SEND HASH           | :TQ10001   |
|  14 |           PX BLOCK ITERATOR     |            |
|  15 |            TABLE ACCESS FULL    | BIGTABLE_1 |
------------------------------------------------------

串行写入，并行读取

现在 MERGE操作最重要 PX ...操作。写入是串行完成的，但读取仍然是并行完成的。

rollback;
alter session disable parallel dml;
alter session disable parallel query;
explain plan for merge /*+ parallel(a,8) */ into bigtable_1 a using bigtable_2 b
  on (a.key = b.key) when matched then update set a.value1 = b.value1;
select * from table(dbms_xplan.display(format => 'basic'));

Plan hash value: 1648019208

------------------------------------------------
| Id  | Operation                 | Name       |
------------------------------------------------
|   0 | MERGE STATEMENT           |            |
|   1 |  MERGE                    | BIGTABLE_1 |  <-- SERIAL WRITE
|   2 |   PX COORDINATOR          |            |  <-- PARALLEL READ
|   3 |    PX SEND QC (RANDOM)    | :TQ10002   |
|   4 |     VIEW                  |            |
|   5 |      HASH JOIN BUFFERED   |            |
|   6 |       BUFFER SORT         |            |
|   7 |        PX RECEIVE         |            |
|   8 |         PX SEND HASH      | :TQ10000   |
|   9 |          TABLE ACCESS FULL| BIGTABLE_2 |
|  10 |       PX RECEIVE          |            |
|  11 |        PX SEND HASH       | :TQ10001   |
|  12 |         PX BLOCK ITERATOR |            |
|  13 |          TABLE ACCESS FULL| BIGTABLE_1 |
------------------------------------------------