Да, упоминание о декартовых соединениях обычно заставляет сердце 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 после неудачных попыток получить статистику объекта для взаимодействия.