Twoje pytania nie są naprawdę kompletne. Chociaż zapytanie pobiera tylko pierwsze 1000 wierszy, programista SQL pobiera tylko pierwsze 50 wierszy z tych 1000 wierszy. IDE nie zamknie kursora, dopóki nie przewiniesz do ostatniego wiersza. Po pobraniu wszystkich danych te równoległe procesy znikają. Upewnij się, że widzisz „Wszystkie wiersze pobrane:1000 w X sekund” zamiast „Pobrano 50 wierszy w Y sekund” (chciałbym, aby program SQL Developer uwidocznił bardziej wizualnie, że czekają dodatkowe wiersze). zobacz ten problem w SQL*Plus, ponieważ SQL*Plus zawsze pobiera wszystkie wiersze.
Gdy pobieranych jest tylko pierwszych N wierszy, te równoległe procesy są „AKTYWNE”, ale nic nie robią. powinieneś być w stanie zignorować te sesje, ponieważ nie zużywają one żadnych znaczących zasobów.
Jeśli martwisz się tylko liczbą sesji równoległych, możesz dostosować swoje oczekiwania. Kiedyś byłem w takiej samej sytuacji jak ty - ciągle mówiąc użytkownikom, że ich (niekompletne) zapytania pochłaniają wszystkie sesje równoległe. W końcu odkryłem, że to tylko problem, ponieważ stworzyłem sztucznie deficytowy zasób. Procesy równoległe Oracle są zwykle lekkie, a bazy danych mogą obsługiwać o wiele więcej równoległych procesów, niż większość ludzi myśli.
Jakie są Twoje wartości parametrów dla PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU i CPU_COUNT? Spójrz na wartość domyślną dla PARALLEL_MAX_SERVERS
. Zgodnie z instrukcją domyślna liczba to:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
Większość administratorów baz danych widzi maksymalną liczbę równoległych wątków w setkach, panikuje, a następnie zmniejsza tę liczbę. A potem zaczynamy krzyczeć na programistów za korzystanie z nieistotnego zasobu, który został sztucznie ograniczony. Zamiast tego powinniśmy podkręcić liczbę z powrotem do wartości domyślnej i po prostu zignorować losowe sesje równoległe. Jeśli użytkownik nie przekracza limitów IO lub CPU, nie powinno mieć znaczenia, z ilu równoległych wątków korzysta.
(Z możliwym wyjątkiem zapobiegania masowym użycie sesji równoległych zapytań. Umieść swoich użytkowników w innym profilu i ustaw ich SESSIONS_PER_USER na kilkadziesiąt. NIE ograniczaj tego do 1 lub 2. IDE wymagają dodatkowych sesji dla wielu kart, procesów w tle, które pobierają metadane, i sesji debugowania. Jeśli ustawisz limit na 2, twoi programiści nie będą mogli poprawnie używać IDE.)
EDYTUJ (odpowiedź na komentarze)
Nie jestem pewien, czy możesz dużo dowiedzieć się o statusie koordynator zapytań . Kontrola jakości robi kilka rzeczy, ale idealnie byłoby, gdyby przez większość czasu była bezczynna, podczas gdy sesje równoległe zajmują się większością pracy.
W modelu producent/konsument połowa sesji równoległych może odbierać dane, ale w rzeczywistości nic nie robi - tak jakby były tylko strukturami pamięci w niektórych operacjach. Sesje równoległe mogą przełączać się między aktywnymi i nieaktywnymi, ponieważ nie wszystkie kroki będą wymagały tylu sesji. Ale nie chcielibyśmy, aby Oracle zamykał sesje w środku, ponieważ mogą być potrzebne później i nie chcielibyśmy tracić czasu na otwieranie i zamykanie sesji.
Istnieją dziesiątki czynników, które wpływają na stopień równoległości, ale o ile wiem, zwiększenie PARALLEL_MAX_SERVERS nie wpłynie na liczbę równoległych serwerów żądanych dla pojedynczej instrukcji. (Ale jeśli instrukcja już prosiła o więcej serwerów niż maksymalna, zwiększenie parametru może wpłynąć na liczbę przydzielonych sesji).
Może się wydawać, że instrukcje SQL po prostu losowo przechwytują wszystkie sesje równoległe, ale ostatecznie obliczenia DOP prawie zawsze postępują zgodnie z regułami deterministycznymi. Tyle, że zasady są tak skomplikowane, że trudno powiedzieć, jak to działa. Na przykład jednym z powszechnych problemów jest to, że za każdym razem, gdy zapytanie dodaje sortowanie lub grupowanie, liczba sesji równoległych jest podwojona.
