Le tue domande non sono veramente complete. Sebbene la tua query recuperi solo le prime 1000 righe, SQL Developer recupera solo le prime 50 righe di quelle 1000 righe. L'IDE non chiuderà il cursore finché non scorri fino all'ultima riga. Una volta recuperati tutti i dati, quei processi paralleli scompaiono. Assicurati di vedere "Tutte le righe recuperate:1000 in X secondi", invece di ""Rilevati 50 righe in Y secondi". (Vorrei che SQL Developer rendesse visivamente più ovvio che ci sono righe aggiuntive in attesa.) Non lo farai vedere questo problema in SQL*Plus perché SQL*Plus acquisisce sempre tutte le righe.
Quando vengono recuperate solo le prime N righe, quei processi paralleli sono "ATTIVI" ma non stanno facendo nulla. dovresti essere in grado di ignorare quelle sessioni poiché non utilizzano risorse significative.
Se sei preoccupato solo per il numero di sessioni parallele, potresti voler modificare le tue aspettative. Ero nella tua stessa situazione:dicevo costantemente agli utenti che le loro query (incomplete) stavano monopolizzando tutte le sessioni parallele. Alla fine, ho scoperto che era solo un problema perché avevo creato una risorsa artificialmente scarsa. I processi paralleli Oracle sono generalmente leggeri e i database possono supportare molti più processi paralleli di quanto la maggior parte delle persone pensi di poter fare.
Quali sono i valori dei parametri per PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU e CPU_COUNT? Osserva il valore predefinito per PARALLEL_MAX_SERVER
. Secondo il manuale, il numero predefinito è:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
La maggior parte dei DBA vede un numero massimo di thread paralleli nell'ordine delle centinaia, va in panico e quindi diminuisce quel numero. E poi iniziamo a sgridare gli sviluppatori per aver utilizzato una risorsa irrilevante che era artificialmente limitata. Invece, dovremmo riportare il numero al valore predefinito e ignorare semplicemente le sessioni parallele casuali. Se un utente non supera i limiti di IO o CPU, non dovrebbe importare quanti thread paralleli utilizza.
(Con la possibile eccezione di prevenire massicci utilizzo della sessione di query parallela. Metti i tuoi utenti in un profilo diverso e imposta i loro SESSIONS_PER_USER su poche dozzine. NON limitarlo a 1 o 2. Gli IDE richiedono sessioni extra per più schede, processi in background che raccolgono metadati e sessioni di debug. Se imposti il limite a 2, i tuoi sviluppatori non saranno in grado di utilizzare correttamente un IDE.)
EDIT (risposta ai commenti)
Non sono sicuro che tu possa leggere molto sullo stato di coordinatore query . Il controllo qualità fa diverse cose, ma idealmente sarà inattivo per la maggior parte del tempo mentre le sessioni parallele gestiscono la maggior parte del lavoro.
Con il modello produttore/consumatore, metà delle sessioni parallele potrebbe ricevere dati ma in realtà non fare nulla, come se fossero solo strutture di memoria in alcune operazioni. Le sessioni parallele possono passare da attive a inattive, poiché non tutti i passaggi richiedono lo stesso numero di sessioni. Ma non vorremmo che Oracle chiudesse le sessioni nel mezzo, poiché potrebbero essere necessarie in seguito e non vorremmo perdere tempo ad aprire e chiudere le sessioni.
Ci sono dozzine di fattori che influenzano il grado di parallelismo, ma per quanto ne so l'aumento di PARALLEL_MAX_SERVERS non influirà sul numero di server paralleli richiesti per una singola istruzione. (Ma se l'istruzione richiedeva già più server del massimo, l'aumento del parametro potrebbe influire sul numero di sessioni allocate).
Potrebbe sembrare che le istruzioni SQL afferrino casualmente tutte le sessioni parallele, ma alla fine i calcoli DOP seguono quasi sempre regole deterministiche. È solo che le regole sono così complicate, è difficile dire come funzioni. Ad esempio, un punto di confusione comune è che ogni volta che una query aggiunge l'ordinamento o il raggruppamento, il numero di sessioni parallele viene raddoppiato.
