Oracle:има ли някаква логическа причина да не се използва паралелно изпълнение с подзаявки в списъка SELECT?

Всеки елемент в този списък е грешен.

(Поне за Oracle 11gR2 и вероятно 10g също. Списъкът може да е точен за някои остарели версии на Oracle.)

Препоръчвам да използвате официалната документация на Oracle, когато е възможно, но главата за паралелно изпълнение не е много точна.

И дори когато ръководството не е грешно, то често е подвеждащо, защото паралелното изпълнение е много сложно. Ако преминете през цялата документация, ще откриете, че има около 30 различни променливи, които определят степента на паралелизъм. Ако някога видите кратък списък с елементи, трябва да сте много скептични. Тези контролни списъци обикновено са само най-подходящите елементи, които трябва да се вземат предвид в много специфичен контекст.

Пример:

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>

Без паралелен намек, без паралелни обекти, без сканиране на пълни таблици, без сканиране на диапазон на индекс, обхващащ множество дялове, и скаларна подзаявка.

Не е изпълнено нито едно условие , но заявката все още използва паралелизъм. (Проверих също v$px_process за да се уверите, че заявката наистина използва паралелизъм и не е просто обяснение на провал на плана.)

Това означава, че отговорът на другия ви въпрос е грешен.

Не съм сигурен какво точно се случва в този случай, но мисля, че е свързано с FAST DUAL оптимизация. В някои контексти DUAL не се използва като таблица, така че няма какво да се паралелизира. Това вероятно е "бъг", но ако използвате DUAL, тогава наистина не искате паралелизъм. (Въпреки че предполагам, че сте използвали DUAL за демонстрационни цели и истинската ви заявка е по-сложна. Ако е така, може да се наложи да актуализирате заявката с по-реалистичен пример.)