Hvorfor kan jeg ikke tvinge Oracle 11g til at forbruge flere CPU'er for en enkelt SQL-forespørgsel

Det vigtigste at forstå ved Oracle-parallelisme er, at det er kompliceret. At optimere parallelisme kræver en masse Oracle-viden, læsning af manualerne, kontrol af mange parametre, test af langvarige forespørgsler og en masse skepsis.

Stil de rigtige spørgsmål

Parallelle problemer involverer i virkeligheden tre forskellige spørgsmål:

1. Hvor mange parallelle servere blev der anmodet om?
2. Hvor mange parallelle servere blev tildelt?
3. Hvor mange parallelle servere blev brugt med mening?

Brug de bedste værktøjer

Gå direkte til det bedste værktøj - SQL Monitoring med aktive rapporter. Find dit SQL_ID og generer HTML-rapporten:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; . Dette er den eneste måde at vide, hvor meget tid der blev brugt på hvert trin i udførelsesplanen. Og det vil fortælle dig, hvor meget parallelisme der blev brugt effektivt, og hvor. For eksempel:

En anden god mulighed er type => 'text' . Det har ikke ret meget information, men det er hurtigere at se på og nemmere at dele.

SQL-overvågning inkluderer også den anmodede DOP og den tildelte DOP:

En 100-linjers parallel select kan køre smukt, men så stopper alt med et enkelt trin på grund af en uncached sekvens. Du kan stirre på en forklarende plan, et spor eller en AWR-rapport i timevis og ikke se problemet. Den aktive rapport gør de langsomme trin næsten trivielle at finde. Spild ikke tid på at gætte, hvor problemet ligger.

Der er dog stadig brug for andre værktøjer. En forklaringsplan genereret med explain plan for ... og select * from table(dbms_xplan.display); vil give nogle få vigtige oplysninger. Specifikt Notes afsnittet kan indeholde mange grunde til, at forespørgslen ikke anmodede om parallelitet.

Men HVORFOR fik jeg det antal parallelle servere?

Den relevante information er spredt over flere forskellige manualer, som er meget nyttige, men nogle gange unøjagtige eller vildledende. Der er mange myter og mange dårlige råd om parallelisme. Og teknologien ændrer sig markant med hver udgivelse.

Når du sammensætter alle de velrenommerede kilder, er listen over faktorer, der påvirker antallet af parallelle servere, forbløffende stor. Listen nedenfor er ordnet nogenlunde efter, hvad jeg synes er de vigtigste faktorer:

1. Inter-operation parallelisme Enhver forespørgsel, der bruger sortering eller gruppering, vil allokere dobbelt så mange parallelle servere som DOP. Dette er sandsynligvis ansvarlig for myten "Oracle allocates så mange parallelle servere som muligt!".
2. Forespørgselstip Fortrinsvis et tip på sætningsniveau som /*+ parallel */ , eller muligvis et hint på objektniveau som /*+ noparallel(table1) */ . Hvis et specifikt trin i en plan kører i serie, er det normalt på grund af tip på objektniveau kun på en del af forespørgslen.
3. Rekursiv SQL Nogle operationer kan køre parallelt, men kan effektivt serialiseres af rekursiv SQL. For eksempel en ikke-cachet sekvens på en stor indsats. Rekursiv SQL genereret for at parse sætningen vil også være seriel; for eksempel dynamiske stikprøveforespørgsler.
4. Skift session alter session [force|enable] parallel [query|dml|ddl]; Bemærk, at parallel DML er deaktiveret som standard.
5. Tabelgrad
6. Indeksgrad
7. Indekset var billigere Parallelle hints fortæller kun optimeringsværktøjet at overveje en fuld tabelscanning med en bestemt DOP. De fremtvinger faktisk ikke parallelitet. Optimizeren er stadig gratis at bruge en seriel indeks-adgang, hvis den mener, det er billigere. (Den FULL tip kan hjælpe med at løse dette problem.)
8. Planstyring SQL Plan Baselines, skitser, profiler, avanceret omskrivning og SQL Translators kan alle ændre graden af ​​parallelitet bag din ryg. Tjek afsnittet Note i planen.
9. Udgave Kun Enterprise og Personal Editions tillader parallelle operationer. Bortset fra pakken 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 Dette er den øvre grænse for hele systemet. Der er en afvejning her. At køre for mange parallelle servere på én gang er dårligt for systemet. Men nedgradering af en forespørgsel til seriel kan være katastrofal for nogle forespørgsler.
18. PARALLEL_MIN_PERCENT
19. PARALLEL_MIN_SERVERS
20. PARALLEL_MIN_TIME_THRESHOLD
21. PARALLEL_SERVERS_TARGET
22. PARALLEL_THREADS_PER_CPU
23. Antal RAC-noder Endnu en multiplikator for standard DOP.
24. CPU_COUNT Hvis standard DOP bruges.
25. RECOVERY_PARALLELISM
26. FAST_START_PARALLEL_ROLLBACK
27. Profil SESSIONS_PER_USER begrænser også parallelle servere.
28. Resource Manager
29. Systembelastning Hvis parallel_adaptive_multi_user er sand. Sandsynligvis umuligt at gætte, hvornår Oracle begynder at drosle.
30. PROCESSER
31. Parallelle DML-begrænsninger Parallel DML fungerer ikke, hvis nogen af ​​disse tilfælde:
    1. KOMPATIBEL <9.2 for intra-partition
    2. INDSÆT VÆRDIER, tabeller med udløsere
    3. replikering
    4. selvrefererende integritet eller slet kaskade eller udskudte integritetsbegrænsninger
    5. adgang til en objektkolonne
    6. ikke-partitioneret tabel med LOB
    7. intra-partition parallelisme med en LOB
    8. distribueret transaktion
    9. klyngede tabeller
    10. midlertidige tabeller
32. Skalære underforespørgsler kører ikke parallelt? Dette er i manualen, og jeg ville ønske det var sandt, men mine test viser, at parallelisme virker her i 11g.
33. ENQUEUE_RESOURCES Skjult parameter i 10g, er dette relevant mere?
34. Indeksorganiserede tabeller Kan direkte-sti ikke indsætte til IOT'er parallelt? (Er dette stadig sandt?)
35. Parallelle pipelinede funktionskrav Skal bruge en CURSOR (?). TODO.
36. Funktioner skal være PARALLEL_ENABLE
37. Type erklæring Ældre versioner begrænsede parallelisme på DML afhængigt af partitionering. Nogle af de nuværende manualer indeholder stadig dette, men det er bestemt ikke sandt længere.
38. Antal partitioner Kun for partitionsmæssige joinforbindelser på ældre versioner.(?)
39. Bugs Specifikt har jeg set en masse fejl med parsing. Oracle vil allokere det rigtige antal parallelle servere, men der vil ikke ske noget, da de alle venter på begivenheder som cursor: pin s wait on x .

Denne liste er bestemt ikke komplet og inkluderer ikke 12c-funktioner. Og det løser ikke operativsystem- og hardwareproblemer. Og det besvarer ikke det frygtelig svære spørgsmål, "hvad er den bedste grad af parallelisme?" (Kort svar:mere er normalt bedre, men på bekostning af andre processer.) Forhåbentlig giver det dig i det mindste en fornemmelse af, hvor svære disse problemer kan være, og et godt sted at begynde at lede.