Uw vragen zijn niet echt compleet. Hoewel uw query alleen de eerste 1000 rijen ophaalt, haalt SQL Developer alleen de eerste 50 rijen van die 1000 rijen op. De IDE sluit de cursor pas als u naar de laatste rij scrolt. Zodra u alle gegevens hebt opgehaald, verdwijnen die parallelle processen. Zorg ervoor dat u "Alle rijen opgehaald:1000 in X seconden" ziet in plaats van "" 50 rijen opgehaald in Y seconden". (Ik wou dat SQL Developer het visueel duidelijker zou maken dat er extra rijen wachten.) zie dit probleem in SQL*Plus omdat SQL*Plus altijd alle rijen pakt.
Wanneer alleen de eerste N rijen worden opgehaald, zijn die parallelle processen "ACTIEF" maar doen niets. Je moet in staat zijn om die sessies te negeren omdat ze geen noemenswaardige bronnen gebruiken.
Als je je alleen zorgen maakt over het aantal parallelle sessies, wil je misschien je verwachtingen bijstellen. Ik bevond me vroeger in dezelfde situatie als jij - ik vertelde gebruikers constant dat hun (onvolledige) vragen alle parallelle sessies in beslag namen. Uiteindelijk ontdekte ik dat het alleen een probleem was omdat ik een kunstmatig schaarse hulpbron had gecreëerd. Parallelle processen van Oracle zijn meestal licht van gewicht en databases kunnen veel meer parallelle processen ondersteunen dan de meeste mensen denken.
Wat zijn uw parameterwaarden voor PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU en CPU_COUNT? Kijk naar de standaardwaarde voor PARALLEL_MAX_SERVERS
. Volgens de handleiding is het standaardnummer:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
De meeste DBA's zien een maximum aantal parallelle threads in de honderden, raak in paniek en verlaag dat aantal dan. En dan beginnen we tegen ontwikkelaars te schreeuwen voor het gebruik van een onbelangrijke bron die kunstmatig beperkt was. In plaats daarvan moeten we het nummer terugzetten naar de standaardwaarde en willekeurige parallelle sessies negeren. Als een gebruiker de IO- of CPU-limieten niet overschrijdt, zou het niet moeten uitmaken hoeveel parallelle threads ze gebruiken.
(Met de mogelijke uitzondering van het voorkomen van massale gebruik van parallelle querysessies. Zet uw gebruikers in een ander profiel en stel hun SESSIONS_PER_USER in op enkele tientallen. Beperk het NIET tot slechts 1 of 2. IDE's hebben extra sessies nodig voor meerdere tabbladen, achtergrondprocessen die metagegevens verzamelen en foutopsporingssessies. Als u de limiet instelt op 2, kunnen uw ontwikkelaars een IDE niet correct gebruiken.)
BEWERKEN (reactie op opmerkingen)
Ik weet niet zeker of je veel kunt lezen over de status van de querycoördinator . De QC doet verschillende dingen, maar idealiter zal hij het grootste deel van de tijd inactief zijn, terwijl de parallelle sessies het meeste werk doen.
Met het producer/consumentenmodel kan de helft van de parallelle sessies gegevens ontvangen maar niet echt iets doen - alsof het bij sommige bewerkingen slechts geheugenstructuren zijn. Parallelle sessies kunnen schakelen tussen actief en inactief, omdat niet alle stappen evenveel sessies nodig hebben. Maar we willen niet dat Oracle sessies halverwege sluit, omdat ze later nodig kunnen zijn en we geen tijd willen verspillen aan het openen en sluiten van sessies.
Er zijn tientallen factoren die de mate van parallellisme beïnvloeden, maar voor zover ik weet heeft het verhogen van PARALLEL_MAX_SERVERS geen invloed op het aantal parallelle servers dat wordt aangevraagd voor een enkele instructie. (Maar als de instructie al om meer servers dan het maximum vroeg, kan het verhogen van de parameter het aantal toegewezen sessies beïnvloeden).
Het lijkt misschien alsof SQL-instructies willekeurig alle parallelle sessies overnemen, maar uiteindelijk volgen DOP-berekeningen bijna altijd deterministische regels. Alleen zijn de regels zo ingewikkeld, dat het moeilijk te zeggen is hoe het werkt. Een veelvoorkomend punt van verwarring is bijvoorbeeld dat wanneer een zoekopdracht sortering of groepering toevoegt, het aantal parallelle sessies wordt verdubbeld.