Коллеги, всем привет! 👋
На связи Денис.
Подкину вам еще одну жизненную задачку из практики работы с DWH и большими объемами данных.
Смотрите, частая история: разработчику нужно перелить крупную пачку данных из одной таблицы в другую. Чтобы процесс не тянулся часами, он щедро добавляет хинты параллелизма и пишет:
insert /*+ parallel(8) / into sales_history
select /+ parallel(8) */ * from stage_sales;
Казалось бы, план надежный как швейцарские часы: чтение на 8 потоках, вставка на 8 потоках, сейчас все залетит со свистом.
Но открываем реальный план выполнения (или SQL Monitor) и видим странную картину:
выборка из таблицы stage_sales честно идет параллельно на 8 процессах, а вот сама операция LOAD TABLE CONVENTIONAL (вставка в sales_history) упорно выполняется одним-единственным процессом-координатором (QC).
В итоге вся параллельная мощь упирается в одно горлышко, а разработчик сидит и недоумевает, почему база не хочет писать в несколько потоков, хотя хинт прямо перед глазами.
Вопрос к вам:
почему Oracle проигнорировал параллелизм именно на операцию вставки и выполняет запись последовательно? Чего не хватает в сессии или коде?
Пишите свои варианты в комментариях 💬
А я разберу этот кейс на вебинаре "Секреты работы с DWH" 3 сентября. Обязательно приходите и коллег приводите, детей, жен, мам 👌🏻
С вами был Денис. Всем отличного дня и шустрого выполнения запросов 🤝
#oracle #sql #performance #dwh #parallel #оптимизация #Denis_Kivilev
Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀
📱 YouTube 📱 ВКонтакте 📱 LinkedIn 📱Threads
RUTUBE