🛠️ SQL тот же, а план другой. Что проверить в Oracle?

Условный артефакт: SQL_ID: 8m4y2q7p1abc9

Быстрое выполнение: PLAN_HASH_VALUE: 1847263951

Медленное выполнение: PLAN_HASH_VALUE: 3079186428

Один SQL_ID может иметь несколько child cursors и планов. Разный PLAN_HASH_VALUE показывает различие планов, но ещё не объясняет причину замедления.

Что могло измениться: — статистика и оценки кардинальности; — распределение значений; — bind-профиль; — child cursor; — параметры и контекст оптимизации; — доступные access paths.

Для ключевых операций сравните: E-Rows — оценка оптимизатора A-Rows — фактические строки

Например: E-Rows: 120 A-Rows: 380000

Такое расхождение может повлиять на join order, join method и способ доступа.

Важно: A-Rows нет в обычном EXPLAIN PLAN. Нужна статистика фактического выполнения и вывод cursor, например через DBMS_XPLAN.DISPLAY_CURSOR. Формат ALLSTATS LAST полезен только тогда, когда runtime plan statistics были собраны.

Проверьте: — старый и новый PLAN_HASH_VALUE; — номера child cursors; — расхождения E-Rows и A-Rows; — даты и состав статистики; — изменения распределения данных; — bind-профили быстрого и медленного выполнения.

Adaptive Cursor Sharing может дать одному statement несколько планов для разных bind-значений. Но bind peeking — не единственная возможная причина, а несколько child cursors — не автоматическая ошибка.

Вывод: не фиксируйте прежний план только потому, что раньше он был быстрым. Сначала проверьте, подходит ли он текущим данным и разным bind-профилям.

🔹🔹🔹🔹