🛠️ 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-профилям.
🔹🔹🔹🔹
Условный артефакт:
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-профилям.
🔹🔹🔹🔹