oracle - Por qué se crean sesiones paralelas incluso cuando desactivo DML paralelo y DDL paralelo

oracle11g query-optimization

Question

Tengo una sugerencia PARALELO (a, 8) en una consulta de combinación. Mi servidor tiene 4 cpus con oráculo 11.2.0.3.0 - 64 bits

Mientras ejecutaba la consulta de combinación deshabilité el DDL paralelo y DML -in v $ sesión. Se crearon 8 sesiones.

Mientras ejecutaba la consulta de combinación, habilité el DDL paralelo y DML -in v $ sesión. Se crearon 16 sesiones.

¿Por qué está pasando esto? ¿Hay alguna explicación sobre esto?

Además, noté que si el DDL y el DML paralelos están habilitados

• para PARALELO (a, 2): se crearon un total de 4 sesiones
• para PARALELO (a, 4): se crearon un total de 8 sesiones

• para PARALELO (a, 8): se crearon un total de 16 sesiones

  ALTER SESSION DISABLE PARALLEL QUERY;
  ALTER SESSION DISABLE PARALELO DML;
  ALTER SESSION DISABLE PARALELO DDL;

  MERGE / * + Parallel (a, 8) * / BIGTABLE_1 a USANDO BIGTABLE_2 b ON (a.KEY = b.KEY) CUANDO SE HACE COINCIDIR ENTONCES UPDATE SET a.Value1 = b.value1;

Además, en la documentación 10g, leí esto

El modo predeterminado de una sesión es DESACTIVAR DML PARALELO. Cuando el DML paralelo está desactivado, no se ejecutará DML en paralelo, incluso si se utiliza la sugerencia PARALELO.

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

Gracias por adelantado

Answer 1

Los paralelismos LEER y ESCRIBIR no siempre están unidos.

alter session disable parallel dml; solo desactiva el paralelismo para la parte ESCRIBIR de la declaración. La parte READ aún puede ejecutarse en paralelo. Como se trata de una operación MERGE , la pista paralela solicita paralelismo de lectura y escritura. Además, una sugerencia paralela anula la alter session disable parallel query; , aunque no anula la alter session disable parallel dml; .

El número de servidores paralelos será el doble del grado de paralelismo solicitado para respaldar las operaciones de productores y consumidores , con el fin de utilizar completamente el paralelismo entre operaciones. Las consultas que agrupan u ordenan los resultados utilizarán el doble de subprocesos. En algunos casos, esto puede suceder incluso si no hay GROUP BY explícito u ORDER BY porque algunas operaciones pueden requerir implícitamente un género.

Tablas de muestra

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

Paralelo de lectura y escritura

Tenga en cuenta el PX COORDINATOR para la operación n. ° 1. Cuando ese paso está por encima de MERGE , significa que la escritura se realiza en paralelo.

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 |
------------------------------------------------------

Escritura en serie, lectura paralela

Ahora la operación MERGE está por encima de todas las operaciones PX ... La escritura se realiza en serie, pero la lectura aún se realiza en paralelo.

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 |
------------------------------------------------