Constraints 约束操作不能并行 validate耗时几个小时

GOAL

NOTE: In the images and/or the document content below, the user information and environment data used represents fictitious data from the Oracle sample or bulit-in schema(s), Public Documentation delivered with an Oracle database product or other training material.  Any similarity to actual environments, actual persons, living or dead, is purely coincidental and not intended in any manner.

You want to create the PRIMARY KEY constraint while specifying the name and storage clause for the underlying INDEX in PARALLEL. You used the following compound statement:

SQL> ALTER SESSION ENABLE PARALLEL DDL;
SQL> ALTER TABLE emp ADD CONSTRAINT P_EMP PRIMARY KEY (empno)
USING INDEX (CREATE UNIQUE INDEX I_EMP ON
emp (empno) PARALLEL) ;
SQL> ALTER SESSION DISABLE PARALLEL DDL;

and you find that the execution time takes long time, while creating the index in parallel alone and enabling the constraint only takes much less time.
SQL> ALTER SESSION ENABLE PARALLEL DDL;
SQL> CREATE UNIQUE INDEX I_EMP ON  emp(empno) PARALLEL;
SQL> ALTER TABLE emp ADD CONSTRAINT P_EMP PRIMARY KEY (empno) USING INDEX I_EMP;
SQL> ALTER SESSION DISABLE PARALLEL DDL;

You want to know why this takes place.

Can We Enable or Modify Constraints Using Parallelism?

SOLUTION
 

Enabling or disabling or modifying the constraints cannot be run in parallelism.
As per Oracle Documentation, only the following DDL operations are supported in Parallelism.

The parallel DDL statements for non-partitioned tables and indexes are:

CREATE INDEX
CREATE TABLE AS SELECT
ALTER TABLE MOVE
ALTER INDEX REBUILD

The parallel DDL statements for partitioned tables and indexes are:

CREATE INDEX
CREATE TABLE AS SELECT
ALTER TABLE {MOVE|SPLIT|COALESCE} PARTITION
ALTER INDEX {REBUILD|SPLIT} PARTITION

Since 19.16.0.0.220719 applied, parallel DML is disabled with following message shown in Execution plan note.

"PDML disabled because parent referential constraints are present"

(delete statement and update statements if it modifies a column referenced in a foreign key constraint) disabled because parent

referential constraints are present but not before

Prior to 19.16.0.0.220719 PDML was working as expected.
 

CHANGES

 Patch level 19.16.0.0.220719 applied.

CAUSE

 New restriction is introduced by fix for Bug 32078078 

parallel PDML is disabled on referential integrity tables if the operation
modifies a primary or foreign key column

SOLUTION

Run the dml serially 

or

disable the FK constraint before parallel dml,  then enable when complete.

Parallel DML (PDML) must be explicitly enabled in order for DML to be considered for parallel execution.  In RDBMS versions lower than 12c, you could accomplish this only at the session level by using an ALTER SESSION statement. Assuming restrictions on parallel DML do not apply to your situation, once the session is altered, all further statements in the session will be candidates for execution of DML in parallel.

ALTER SESSION ENABLE PARALLEL DML;
<execute DML statement> 

SOLUTION

NOTE: In the images and/or the document content below, the user information and data used represents fictitious
data from the Oracle sample schema(s) or Public Documentation delivered with an Oracle database product.  
Any similarity to actual persons, living or dead, is purely coincidental and not intended in any manner.

New Hint in 12c: ENABLE_PARALLEL_DML

Starting in 12c, there is a new hint that will let you enable PDML at the statement level: ENABLE_PARALLEL_DML

/*+ enable_parallel_dml parallel(x) */  -- (x) is optional, where x is the requested degree of parallelism

Example 1: PDML is disabled

In this example, the select will run in parallel, but the load will be done serially because PDML is not explicitly enabled.  In 12c, the explain plan will include the reason that PDML was not considered.

insert /*+ parallel */ into t1 select * from t1_staging;

Execution Plan

----------------------------------------------------------
| Id | Operation                          | Name         | 
----------------------------------------------------------
| 0 | INSERT STATEMENT                    |              |
| 1 |  LOAD TABLE CONVENTIONAL            | T1           | <---- LOAD is not under a PX COORDINATOR, so PDML is disabled
| 2 |   PX COORDINATOR                    |              |
| 3 |    PX SEND QC (RANDOM)              | :TQ10000     |
| 4 |     PX BLOCK ITERATOR               |              |
| 5 |      TABLE ACCESS FULL              | <TABLE1>     |
----------------------------------------------------------------------

Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- automatic DOP: Computed Degree of Parallelism is 2
- PDML is disabled in current session   <------

 

Example 2: PDML is enabled

In this example, we see both the select and load are done in parallel.

insert /*+ parallel(8) enable_parallel_dml */ into t1 select * from t1_staging;

----------------------------------------------------------
| Id | Operation                         | Name          | 
----------------------------------------------------------
| 0 | INSERT STATEMENT                   |               |
| 1 |  PX COORDINATOR                    |               |
| 2 |   PX SEND QC (RANDOM)              | :TQ10000      |
| 3 |    LOAD AS SELECT (HYBRID TSM/HWMB)| T1            | <---- LOAD is under a PX COORDINATOR, so PDML is enabled
| 4 |     OPTIMIZER STATISTICS GATHERING |               |
| 5 |      PX BLOCK ITERATOR             |               |
| 6 |       TABLE ACCESS FULL            | <TABLE1>      |
----------------------------------------------------------

Note
-----
- dynamic statistics used: dynamic sampling (level=2)
- - Degree of Parallelism is 8 because of hint

Notes:
1. The "enable_parallel_dml" hint may occur in any order within the /*+  */ delimiters.
2. The hint "disable_parallel_dml" is also new in 12c and disables PDML at the statement level. 
3. This hint is not yet included in the 12.1 documentation.