Każdy element na tej liście jest nieprawidłowy.
(Przynajmniej dla Oracle 11gR2 i prawdopodobnie również 10g. Lista może być dokładna dla niektórych przestarzałych wersji Oracle.)
Zalecam korzystanie z oficjalnej dokumentacji Oracle, gdy tylko jest to możliwe, ale rozdział dotyczący wykonywania równoległego nie jest zbyt dokładny.
A nawet jeśli instrukcja się nie myli, często wprowadza w błąd, ponieważ równoległe wykonywanie jest bardzo skomplikowane. Jeśli przejrzysz całą dokumentację, odkryjesz, że istnieje około 30 różnych zmiennych, które określają stopień równoległości. Jeśli kiedykolwiek zobaczysz krótką listę kontrolną elementów, powinieneś być bardzo sceptyczny. Te listy kontrolne są zwykle po prostu najistotniejszymi elementami do rozważenia w bardzo konkretnym kontekście.
Przykład:
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>
Bez podpowiedzi równoległych, bez obiektów równoległych, bez pełnego skanowania tabel, bez skanowania zakresu indeksu obejmującego wiele partycji i podzapytania skalarnego.
Nie spełniony żaden warunek , ale zapytanie nadal używa równoległości. (Zweryfikowałem również v$px_process aby upewnić się, że zapytanie naprawdę używa równoległości i nie jest to tylko niepowodzenie planu wyjaśniania).
Oznacza to, że odpowiedź na Twoje inne pytanie jest błędna.
Nie wiem dokładnie, co się dzieje w takim przypadku, ale myślę, że ma to związek z FAST DUAL optymalizacja. W niektórych kontekstach DUAL nie jest używany jako tabela, więc nie ma nic do zrównoleglania. Jest to prawdopodobnie "błąd", ale jeśli używasz DUAL, to i tak naprawdę nie chcesz równoległości. (Chociaż zakładam, że użyłeś DUAL do celów demonstracyjnych, a twoje prawdziwe zapytanie jest bardziej skomplikowane. Jeśli tak, może być konieczne zaktualizowanie zapytania o bardziej realistyczny przykład.)
