Добавить в корзинуПозвонить
Найти в Дзене
Oracle Developer

⚡️ Cardinality Feedback — как запрос «учится» на ходу

Друзья, всем привет! 👋 Хотим поделиться с вами кейсом нашего ученика и давнего подписчика Олега. Ему слово. Есть запрос, построенный на двух view. Он долго отрабатывал из-за неверного типа соединения, я добавил хинты, стало лучше. Но.. • первый запуск - 6 минут ⏳ • второй запуск - уже 12 секунд 🚀 🕵️‍♂️ Что происходит? Залез в v$sql_shared_cursor и увидел несколько child-курсоров. Разница - в планах выполнения и флаге USE_FEEDBACK_STATS. В «быстром» плане было примечание: cardinality feedback used. 📊 Что за Cardinality Feedback❓ Если коротко, это механизм, с помощью которого оптимизатор Oracle буквально «учится на своих ошибках»: при выполнении запроса он сравнивает estimate rows, вычисленное на основе доступной статистики, с actual rows. Если разница существенна, Oracle фиксирует этот промах, и при следующем запуске этого же запроса опирается уже на фактические цифры из прошлого выполнения. Это позволяет ему на лету корректировать свои ожидания и выбирать более оптимальный п

⚡️ Cardinality Feedback — как запрос «учится» на ходу

Друзья, всем привет! 👋

Хотим поделиться с вами кейсом нашего ученика и давнего подписчика Олега. Ему слово.

Есть запрос, построенный на двух view. Он долго отрабатывал из-за неверного типа соединения, я добавил хинты, стало лучше. Но..

• первый запуск - 6 минут ⏳

• второй запуск - уже 12 секунд 🚀

🕵️‍♂️ Что происходит?

Залез в v$sql_shared_cursor и увидел несколько child-курсоров. Разница - в планах выполнения и флаге USE_FEEDBACK_STATS. В «быстром» плане было примечание: cardinality feedback used.

📊 Что за Cardinality Feedback❓

Если коротко, это механизм, с помощью которого оптимизатор Oracle буквально «учится на своих ошибках»: при выполнении запроса он сравнивает estimate rows, вычисленное на основе доступной статистики, с actual rows. Если разница существенна, Oracle фиксирует этот промах, и при следующем запуске этого же запроса опирается уже на фактические цифры из прошлого выполнения. Это позволяет ему на лету корректировать свои ожидания и выбирать более оптимальный план. В новых версиях Oracle этот механизм стал частью Adaptive Statistics.

💡 Что происходит под капотом

1️⃣ Первый запуск - оптимизатор промахивается с оценкой строк (estimate vs actual) 🤷‍♂️

2️⃣ Второй запуск - используются реальные данные прошлого выполнения, план перестраивается на HASH JOIN

3️⃣ Третий запуск - быстрый план закрепляется как основной, флаги сбрасываются, и всё работает стабильно ⚡️

🛠 Как заставить запрос летать с первого раза?

✅ Актуальная статистика: хорошо, но не всегда помогает.

✅ SQL Plan Baseline: когда нужно быстро закрепить план на проде, не дожидаясь тех.окна.

✅ Хинтование: можно взять хинты из блока OUTLINE DATA «быстрого» плана и прибить ими план основного запроса.

✅ dynamic sampling: хороший dynamic sampling позволяет построить верный план уже для Child 0.

Пишите в наш чатик, если сталкивались с таким в своей работе. Ставьте палец вверх, если понравилось 👍🏻 Олегу будет приятно 😊

На курсе по оптимизации мы более подробно говорим про статистику и Adaptive Features. Без понимания этих тем будет сложно закрывать технический блок на интервью, если вы претендуете на синьорские позиции. Чтобы не попасть в такую ситуацию, заполняйте анкету предзаписи на 8-ой поток по оптимизации.

#oracle #sql #performance #оптимизация #обучение #Oleg_Druts #Pavel_Dolganov

Канал Oracle Developer | Чатик 💬

Мини-курс Оптимизация: Быстрый старт 🚀

📱 YouTube 📱 ВКонтакте 📱 LinkedIn 📱Threads

RUTUBE