Когда Oracle CBO решает выполнить операцию объединения с декартовым слиянием?
Время от времени, Oracle, кажется, предпочитает MERGE JOIN CARTESIAN операция над регулярной MERGE JOIN, Зная данные и глядя на конкретные планы выполнения, я вижу, что эта операция обычно не является проблемой, поскольку одна из связанных сущностей может вернуть только одну запись в запросе.
Однако по историческим причинам наши администраторы баз данных испытывают общее отвращение к декартовым продуктам.
Поэтому я бы хотел лучше проанализировать эти случаи и получить подтверждение в документации в моей аргументации. Есть ли официальная документация Oracle о преобразовании запросов и CBO, где я могу понять случаи, когда Oracle предпочитает MERGE JOIN CARTESIAN (или похожая) операция?
В этом случае я использую Oracle 11g (11.2.0.2.0)
ОБНОВЛЕНИЕ:
Это похожие вопросы, но они не объясняют, почему или когда Oracle предпочитает MJC по регулярному MERGE JOIN:
1 ответ
Да, упоминание о декартовых объединениях обычно заставляет сердце DBA пропустить удар. Декартовы объединения, вызванные отсутствием условий соединения, безусловно, являются проблемой, с которой приходится сталкиваться - это типы соединений, которые могут "взорвать" временное пространство и вызвать срабатывание всех типов сигналов тревоги.
Я не нашел ничего в официальной документации Oracle 11g по этому конкретному методу соединения, но я нашел множество статей о проблемах с ним в их базе данных поддержки. Я преследовал некоторые из них в последние пару недель, и вот что я нашел.
Источником MJC является оптимизация CBO. MJC - это оптимизация, которая отлично работает, когда количество присоединяемых наборов результатов низкое. Проблема возникает, когда Оптимизатор неправильно оценивает мощность одного или нескольких наборов результатов, которые являются входными данными для объединения. Если предполагаемые строки = 1 (или является небольшим числом), но фактические строки для набора результатов велики, тогда оптимизатор все равно может выбрать MJC, что приведет к неоптимальному плану. И это преуменьшение. У меня были проблемы с этим, и запросы выполнялись в течение нескольких дней и не заканчивались. После того, как CBO вернулся в строй, они работали в секундах, а не в часах или днях.
Лучший способ выяснить, соответствует ли этот пример оценочным или действительным строкам, - это выполнить запрос и просмотреть статистику его плана выполнения. Вы упомянули, что вы на 11g - используйте функцию мониторинга SQL. Вывод этой функции покажет вам, сколько времени было потрачено на каждый шаг вашего плана выполнения. Он также покажет вам оценочные строки против фактических строк. Вы ищете большие расхождения в оценочных и фактических строках входных данных для MJC.
Мониторинг SQL доступен через OEM/DB Control, или вы можете использовать API (поиск DBMS_SQLTUNE.REPORT_SQL_MONITOR). Те же самые виды информации можно собрать, используя подсказку GATHER_PLAN_STATISTICS с запросом, а затем сгенерировать отчет с помощью DBMS_XPLAN... подробности здесь, чтобы сделать это.
Так как от этого избавиться? Попробуйте решить проблемы со статистикой объекта. Как только CBO знает, что на самом деле имеет дело с сотнями, тысячами или миллионами записей в качестве входных данных для объединения вместо "1", ему следует выбрать метод соединения, более подходящий для набора данных, а не выбирать MJC. Легче сказать, чем сделать, книги по этой теме написаны, но, по крайней мере, ознакомьтесь с основами - убедитесь, что во всех таблицах, включенных в запрос, есть статистика. Может также оказаться возможным использовать дополнительную статистику, если в предложении where применяются выражения из нескольких столбцов.
Если вам нужен большой молот, есть некоторые скрытые параметры, которые разрешают / запрещают использование MJC. Они могут быть реализованы на уровне базы данных, на уровне сеанса или уровне запросов (с помощью подсказок). Я оставлю имена параметров в качестве упражнения для читателя, поскольку официальная позиция Oracle заключается в том, что они должны использоваться только под руководством службы поддержки. Не говорите им, но я добился некоторого успеха, устраняя MJC на уровне запроса с подсказкой OPT_PARAM после неудачных попыток получить статистику объекта для взаимодействия.