"Don't trust what you see!"
A cliche in spy movies, this sentence can also have a less impressive interpretation: "Don't be over-excited by any finding!"
I came to believe in this interpretation when I was studying for Oracle SQL Tuning Expert exam.
Going through experiments on using different DOP for INSERT...SELECT statement (a more comprehensive post coming up soon), I came across something which looked like a behavior change between 11.2.0.4 and 12.1.0.2 and -more importantly- seemed to contradict the documentation.
All I heard in my brain was this: "Shit! This is going to put me on the map! OakTable! Here I come!"
I got in touch with Martin Widlake, who was kind enough to go through the results of my experiment, and advised me to publish the results -which I'm extremely grateful for it.
DOP in INSERT..SELECT
Just for clarification, I'd like to rewrite the rule for calculation of DOP in INSERT..SELECT as below:
After the decision to parallelize the
SELECT or INSERT operation is made, one parallel directive is
picked for deciding the DOP of the whole statement, using the following
precedence rule:
1. Insert
hint directive
2. then
Session
3. then
Parallel declaration specification of the inserting table
4. and
then Maximum query directive.
Oracle states: "In this context, maximum query directive means that among multiple tables and indexes, the table or index that has the maximum DOP determines the parallelism for the query operation."
(You can find 11gR2's original documentation here and 12.1.0.2's here.)
But the results of the experiment below in 12.1.0.2 appears to suggest that rule 4 overrides the rule 3, in this version.
Tables:
SQL> CREATE TABLE SOURCE_DATA NOLOGGING PARALLEL 4 AS
SELECT ROWNUM ID , MOD(ROWNUM,5) PART_ID, ROUND(DBMS_RANDOM.VALUE(1,ROWNUM)*5,5) VALUE
FROM DUAL
CONNECT BY LEVEL < 1000001;
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'SOURCE_DATA');
SQL> CREATE TABLE DESTINATION_DATA AS
SELECT * FROM SOURCE_DATA WHERE 1=2;
SELECT ROWNUM ID , MOD(ROWNUM,5) PART_ID, ROUND(DBMS_RANDOM.VALUE(1,ROWNUM)*5,5) VALUE
FROM DUAL
CONNECT BY LEVEL < 1000001;
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'SOURCE_DATA');
SQL> CREATE TABLE DESTINATION_DATA AS
SELECT * FROM SOURCE_DATA WHERE 1=2;
Session:
SQL> ALTER SESSION ENABLE PARALLEL DML;
The experiment
SQL> ALTER TABLE DESTINATION_DATA PARALLEL 3;
As you can see below, there are no hints on the statement, and Parallel DML is merely enabled on he session. We are doing a simple direct-path insert into a table with parallel declaration of 3, and selecting from a table which has a parallel declaration of 4. So based on Oracle documentation we expect the DOP to be 3 (i.e. "Parallel declaration specification of the inserting table") despite the higher DOP on the source table.
Using DBMS_XPLAN.DISPLAY_CURSOR, we get:
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
SQL_ID cwrqam2gbx7ds, child number 0
-------------------------------------
INSERT /*+ append TEST3 */ INTO DESTINATION_DATA SELECT * FROM
SOURCE_DATA
Plan hash value: 2115782672
-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | TQ |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | | | | |
| 1 | PX COORDINATOR | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 1000K| Q1,00 | P->S | QC (RAND) |
| 3 | LOAD AS SELECT (HYBRID TSM/HWMB)| | | Q1,00 | PCWP | |
| 4 | OPTIMIZER STATISTICS GATHERING | | 1000K| Q1,00 | PCWP | |
| 5 | PX BLOCK ITERATOR | | 1000K| Q1,00 | PCWC | |
|* 6 | TABLE ACCESS FULL | SOURCE_DATA | 1000K| Q1,00 | PCWP | |
-----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - access(:Z>=:Z AND :Z<=:Z)
Note
-----
- Degree of Parallelism is 4 because of table property
28 rows selected
-----------------------------------------------------------------------------------------------
SQL_ID cwrqam2gbx7ds, child number 0
-------------------------------------
INSERT /*+ append TEST3 */ INTO DESTINATION_DATA SELECT * FROM
SOURCE_DATA
Plan hash value: 2115782672
-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | TQ |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | | | | |
| 1 | PX COORDINATOR | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 1000K| Q1,00 | P->S | QC (RAND) |
| 3 | LOAD AS SELECT (HYBRID TSM/HWMB)| | | Q1,00 | PCWP | |
| 4 | OPTIMIZER STATISTICS GATHERING | | 1000K| Q1,00 | PCWP | |
| 5 | PX BLOCK ITERATOR | | 1000K| Q1,00 | PCWC | |
|* 6 | TABLE ACCESS FULL | SOURCE_DATA | 1000K| Q1,00 | PCWP | |
-----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - access(:Z>=:Z AND :Z<=:Z)
Note
-----
- Degree of Parallelism is 4 because of table property
28 rows selected
WHAT?! DOP is 4?!
Not so fast though ... #sigh
During the comparison of the behavior between 11g and 12c, I kept checking the V$SQL.PX_SERVERS_EXECUTIONS, mainly because the DBMS_XPLAN.DISPLAY_CURSOR was not giving any hints on the employed DOP.
I hadn't done it for 12.1.0.2 because the output seemed to have enough information in that regard. But Martin Widlake suggested I do the same, to be consistent.
SQL> SELECT sql_id, child_number, PX_SERVERS_EXECUTIONS
FROM v$sql
WHERE sql_text LIKE '%TEST3%';
SQL_ID CHILD_NUMBER PX_SERVERS_EXECUTIONS
------------- ------------ ---------------------
cwrqam2gbx7ds 0 3
FROM v$sql
WHERE sql_text LIKE '%TEST3%';
SQL_ID CHILD_NUMBER PX_SERVERS_EXECUTIONS
------------- ------------ ---------------------
cwrqam2gbx7ds 0 3
There you go! Oracle's documentation was not wrong after all. The DOP is in fact equal to the parallel declaration on the inserting table (i.e. 3).
One last blow came from OEM. You can clearly see the parallel servers involved in the INSERT...SELECT.
Just a note that seeing only one set of parallel servers proves Oracle's statement that when the decision is made to do both INSERT & SELECT in parallel, ONE parallel directive is used to carry out the operation; i.e. both operation use the same DOP.
Conclusion
Don't be deceived by the glamor of the extra information which is presented in 12.1.0.2. DBMS_XPLAN can lie.
Here I have to mention that I had also sought Jonathan Lewis' opinion about the post.
I'd like to quote this from Jonathan's response, when I got back to him to say that I was wrong:
"There's always one more thing to check."
