Запрос не меняли, но после сбора статистики он стал медленным
Запрос не меняли, но после сбора статистики он стал медленным Условное сравнение: SQL_ID: один и тот же Старый PLAN_HASH_VALUE: 1847263951 Новый PLAN_HASH_VALUE: 3079186428 Одинаковый SQL_ID не гарантирует одинаковый execution plan. Один SQL может иметь несколько child cursors и планов. Oracle Optimizer учитывает: — статистику и кардинальность; — распределение значений; — bind-переменные; — доступные access paths; — child cursor и контекст оптимизации. Разный PLAN_HASH_VALUE показывает различие планов, но не доказывает причину деградации. Что сравнить: — старый и новый планы; — child cursors; — E-Rows и A-Rows; — даты сбора статистики; — распределение данных; — bind-профили; — условия быстрого и медленного выполнения. A-Rows требуют фактической статистики выполнения: обычного EXPLAIN PLAN недостаточно. Типичная ошибка — сразу заставить Oracle использовать старый план. Это может временно стабилизировать запрос, но не объясняет, почему план изменился и подходит ли прежний вариант текущим данным. Вывод: сначала сравните артефакты выполнения и контекст. Только затем решайте, нужна ли стабилизация плана. #УЦФОРС #Oracle #SQL #ПроизводительностьБД #DBA