Ihre Abfragen sind nicht wirklich vollständig. Obwohl Ihre Abfrage nur die ersten 1000 Zeilen abruft, ruft SQL Developer nur die ersten 50 Zeilen dieser 1000 Zeilen ab. Die IDE schließt den Cursor nicht, bis Sie zur letzten Zeile scrollen. Sobald Sie alle Daten abgerufen haben, verschwinden diese parallelen Prozesse. Stellen Sie sicher, dass Sie "Alle Zeilen abgerufen:1000 in X Sekunden" anstelle von ""50 Zeilen in Y Sekunden abgerufen" sehen (ich wünschte, SQL Developer würde es visuell deutlicher machen, dass zusätzliche Zeilen warten.) Das werden Sie nicht sehen Sie dieses Problem in SQL*Plus, weil SQL*Plus immer alle Zeilen greift.
Wenn nur die ersten N Zeilen abgerufen werden, sind diese parallelen Prozesse "AKTIV", tun aber nichts. Sie sollten in der Lage sein, diese Sitzungen zu ignorieren, da sie keine signifikanten Ressourcen verwenden.
Wenn Sie sich nur Sorgen um die Anzahl der parallelen Sitzungen machen, sollten Sie Ihre Erwartungen vielleicht anpassen. Früher war ich in der gleichen Situation wie Sie – ich habe den Benutzern ständig gesagt, dass ihre (unvollständigen) Abfragen alle parallelen Sitzungen in Beschlag nehmen würden. Schließlich entdeckte ich, dass es nur ein Problem war, weil ich eine künstlich knappe Ressource geschaffen hatte. Parallele Prozesse von Oracle sind normalerweise leichtgewichtig, und Datenbanken können viel mehr parallele Prozesse unterstützen, als die meisten Leute glauben.
Was sind Ihre Parameterwerte für PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU und CPU_COUNT? Sehen Sie sich den Standardwert für PARALLEL_MAX_SERVER
. Laut Handbuch ist die Standardanzahl:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
Die meisten DBAs sehen eine maximale Anzahl von Hunderten paralleler Threads, geraten in Panik und verringern diese Zahl dann. Und dann schreien wir die Entwickler an, weil sie eine unwichtige Ressource verwenden, die künstlich begrenzt wurde. Stattdessen sollten wir die Zahl wieder auf den Standardwert hochdrehen und zufällige parallele Sitzungen einfach ignorieren. Wenn ein Benutzer die E/A- oder CPU-Grenzen nicht überschreitet, sollte es keine Rolle spielen, wie viele parallele Threads er verwendet.
(Mit der möglichen Ausnahme, massive zu verhindern Verwendung paralleler Abfragesitzungen. Fügen Sie Ihren Benutzern ein anderes Profil hinzu und setzen Sie ihre SESSIONS_PER_USER auf ein paar Dutzend. Beschränken Sie es NICHT auf nur 1 oder 2. IDEs benötigen zusätzliche Sitzungen für mehrere Registerkarten, Hintergrundprozesse, die Metadaten erfassen, und Debug-Sitzungen. Wenn Sie das Limit auf 2 setzen, können Ihre Entwickler eine IDE nicht richtig verwenden.)
EDIT (Antwort auf Kommentare)
Ich bin mir nicht sicher, ob Sie viel über den Status des Abfragekoordinator . Die QC erledigt mehrere Dinge, aber im Idealfall ist sie die meiste Zeit untätig, während die parallelen Sitzungen den Großteil der Arbeit erledigen.
Beim Producer/Consumer-Modell empfängt die Hälfte der parallelen Sitzungen möglicherweise Daten, tut aber nicht wirklich etwas - als wären sie in einigen Operationen nur Speicherstrukturen. Parallele Sitzungen können zwischen aktiv und inaktiv wechseln, da nicht alle Schritte so viele Sitzungen benötigen. Aber wir möchten nicht, dass Oracle Sitzungen in der Mitte schließt, da sie später benötigt werden könnten, und wir möchten keine Zeit mit dem Öffnen und Schließen von Sitzungen verschwenden.
Es gibt Dutzende von Faktoren, die den Grad der Parallelität beeinflussen, aber soweit ich weiß, wirkt sich die Erhöhung von PARALLEL_MAX_SERVERS nicht auf die Anzahl der parallelen Server aus, die für eine einzelne Anweisung angefordert werden. (Aber wenn die Anweisung bereits nach mehr Servern als dem Maximum gefragt hat, kann eine Erhöhung des Parameters die Anzahl der zugewiesenen Sitzungen beeinflussen).
Es mag den Anschein haben, als würden SQL-Anweisungen alle parallelen Sitzungen zufällig abrufen, aber letztendlich folgen DOP-Berechnungen fast immer deterministischen Regeln. Es ist nur so, dass die Regeln so kompliziert sind, dass es schwer zu sagen ist, wie es funktioniert. Ein häufiger Punkt für Verwirrung ist beispielsweise, dass immer dann, wenn eine Abfrage eine Sortierung oder Gruppierung hinzufügt, die Anzahl paralleler Sitzungen verdoppelt wird.
