Вашите запитвания не са наистина завършени. Въпреки че вашата заявка извлича само първите 1000 реда, SQL Developer извлича само първите 50 реда от тези 1000 реда. IDE няма да затвори курсора, докато не превъртите до последния ред. След като извлечете всички данни, тези паралелни процеси изчезват. Уверете се, че виждате „Извлечени всички редове:1000 за X секунди“, вместо „„Извлечени 50 реда за Y секунди“. (Иска ми се SQL Developer да направи визуално по-очевидно, че има чакащи допълнителни редове.) Няма да вижте този проблем в SQL*Plus, защото SQL*Plus винаги хваща всички редове.
Когато се извличат само първите N реда, тези паралелни процеси са „АКТИВНИ“, но не правят нищо. Вие трябва можете да игнорирате тези сесии, тъй като те не използват никакви значителни ресурси.
Ако се притеснявате само за броя на паралелните сесии, може да искате да коригирате очакванията си. Преди бях в същата ситуация като вас - постоянно казвах на потребителите, че техните (непълни) заявки затрупват всички паралелни сесии. В крайна сметка открих, че това е само проблем, защото бях създал изкуствено оскъден ресурс. Паралелните процеси на Oracle обикновено са леки и базите данни могат да поддържат много повече паралелни процеси, отколкото повечето хора смятат, че могат.
Какви са вашите стойности на параметрите за PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU и CPU_COUNT? Вижте стойността по подразбиране за PARALLEL_MAX_SERVERS
. Според ръководството числото по подразбиране е:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .
Повечето DBA виждат максимален брой паралелни нишки в стотици, изпадат в паника и след това намаляват този брой. И тогава започваме да крещим на разработчиците за използването на маловажен ресурс, който е изкуствено ограничен. Вместо това трябва да върнем числото обратно към стандартното и просто да игнорираме произволни паралелни сесии. Ако даден потребител не надвишава ограниченията за IO или CPU, не трябва да има значение колко паралелни нишки използва.
(С възможното изключение на предотвратяването на масивни използване на паралелна сесия на заявка. Поставете вашите потребители в различен профил и задайте техните SESSIONS_PER_USER на няколко дузини. НЕ го ограничавайте само до 1 или 2. IDE се нуждаят от допълнителни сесии за множество раздели, фонови процеси, които грабват метаданни, и сесии за отстраняване на грешки. Ако зададете ограничението на 2, вашите разработчици няма да могат да използват правилно IDE.)
РЕДАКТИРАНЕ (отговор на коментари)
Не съм сигурен дали можете да прочетете много в състоянието на координатор на заявки . QC прави няколко неща, но в идеалния случай той ще бъде неактивен през по-голямата част от времето, докато паралелните сесии се справят с по-голямата част от работата.
С модела производител/потребител половината от паралелните сесии може да получават данни, но всъщност да не правят нищо - сякаш са просто структури на паметта в някои операции. Паралелните сесии могат да превключват между активни и неактивни, тъй като не всички стъпки ще се нуждаят от толкова много сесии. Но не бихме искали Oracle да затваря сесии по средата, тъй като може да са необходими по-късно и не бихме искали да губим време за отваряне и затваряне на сесии.
Има десетки фактори, които влияят на степента на паралелизъм, но доколкото ми е известно, увеличаването на PARALLEL_MAX_SERVERS няма да повлияе на броя на паралелните сървъри, изисквани за един оператор. (Но ако операторът вече изискваше повече сървъри от максимума, увеличаването на параметъра може да повлияе на броя разпределени сесии).
Може да изглежда, че SQL изразите просто произволно грабват всички паралелни сесии, но в крайна сметка DOP изчисленията почти винаги следват детерминирани правила. Просто правилата са толкова сложни, че е трудно да се каже как работят. Например, една често срещана точка на объркване е, че всеки път, когато дадена заявка добави сортиране или групиране, броят на паралелните сесии се удвоява.
