Varför kan jag inte tvinga Oracle 11g att förbruka fler processorer för en enda SQL-fråga

Det viktigaste att förstå om Oracle-parallellism är att det är komplicerat. Att optimera parallellitet kräver mycket Oracle-kunskap, att läsa manualerna, kontrollera många parametrar, testa långvariga frågor och mycket skepsis.

Ställ rätt frågor

Parallella problem involverar egentligen tre olika frågor:

1. Hur många parallella servrar efterfrågades?
2. Hur många parallella servrar tilldelades?
3. Hur många parallella servrar användes på ett meningsfullt sätt?

Använd de bästa verktygen

Gå direkt till det bästa verktyget - SQL Monitoring med aktiva rapporter. Hitta ditt SQL_ID och generera HTML-rapporten:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; . Detta är det enda sättet att veta hur mycket tid som spenderades på varje steg i genomförandeplanen. Och det kommer att berätta hur mycket parallellitet som användes effektivt och var. Till exempel:

Ett annat bra alternativ är type => 'text' . Den har inte lika mycket information men den är snabbare att titta på och lättare att dela.

SQL-övervakning inkluderar även den begärda DOP och den tilldelade DOP:

En 100-rads parallell select kan springa vackert, men sedan stannar allt i ett enda steg på grund av en uncachad sekvens. Du kan stirra på en förklarande plan, ett spår eller en AWR-rapport i timmar och inte se problemet. Den aktiva rapporten gör de långsamma stegen nästan triviala att hitta. Slösa inte tid på att gissa var problemet ligger.

Men det krävs fortfarande andra verktyg. En förklaringsplan genererad med explain plan for ... och select * from table(dbms_xplan.display); kommer att ge några viktiga delar av information. Närmare bestämt Notes avsnittet kan innehålla många anledningar till varför frågan inte begärde parallellitet.

Men VARFÖR fick jag så många parallella servrar?

Den relevanta informationen är spridd över flera olika manualer, som är mycket användbara men ibland felaktiga eller vilseledande. Det finns många myter och många dåliga råd om parallellism. Och tekniken förändras avsevärt med varje release.

När du sätter ihop alla välrenommerade källor är listan över faktorer som påverkar antalet parallella servrar häpnadsväckande stor. Listan nedan är ordnad ungefär efter vad jag tycker är de viktigaste faktorerna:

1. Interoperation parallellism Varje fråga som använder sortering eller gruppering kommer att allokera dubbelt så många parallella servrar som DOP. Detta är förmodligen ansvarigt för myten "Oracle allocerar så många parallella servrar som möjligt!".
2. Frågetips Helst en ledtråd på satsnivå som /*+ parallel */ , eller möjligen en ledtråd på objektnivå som /*+ noparallel(table1) */ . Om ett specifikt steg i en plan körs i serie är det vanligtvis på grund av tips på objektnivå på endast en del av frågan.
3. Rekursiv SQL Vissa operationer kan köras parallellt men kan effektivt serialiseras med rekursiv SQL. Till exempel en uncachad sekvens på en stor infogning. Rekursiv SQL som genereras för att analysera satsen kommer också att vara seriell; till exempel dynamiska samplingsfrågor.
4. Ändra session alter session [force|enable] parallel [query|dml|ddl]; Observera att parallell DML är inaktiverat som standard.
5. Tabellgrad
6. Indexgrad
7. Indexet var billigare Parallella tips talar bara om för optimeraren att överväga en genomsökning av en hel tabell med en viss DOP. De framtvingar faktiskt inte parallellism. Optimeraren är fortfarande gratis att använda en seriell index-åtkomst om den tror att det är billigare. (Den FULL tips kan hjälpa till att lösa det här problemet.)
8. Planhantering SQL Plan Baselines, konturer, profiler, avancerad omskrivning och SQL Translators kan alla ändra graden av parallellitet bakom din rygg. Kontrollera avsnittet Notera i planen.
9. Utgåva Endast Enterprise och Personal Edition tillåter parallella operationer. Förutom paketet 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 Detta är den övre gränsen för hela systemet. Det finns en avvägning här. Att köra för många parallella servrar samtidigt är dåligt för systemet. Men att nedgradera en fråga till seriell kan vara katastrofalt för vissa frågor.
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 Ytterligare en multiplikator för standard DOP.
24. CPU_COUNT Om standard DOP används.
25. RECOVERY_PARALLELISM
26. FAST_START_PARALLEL_ROLLBACK
27. Profil SESSIONS_PER_USER begränsar också parallella servrar.
28. Resurshanterare
29. Systembelastning Om parallell_adaptive_multi_user är sant. Förmodligen omöjligt att gissa när Oracle kommer att börja strypa.
30. PROCESSER
31. Parallella DML-begränsningar Parallell DML fungerar inte om något av dessa fall:
    1. KOMPATIBEL <9.2 för intra-partition
    2. INFOGA VÄRDEN, tabeller med utlösare
    3. replikering
    4. självrefererande integritet eller ta bort kaskad eller uppskjutna integritetsbegränsningar
    5. åtkomst till en objektkolumn
    6. icke-partitionerad tabell med LOB
    7. intra-partition parallellism med en LOB
    8. distribuerad transaktion
    9. klustrade tabeller
    10. tillfälliga tabeller
32. Skalära underfrågor körs inte parallellt? Det här finns i manualen och jag önskar att det var sant, men mina tester visar att parallellism fungerar här i 11g.
33. ENQUEUE_RESOURCES Dold parameter i 10g, är detta relevant längre?
34. Indexorganiserade tabeller Kan inte direkt-path infoga till IOTs parallellt? (Är detta fortfarande sant?)
35. Parallell pipelined funktionskrav Måste använda en CURSOR (?). ATT GÖRA.
36. Funktioner måste vara PARALLEL_ENABLE
37. Typ av uttalande Äldre versioner begränsade parallellism på DML beroende på partitionering. Vissa av de nuvarande manualerna innehåller fortfarande detta men det är verkligen inte sant längre.
38. Antal partitioner Endast för partitionsmässiga kopplingar på äldre versioner.(?)
39. Buggar Specifikt har jag sett många buggar med analys. Oracle kommer att allokera rätt antal parallella servrar men ingenting kommer att hända eftersom de alla väntar på händelser som cursor: pin s wait on x .

Den här listan är verkligen inte komplett och inkluderar inte 12c-funktioner. Och det tar inte upp operativsystem- och maskinvaruproblem. Och det svarar inte på den fruktansvärt svåra frågan, "vilken är den bästa graden av parallellism?" (Kort svar:mer är vanligtvis bättre, men på bekostnad av andra processer.) Förhoppningsvis ger det dig åtminstone en känsla av hur svåra dessa problem kan vara, och ett bra ställe att börja leta.