Proč se mi nedaří přinutit Oracle 11g spotřebovat více CPU na jeden SQL dotaz

Nejdůležitější věcí k pochopení paralelismu Oracle je, že je komplikovaný. Optimalizace paralelismu vyžaduje hodně znalostí Oracle, čtení manuálů, kontrolu mnoha parametrů, testování dlouhotrvajících dotazů a hodně skepticismu.

Klaďte správné otázky

Paralelní problémy ve skutečnosti zahrnují tři různé otázky:

1. Kolik paralelních serverů bylo požadováno?
2. Kolik paralelních serverů bylo přiděleno?
3. Kolik paralelních serverů bylo smysluplně použito?

Používejte nejlepší nástroje

Přejděte přímo na nejlepší nástroj - SQL Monitoring s aktivními sestavami. Najděte své SQL_ID a vygenerujte zprávu HTML:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; . Toto je jediný způsob, jak zjistit, kolik času bylo vynaloženo na každý krok v prováděcím plánu. A řekne vám, kolik paralelismu bylo efektivně použito a kde. Například:

Další dobrou možností je type => 'text' . Neobsahuje tolik informací, ale je rychlejší na prohlížení a snazší sdílení.

SQL Monitoring také zahrnuje požadované DOP a přidělené DOP:

100řádkový paralelní select může běžet krásně, ale pak se vše zastaví v jediném kroku kvůli neuložené sekvenci. Můžete se hodiny dívat na plán vysvětlení, trasování nebo zprávu AWR a nevidíte problém. Díky aktivní zprávě je hledání pomalých kroků téměř triviální. Neztrácejte čas hádáním, kde je problém.

Stále jsou však zapotřebí další nástroje. Plán vysvětlení vygenerovaný pomocí explain plan for ... a select * from table(dbms_xplan.display); poskytne několik klíčových informací. Konkrétně Notes sekce může obsahovat mnoho důvodů, proč dotaz nevyžadoval paralelismus.

Ale PROČ jsem získal takový počet paralelních serverů?

Relevantní informace jsou rozmístěny v několika různých příručkách, které jsou velmi užitečné, ale občas nepřesné nebo zavádějící. Existuje mnoho mýtů a mnoho špatných rad o paralelismu. A technologie se výrazně mění s každým vydáním.

Když dáte dohromady všechny renomované zdroje, seznam faktorů ovlivňujících počet paralelních serverů je překvapivě velký. Níže uvedený seznam je seřazen zhruba podle toho, co považuji za nejdůležitější:

