Dina frågor är inte riktigt kompletta. Även om din fråga bara hämtar de första 1000 raderna, hämtar SQL Developer bara de första 50 raderna av dessa 1000 rader. IDE kommer inte att stänga markören förrän du rullar till sista raden. När du har hämtat all data försvinner de parallella processerna. Se till att du ser "Alla rader hämtade:1000 på X sekunder" istället för "hämtade 50 rader på Y sekunder". (Jag önskar att SQL-utvecklaren skulle göra det mer visuellt uppenbart att det finns ytterligare rader som väntar.) Det gör du inte. se det här problemet i SQL*Plus eftersom SQL*Plus alltid tar tag i alla rader.
När endast de första N raderna hämtas är dessa parallella processer "AKTIVA" men gör ingenting. Du bör kunna ignorera dessa sessioner eftersom de inte använder några betydande resurser.
Om du är orolig bara för antalet parallella sessioner, kanske du vill justera dina förväntningar. Jag brukade vara i samma situation som du - att ständigt berätta för användarna att deras (ofullständiga) förfrågningar störde alla parallella sessioner. Så småningom upptäckte jag att det bara var ett problem eftersom jag hade skapat en artificiellt knapp resurs. Oracles parallella processer är vanligtvis lätta, och databaser kan stödja mycket fler parallella processer än de flesta tror att de kan.
Vilka är dina parametervärden för PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU och CPU_COUNT? Titta på standardvärdet för PARALLEL_MAX_SERVERS
. Enligt manualen är standardnumret:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
De flesta DBA:er ser ett maximalt antal parallella trådar i hundra, får panik och minskar sedan det antalet. Och sedan börjar vi skrika åt utvecklare för att de använder en oviktig resurs som var artificiellt begränsad. Istället bör vi vrida tillbaka numret till standardvärdet och bara ignorera slumpmässiga parallella sessioner. Om en användare inte överskrider IO- eller CPU-gränserna bör det inte spela någon roll hur många parallella trådar de använder.
(Med undantag för att förhindra massiv användning av parallell frågesession. Sätt dina användare i en annan profil och ställ in deras SESSIONS_PER_USER till några dussin. Begränsa INTE det till bara 1 eller 2. IDE:er behöver extra sessioner för flera flikar, bakgrundsprocesser som tar upp metadata och felsöksessioner. Om du ställer in gränsen till 2 kommer dina utvecklare inte att kunna använda en IDE ordentligt.)
EDIT (svar på kommentarer)
Jag är inte säker på om du kan läsa mycket om statusen för frågesamordnare . QC gör flera saker, men helst kommer den att vara inaktiv för det mesta medan de parallella sessionerna hanterar det mesta av arbetet.
Med producent/konsumentmodellen kan hälften av de parallella sessionerna ta emot data men egentligen inte göra någonting - som att de bara är minnesstrukturer i vissa operationer. Parallella sessioner kan växla mellan aktiva och inaktiva, eftersom inte alla steg behöver lika många sessioner. Men vi skulle inte vilja att Oracle skulle stänga sessioner i mitten, eftersom de kan behövas senare och vi inte vill slösa tid på att öppna och stänga sessioner.
Det finns dussintals faktorer som påverkar graden av parallellitet, men så vitt jag vet kommer en ökning av PARALLEL_MAX_SERVERS inte att påverka antalet parallella servrar som efterfrågas för ett enskilt uttalande. (Men om uttalandet redan bad om fler servrar än maxvärdet, kan en ökning av parametern påverka antalet tilldelade sessioner).
Det kan kännas som att SQL-satser bara slumpmässigt tar tag i alla parallella sessioner, men i slutändan följer DOP-beräkningar nästan alltid deterministiska regler. Det är bara det att reglerna är så komplicerade att det är svårt att säga hur det fungerar. En vanlig förvirringspunkt är till exempel att när en fråga lägger till sortering eller gruppering fördubblas antalet parallella sessioner.