Het belangrijkste om te begrijpen over Oracle-parallellisme is dat het ingewikkeld is. Het optimaliseren van parallellisme vereist veel Oracle-kennis, het lezen van de handleidingen, het controleren van veel parameters, het testen van langlopende query's en veel scepsis.
Stel de juiste vragen
Parallelle problemen omvatten eigenlijk drie verschillende vragen:
- Hoeveel parallelle servers zijn aangevraagd?
- Hoeveel parallelle servers zijn toegewezen?
- Hoeveel parallelle servers zijn zinvol gebruikt?
Gebruik de beste tools
Ga direct naar de beste tool - SQL Monitoring met actieve rapportages. Zoek uw SQL_ID en genereer het HTML-rapport:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; . Dit is de enige manier om te weten hoeveel tijd aan elke stap in het uitvoeringsplan is besteed. En het zal u vertellen hoeveel parallellisme effectief werd gebruikt, en waar. Bijvoorbeeld:
Een andere goede optie is type => 'text' . Het bevat niet zoveel informatie, maar het is sneller om naar te kijken en gemakkelijker te delen.
SQL Monitoring omvat ook de gevraagde DOP en de toegewezen DOP:
Een 100-lijns parallelle select kan mooi lopen, maar dan stopt alles bij een enkele stap vanwege een niet-gecachete reeks. U kunt uren staren naar een uitlegplan, een trace of een AWR-rapport zonder het probleem te zien. Het actieve rapport maakt de langzame stappen bijna triviaal om te vinden. Verspil geen tijd met raden waar het probleem ligt.
Er zijn echter nog andere hulpmiddelen nodig. Een uitlegplan gegenereerd met explain plan for ... en select * from table(dbms_xplan.display); zal enkele belangrijke informatie verstrekken. Met name de Notes sectie kan vele redenen bevatten waarom de zoekopdracht niet om parallellisme vroeg.
Maar WAAROM heb ik dat aantal parallelle servers gekregen?
De relevante informatie is verspreid over verschillende handleidingen, die zeer nuttig zijn, maar soms onnauwkeurig of misleidend. Er zijn veel mythen en veel slecht advies over parallellisme. En de technologie verandert aanzienlijk bij elke release.
Als je alle betrouwbare bronnen bij elkaar optelt, is de lijst met factoren die van invloed zijn op het aantal parallelle servers verbazingwekkend groot. De onderstaande lijst is grofweg geordend op wat volgens mij de belangrijkste factoren zijn:
- Inter-operatie parallellisme Elke query die sortering of groepering gebruikt, wijst twee keer zoveel parallelle servers toe als de DOP. Dit is waarschijnlijk verantwoordelijk voor de mythe "Oracle wijst zoveel mogelijk parallelle servers toe!".
- Query-hint Bij voorkeur een hint op instructieniveau zoals
/*+ parallel */, of mogelijk een hint op objectniveau zoals/*+ noparallel(table1) */. Als een specifieke stap van een plan serieel wordt uitgevoerd, is dit meestal vanwege hints op objectniveau op slechts een deel van de query. - Recursieve SQL Sommige bewerkingen kunnen parallel worden uitgevoerd, maar kunnen effectief worden geserialiseerd door recursieve SQL. Bijvoorbeeld een niet-gecachete reeks op een grote insert. Recursieve SQL die wordt gegenereerd om de instructie te ontleden, is ook serieel; bijvoorbeeld dynamische steekproeven.
- Sessie wijzigen
alter session [force|enable] parallel [query|dml|ddl];Merk op dat parallelle DML standaard is uitgeschakeld. - Tafelgraad
- Indexgraad
- Index was goedkoper Parallelle hints vertellen de optimizer alleen om een volledige tabelscan met een bepaalde DOP te overwegen. Ze dwingen niet echt parallellisme af. De optimizer is nog steeds vrij om een seriële index-toegang te gebruiken als hij denkt dat het goedkoper is. (De
FULLhint kan dit probleem helpen oplossen.) - Planbeheer SQL Plan Baselines, contouren, profielen, geavanceerd herschrijven en SQL Translators kunnen allemaal de mate van parallellisme achter uw rug om veranderen. Controleer het gedeelte Opmerking van het abonnement.
- Editie Alleen Enterprise en Personal Editions staan parallelle bewerkingen toe. Behalve het pakket DBMS_PARALLEL_EXECUTE.
- PARALLEL_ADAPTIVE_MULTI_USER
- PARALLEL_AUTOMATIC_TUNING
- PARALLEL_DEGREE_LIMIT
- PARALLEL_DEGREE_POLICY
- PARALLEL_FORCE_LOCAL
- PARALLEL_INSTANCE_GROUP
- PARALLEL_IO_CAP_ENABLED
- PARALLEL_MAX_SERVERS Dit is de bovengrens voor het hele systeem. Er is hier een afweging. Te veel parallelle servers tegelijk draaien is slecht voor het systeem. Maar het downgraden van een zoekopdracht naar serieel kan voor sommige zoekopdrachten rampzalig zijn.
- PARALLEL_MIN_PERCENT
- PARALLEL_MIN_SERVERS
- PARALLEL_MIN_TIME_THRESHOLD
- PARALLEL_SERVERS_TARGET
- PARALLEL_THREADS_PER_CPU
- Aantal RAC-knooppunten Nog een vermenigvuldiger voor standaard DOP.
- CPU_COUNT Als de standaard DOP wordt gebruikt.
- RECOVERY_PARALLELISME
- FAST_START_PARALLEL_ROLLBACK
- Profiel
SESSIONS_PER_USERbeperkt ook parallelle servers. - Bronnenbeheer
- Systeembelasting Als parallel_adaptive_multi_user waar is. Waarschijnlijk onmogelijk te raden wanneer Oracle zal gaan smoren.
- PROCESSEN
- Parallelle DML-beperkingen Parallelle DML werkt niet in een van de volgende gevallen:
- COMPATIBEL <9.2 voor intrapartitie
- VOEG WAARDEN IN, tabellen met triggers
- replicatie
- zelf-referentiële integriteit of cascade- of uitgestelde integriteitsbeperkingen verwijderen
- toegang tot een objectkolom
- niet-gepartitioneerde tabel met LOB
- intrapartitie parallellisme met een LOB
- verdeelde transactie
- geclusterde tabellen
- tijdelijke tabellen
- Scalaire subquery's lopen niet parallel? Dit staat in de handleiding, en ik wou dat dit was waar, maar mijn tests geven aan dat parallellisme hier werkt in 11g.
- ENQUEUE_RESOURCES Verborgen parameter in 10g, is dit meer relevant?
- Index-georganiseerde tabellen Kan het pad niet parallel naar IOT's worden ingevoegd? (Is dit nog steeds waar?)
- Vereisten voor parallelle pijplijnfunctie Moet een
CURSOR. gebruiken (?). TODO. - Functies moeten PARALLEL_ENABLE zijn
- Type verklaring Oudere versies beperkten parallellisme op DML, afhankelijk van de partitionering. Sommige van de huidige handleidingen bevatten dit nog steeds, maar het is zeker niet meer waar.
- Aantal partities Alleen voor partitiegewijze joins op oudere versies.(?)
- Bugs Ik heb met name veel bugs gezien bij het parseren. Oracle zal het juiste aantal parallelle servers toewijzen, maar er gebeurt niets omdat ze allemaal wachten op gebeurtenissen zoals
cursor: pin s wait on x.
Deze lijst is zeker niet compleet en bevat geen 12c-functies. En het lost geen problemen met het besturingssysteem en de hardware op. En het geeft geen antwoord op de verschrikkelijk moeilijke vraag, "wat is de beste mate van parallellisme?" (Kort antwoord:meer is meestal beter, maar dit gaat ten koste van andere processen.) Hopelijk geeft het je in ieder geval een idee van hoe moeilijk deze problemen kunnen zijn, en een goede plek om te beginnen met zoeken.