Todos os itens dessa lista estão errados.
(Pelo menos para Oracle 11gR2, e provavelmente 10g também. A lista pode ser precisa para algumas versões obsoletas do Oracle.)
Recomendo usar a documentação oficial da Oracle sempre que possível, mas o capítulo de execução paralela não é muito preciso.
E mesmo quando o manual não está errado, muitas vezes é enganoso, porque a execução paralela é muito complicada. Se você passar por toda a documentação, descobrirá que existem cerca de 30 variáveis diferentes que determinam o grau de paralelismo. Se você vir uma pequena lista de verificação de itens, deve ser muito cético. Essas listas de verificação geralmente são apenas os itens mais relevantes a serem considerados em um contexto muito específico.
Exemplo:
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>
Nenhuma dica paralela, nenhum objeto paralelo, nenhuma varredura de tabela completa, nenhuma varredura de intervalo de índice abrangendo várias partições e uma subconsulta escalar.
Nenhuma condição foi atendida , mas a consulta ainda usa paralelismo. (Também verifiquei
v$px_process para garantir que a consulta realmente use paralelismo e não seja apenas uma falha no plano de explicação.) Isso significa que a resposta para sua outra pergunta está errada.
Não sei exatamente o que está acontecendo nesse caso, mas acho que tem a ver com o
FAST DUAL otimização. Em alguns contextos, DUAL não é usado como uma tabela, então não há nada para paralelizar. Este é provavelmente um "bug", mas se você estiver usando DUAL, então você realmente não quer paralelismo de qualquer maneira. (Embora eu suponha que você tenha usado DUAL para fins de demonstração e sua consulta real seja mais complicada. Nesse caso, talvez seja necessário atualizar a consulta com um exemplo mais realista.) 
