Each item in is invalid.
(At least for Oracle 11gR2 and probably 10g. The list may be accurate for some older versions of Oracle.)
I recommend using Oracle's official documentation whenever possible, but the parallel execution chapter is not very accurate.
And even if the manual is not wrong, it is often misleading because parallel execution is very difficult. If you look through all the documentation, you will find about 30 different variables that determine the degree of parallelism. If you ever see a short checklist of items, you should be very skeptical. These checklists are usually the most relevant to consider in a very specific context.
Example:
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>
There are no parallel prompts, no parallel objects, full table scans, range index scans covering several sections, and a scalar subquery.
Not a single condition has been met , but the request still uses parallelism. (I also checked v$px_process to make sure the request really uses parallelism, and this is not just a failure of the explanation plan.)
This means that the answer to your other question is incorrect.
I'm not sure what happens in this case, but I think this is due to the optimization of FAST DUAL . In some contexts, DUAL is not used as a table, so there is nothing to parallelize. This is probably a "mistake", but if you use DUAL, you really don't want parallelism anyway. (Although I assume that you used DUAL for demo purposes, and your real query is more complex. If so, you might need to update the query with a more realistic example.)