Hvert punkt på listen er forkert.
(I hvert fald for Oracle 11gR2, og sandsynligvis også 10g. Listen kan være nøjagtig for nogle forældede versioner af Oracle.)
Jeg anbefaler at bruge den officielle Oracle-dokumentation, når det er muligt, men kapitlet om parallel udførelse er ikke særlig præcist.
Og selv når manualen ikke er forkert, er den ofte vildledende, fordi parallel udførelse er meget kompliceret. Hvis du gennemgår al dokumentationen, vil du opdage, at der er omkring 30 forskellige variabler, der bestemmer graden af parallelitet. Hvis du nogensinde ser en kort tjekliste over emner, bør du være meget skeptisk. Disse tjeklister er normalt bare de mest relevante punkter at overveje i en meget specifik kontekst.
Eksempel:
SQL> --Create a table without any parallel settings
SQL> create table parallel_test(a number primary key, b number);
Table created.
SQL> --Create some test data
SQL> insert into parallel_test
2 select level, level from dual connect by level <= 100000;
100000 rows created.
SQL> commit;
Commit complete.
SQL> --Force the session to run the query in parallel
SQL> alter session force parallel query;
Session altered.
SQL> --Generate explain plan
SQL> explain plan for
2 select a
3 ,(
4 select a
5 from parallel_test parallel_test2
6 where parallel_test2.a = parallel_test.a
7 )
8 from parallel_test;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3823224058
---------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 116K| 1477K| 9 (0)| 00:00:01 | | | |
|* 1 | INDEX UNIQUE SCAN | SYS_C0028894 | 1 | 13 | 1 (0)| 00:00:01 | | | |
| 2 | PX COORDINATOR | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 116K| 1477K| 9 (0)| 00:00:01 | Q1,00 | P->S | QC (RAND) |
| 4 | PX BLOCK ITERATOR | | 116K| 1477K| 9 (0)| 00:00:01 | Q1,00 | PCWC | |
| 5 | INDEX FAST FULL SCAN| SYS_C0028894 | 116K| 1477K| 9 (0)| 00:00:01 | Q1,00 | PCWP | |
---------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("PARALLEL_TEST2"."A"=:B1)
Note
-----
- dynamic sampling used for this statement (level=2)
21 rows selected.
SQL>
Intet parallelt tip, ingen parallelle objekter, ingen fuld tabelscanninger, ingen indeksområdescanninger, der spænder over flere partitioner og en skalær underforespørgsel.
Ikke en eneste betingelse er opfyldt , men forespørgslen bruger stadig parallelisme. (Jeg har også bekræftet v$px_process for at sikre, at forespørgslen virkelig bruger parallelitet, og det er ikke bare en forklaringsplanfejl.)
Det betyder, at svaret på dit andet spørgsmål er forkert.
Jeg er ikke sikker på præcis, hvad der sker i det tilfælde, men jeg tror, det har at gøre med FAST DUAL optimering. I nogle sammenhænge bruges DUAL ikke som en tabel, så der er ikke noget at parallelisere. Dette er sandsynligvis en "bug", men hvis du bruger DUAL, vil du virkelig ikke have parallelitet alligevel. (Selvom jeg antager, at du brugte DUAL til demonstrationsformål, og din rigtige forespørgsel er mere kompliceret. Hvis det er tilfældet, skal du muligvis opdatere forespørgslen med et mere realistisk eksempel.)