1. Paralelismus mezi operacemi Jakýkoli dotaz využívající řazení nebo seskupování přidělí dvakrát více paralelních serverů než DOP. To je pravděpodobně zodpovědné za mýtus „Oracle přiděluje co nejvíce paralelních serverů!“.
2. Nápověda k dotazu Nejlépe nápověda na úrovni příkazu jako /*+ parallel */ , nebo možná nápověda na úrovni objektu jako /*+ noparallel(table1) */ . Pokud konkrétní krok plánu běží sériově, je to obvykle kvůli nápovědám na úrovni objektu pouze v části dotazu.
3. Rekurzivní SQL Některé operace mohou běžet paralelně, ale lze je efektivně serializovat pomocí rekurzivního SQL. Například neuložená sekvence na velkém insertu. Rekurzivní SQL generovaný k analýze příkazu bude také sériový; například dynamické vzorkovací dotazy.
4. Změnit relaci alter session [force|enable] parallel [query|dml|ddl]; Všimněte si, že paralelní DML je ve výchozím nastavení zakázáno.
5. Stupeň tabulky
6. Stupeň indexu
7. Index byl levnější Paralelní rady pouze sdělují optimalizátoru, aby zvážil úplné prohledání tabulky s určitým DOP. Ve skutečnosti nevynucují paralelismus. Optimalizátor může stále volně používat sériový přístup k indexu, pokud si myslí, že je to levnější. (FULL nápověda může pomoci vyřešit tento problém.)
8. Správa plánu Základní linie plánu SQL, obrysy, profily, pokročilé přepisování a překladače SQL – to vše může změnit stupeň paralelismu za vašimi zády. Podívejte se do části Poznámka v plánu.
9. Vydání Pouze verze Enterprise a Personal Edition umožňují paralelní operace. Kromě balíčku DBMS_PARALLEL_EXECUTE.
10. PARALLEL_ADAPTIVE_MULTI_USER
11. PARALLEL_AUTOMATIC_TUNING
12. PARALLEL_DEGREE_LIMIT
13. PARALLEL_DEGREE_POLICY
14. PARALLEL_FORCE_LOCAL
15. PARALLEL_INSTANCE_GROUP
16. PARALLEL_IO_CAP_ENABLED
17. PARALLEL_MAX_SERVERS To je horní hranice pro celý systém. Je tu kompromis. Provozování příliš mnoha paralelních serverů najednou je pro systém špatné. Ale downgrade dotazu na sériový může být pro některé dotazy katastrofální.
18. PARALLEL_MIN_PERCENT
19. PARALLEL_MIN_SERVERS
20. PARALLEL_MIN_TIME_THRESHOLD
21. PARALLEL_SERVERS_TARGET
22. PARALLEL_THREADS_PER_CPU
23. Počet uzlů RAC Další multiplikátor pro výchozí DOP.
24. CPU_COUNT Pokud je použit výchozí DOP.
25. RECOVERY_PARALLELISMUS
26. FAST_START_PARALLEL_ROLLBACK
27. Profil SESSIONS_PER_USER také omezuje paralelní servery.
28. Správce zdrojů
29. Zatížení systému Pokud má parallel_adaptive_multi_user hodnotu true. Pravděpodobně je nemožné odhadnout, kdy Oracle začne utlumovat.
30. PROCESY
31. Paralelní omezení DML Paralelní DML nebude fungovat, pokud některý z těchto případů:
    1. KOMPATIBILNÍ <9.2 pro vnitřní oddíl
    2. VLOŽTE HODNOTY, tabulky se spouštěči
    3. replikace
    4. samostatná referenční integrita nebo odstranění kaskádových nebo odložených omezení integrity
    5. Přístup ke sloupci objektu
    6. nerozdělená tabulka s LOB
    7. paralelismus uvnitř oddílu s LOB
    8. distribuovaná transakce
    9. seskupené tabulky
    10. dočasné tabulky
32. Skalární dílčí dotazy neběží paralelně? Toto je v příručce a přál bych si, aby to bylo pravda, ale moje testy naznačují, že paralelismus zde funguje v 11g.
33. ENQUEUE_RESOURCES Skrytý parametr v 10g, je to ještě relevantní?
34. Tabulky uspořádané podle indexů Nelze paralelně vkládat přímou cestu k IOT? (Je to stále pravda?)
35. Požadavky na paralelní zřetězené funkce Je nutné použít CURSOR (?). TODO.
36. Funkce musí být PARALLEL_ENABLE
37. Typ výpisu Starší verze omezovaly paralelismus na DML v závislosti na rozdělení. Některé ze současných příruček to stále obsahují, ale už to rozhodně není pravda.
38. Počet oddílů Pouze pro připojení po oddílech na starších verzích.(?)
39. Chyby Konkrétně jsem viděl spoustu chyb při analýze. Oracle přidělí správný počet paralelních serverů, ale nic se nestane, protože všechny čekají na události jako cursor: pin s wait on x .

Tento seznam rozhodně není úplný a neobsahuje funkce 12c. A neřeší problémy s operačním systémem a hardwarem. A neodpovídá na strašně obtížnou otázku, "jaký je nejlepší stupeň paralelismu?" (Krátká odpověď:více je obvykle lepší, ale na úkor jiných procesů.) Doufejme, že vám to alespoň poskytne představu o tom, jak obtížné tyto problémy mohou být, a dobré místo, kde začít hledat.