Dine forespørgsler er ikke rigtig udfyldende. Selvom din forespørgsel kun henter de første 1000 rækker, henter SQL Developer kun de første 50 rækker af disse 1000 rækker. IDE'en lukker ikke markøren, før du ruller til den sidste række. Når du har hentet alle data, forsvinder disse parallelle processer. Sørg for, at du ser "Alle rækker hentet:1000 på X sekunder" i stedet for ""Hentet 50 rækker på Y sekunder". (Jeg ville ønske, at SQL-udvikler ville gøre det mere visuelt indlysende, at der er flere rækker, der venter.) Du vil ikke se dette problem i SQL*Plus, fordi SQL*Plus altid griber alle rækkerne.
Når kun de første N rækker hentes, er disse parallelle processer "AKTIVE", men de gør ikke noget. Du bør være i stand til at ignorere disse sessioner, da de ikke bruger nogen væsentlige ressourcer.
Hvis du bare er bekymret for antallet af parallelle sessioner, vil du måske justere dine forventninger. Jeg plejede at være i samme situation som dig - konstant at fortælle brugerne, at deres (ufuldstændige) forespørgsler tvang alle de parallelle sessioner. Til sidst opdagede jeg, at det kun var et problem, fordi jeg havde skabt en kunstigt knap ressource. Oracle parallelle processer er normalt lette, og databaser kan understøtte langt flere parallelle processer, end de fleste tror, de kan.
Hvad er dine parameterværdier for PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU og CPU_COUNT? Se på standardværdien for PARALLEL_MAX_SERVERS
. Ifølge manualen er standardnummeret:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
De fleste DBA'er ser et maksimalt antal parallelle tråde i hundredvis, panik, og sænk derefter dette antal. Og så begynder vi at råbe af udviklere for at bruge en uvigtig ressource, der var kunstigt begrænset. I stedet bør vi skrue tallet tilbage til standarden og bare ignorere tilfældige parallelle sessioner. Hvis en bruger ikke overskrider IO- eller CPU-grænser, burde det være lige meget, hvor mange parallelle tråde de bruger.
(Med den mulige undtagelse for at forhindre massive brug af parallel forespørgselssession. Sæt dine brugere i en anden profil, og indstil deres SESSIONS_PER_USER til et par dusin. Begræns det IKKE til kun 1 eller 2. IDE'er har brug for ekstra sessioner til flere faner, baggrundsprocesser, der fanger metadata, og fejlfindingssessioner. Hvis du sætter grænsen til 2, vil dine udviklere ikke være i stand til at bruge en IDE korrekt.)
EDIT (svar på kommentarer)
Jeg er ikke sikker på, om du kan læse meget om status for forespørgselskoordinator . QC'en gør flere ting, men ideelt set vil den være inaktiv det meste af tiden, mens de parallelle sessioner håndterer det meste af arbejdet.
Med producent/forbruger-modellen kan halvdelen af de parallelle sessioner modtage data, men ikke rigtig gøre noget - som om de bare er hukommelsesstrukturer i nogle operationer. Parallelle sessioner kan skifte mellem aktive og inaktive, da ikke alle trin kræver så mange sessioner. Men vi ønsker ikke, at Oracle lukker sessioner i midten, da de kan blive nødvendige senere, og vi vil ikke spilde tid på at åbne og lukke sessioner.
Der er snesevis af faktorer, der påvirker graden af parallelitet, men så vidt jeg ved, vil en forøgelse af PARALLEL_MAX_SERVERS ikke påvirke antallet af parallelle servere, der anmodes om for en enkelt erklæring. (Men hvis sætningen allerede bad om flere servere end maks., kan en forøgelse af parameteren påvirke antallet af allokerede sessioner).
Det kan føles som om SQL-sætninger bare tilfældigt griber alle de parallelle sessioner, men i sidste ende følger DOP-beregninger næsten altid deterministiske regler. Det er bare, at reglerne er så komplicerede, at det er svært at sige, hvordan det fungerer. Et almindeligt forvirringspunkt er f.eks., at når en forespørgsel tilføjer sortering eller gruppering, fordobles antallet af parallelle sessioner.