Наборы параллельных серверов: PARALLEL_DEGREE_LIMIT ограничивает степень параллелизма, но если ваш запрос сортирует или группирует, количество параллельных процессов может быть в два раза больше (два набора серверов для включения параллелизма между процессами). Это объясняет, почему вы увидите 48 параллельных процессов даже с пределом 24. Это также происходит, если вы используете диспетчер ресурсов для ограничения DOP.
Параллельные подсказки: PARALLEL_DEGREE_LIMIT применяется только к операторам, которые используют автоматическую степень параллелизма. Любые операторы, которые используют жестко запрограммированную степень, или даже любой тип параллельной подсказки уровня объекта, будут игнорировать ограничение. Если у вас есть эти подсказки, это может объяснить, почему вы видите 96 раз.
Калибровка ввода / вывода: возможно, автоматический DOP не используется, и, следовательно, ограничение не соблюдается, поскольку ввод / вывод не был откалиброван . Этот запрос скажет вам, был ли IO откалиброван:
select * from V$IO_CALIBRATION_STATUS;
Я видел эту проблему раньше, но моя текущая система не откалибрована, и автоматический DOP, кажется, работает нормально. Вы можете определить, действительно ли это проблема, взглянув на раздел «Примечания» плана объяснения. Если вы видите что-то, как у - automatic DOP: Computed Degree of Parallelism is 2
вас все хорошо, но вы не хотите видеть automatic DOP: skipped because of IO calibrate statistics are missing
.
Увеличьте PARALLEL_MAX_SERVERS: вместо того, чтобы беспокоиться о нехватке параллельных серверов, я бы рекомендовал вам значительно увеличить PARALLEL_MAX_SERVERS. Вы должны хотя бы попытаться вернуться к значению по умолчанию : PARALLEL_THREADS_PER_CPU x CPU_COUNT x concurrent_parallel_users x 5, между 240 и 960, в зависимости от настроек памяти.
Эти высокие цифры звучат нелепо для многих администраторов баз данных, но на самом деле они имеют большой смысл по следующим причинам:
- Параллельные серверы Oracle являются более легкими, чем предполагает большинство людей. (И вряд ли кто-либо когда-либо тестирует это, они просто находят одну ситуацию, когда большой DOP вызывает проблему, и предполагают, что высокий DOP всегда плох.)
- Распространено выполнение запроса adhoc в инструменте с графическим интерфейсом, который извлекает только первые 50 строк, но при этом использует десятки параллельных серверов. Эти запросы НЕ потребляют каких-либо значительных ресурсов, если только PARALLEL_MAX_SERVERS не слишком низок. Затем люди кричат на выполнение совершенно разумных запросов, что может привести к некоторым уродливым ситуациям.
- Очень большой DOP для одного запроса не всегда плох. Все предполагают, что если вы продолжите увеличивать DOP, накладные расходы станут слишком высокими, а производительность значительно снизится. Но во многих системах я обнаружил, что даже смехотворно высокий DOP приведет к повышению производительности, хотя отдача определенно уменьшается, и это может быть очень несправедливо по отношению к другим сеансам. Но не просто угадай, проверь это; возьмите запрос и запустите его со всеми видами DOP, вплоть до 1000. Вы можете быть удивлены.
- Да, слишком много параллелизма может быть плохо. Но что хуже для системы, имея чуть больше, чем оптимальное количество сеансов, или заставляя выполнять последовательный запрос и в основном убивая важную работу? Вы должны контролировать систему, прежде чем вводить произвольные ограничения.