Чтение плана запроса на собеседовании в Спортмастер 🏋️‍♂️

Друзья, всем привет!
С вами Денис 🙏🏻

Сегодня разберём реальное задание с собеседования в компанию «Спортмастер», где нужно было прочитать и объяснить план выполнения SQL-запроса.
Такие кейсы встречаются на интервью в крупных компаниях, поэтому стоит быть к ним готовым 😉

Немного контекста
Я проходил это собеседование прошлой осенью, собирая материал для курса по оптимизации.
Интересный момент — интервью проводила девушка, с которой мы вместе работали в «Магните» в 2016–2018 годах 😅
К счастью, она меня не узнала, и разговор получился очень техническим — без «поблажек по старой памяти».

Теперь к сути
Мне показали фрагмент explain plan и просили объяснить - какие операции в запросы выполняются, что они означают, какие структуры данных использовались.

Понимание плана выполнения — это навык, который проверяют не только в «Спортмастере», но и в банках, телекомах и крупных e-commerce.

Если при виде execution plan вы чувствуете неуверенность — самое время подтянуть знания.
Такие задания часто определяют, пройдёте ли вы техническое интервью или «застрянете» на объяснении простого Full Scan.

🎥 На youtube в HD-качестве

А если хотите научиться читать планы запросов любого уровня сложности - вы знаете что делать 😉

#Oracle #SQL #оптимизация #executionplan #интервью #спортмастер #Denis_Kivilev

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Анкета предзаписи на 7 поток "Оптимизация Oracle SQL"

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

Почему многие специалисты не растут в зарплате?

Привет, друзья 👋
На связи Денис Кивилёв.

Знаете, я всё чаще замечаю одну интересную вещь. Люди становятся всё опытнее, всё грамотнее, но при этом их жизнь как будто стоит на паузе.
Ты смотришь на человека: хороший специалист, с головой, руки на месте, в профессии уже лет десять…
А доход тот же, что и пять лет назад, работа та же… И внутри ощущение: «ну, вроде всё стабильно, но чего-то не хватает».

Многие в этот момент начинают искать новые курсы, технологии, сертификаты,
думая, что «вот сейчас доберу знаний, и всё изменится». Но вот в чём парадокс: знания не решают проблему, если ты живёшь в старой системе координат.

📉 200–300 тысяч — цифра, которая 15 лет назад звучала как «успех жизни». Тогда на эти деньги можно было спокойно закрыть ипотеку за 3–5 лет, купить машину за год и летать с семьёй в отпуск хоть каждый месяц. Это была зарплата уровня «жизнь удалась».

А сегодня что? Эти же 300 тысяч — это пять дней отпуска за границей, ипотека на двадцать лет и нескончаемое ощущение, что ты вроде работаешь, а выдохнуть не можешь…

Но многие продолжают мечтать о тех самых «300 тысячах», словно мы всё ещё живём в 2008 году. Многие продолжают думать, что главное – просто быть хорошим специалистом, что «лишний раз дергаться не стоит», и что «когда-нибудь всё само сложится».

Но мир давно поменялся.
И теперь выигрывают те, кто не ждёт, пока его заметят,
а сам выходит вперёд.
Те, кто не боится переучиваться, идти на новые собеседования, искать возможности там, где другие даже не смотрят.

Пока одни годами сидят на одном месте «ради стабильности», другие работают с зарубежными компаниями, получают офферы на 400–500К, путешествуют с семьёй и живут без страха, что завтра «всё рухнет».

И разница между ними не в знаниях, а в том, что одни продолжают цепляться за прошлое, а другие приняли новое время и двигаются вперёд 🔥

Так что же делать?

1️⃣ Перестать ждать «лучших времён». Они не наступят сами. Сейчас выигрывают те, кто умеет действовать – пробовать новое, выходить за рамки, не бояться ошибиться.

2️⃣ Пересмотреть свои ориентиры. Если вы всё ещё живёте старыми цифрами и старыми ожиданиями, вы играете в игру, которой уже нет. Рынок стал другим. Деньги теперь идут за теми, кто мыслит шире и двигается быстрее.

3️⃣ Не закапывайтесь в стабильности. Стабильность — это красивая упаковка для стагнации. Вы можете оставаться на месте и «ждать повышения», но вокруг вас будут те, кто не боится меняться.

Проблема не в том, что вы чего-то не знаете,
а в том, что вы перестали двигаться. И как только вы снова начнёте, результаты не заставят себя ждать 🚀

С вами был Денис Кивилёв.
Растите. Меняйтесь. Не застревайте в прошлом.
Потому что впереди — куда больше, чем просто «стабильность» 🔥

#oracle #оптимизация #карьера

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Анкета предзаписи на 7 поток "Оптимизация Oracle SQL"

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

История про возврат курса.

Хочу рассказать вам историю из закулисья нашей школы.
Этим летом у нас случился интересный случай.

Один студент прошёл три урока, посетил все вебинары, посмотрел мини-курс. В целом, был активен, задавал вопросы, участвовал в обсуждениях. И, судя по всему, всё шло отлично.

А потом написал сообщение вроде «вы меня ничему научить не можете» и попросил сделать возврат. Мы, конечно, не стали ничего усложнять. Вернули деньги — как и положено, по закону и по-человечески. Вычли только то, что человек реально прошёл. Всё честно и прозрачно.

Скорее всего, дело было не в курсе. Он взял обучение в кредит, не справился с обязательствами, а признаться в этом, видимо, было сложнее, чем просто сказать, что это «мы плохие».

🤷‍♂️ Ну что ж… плохому танцору всегда что-то мешает.

Иногда людям проще обвинить других, чем признать,
что не выдержали ритм, не дотянули, не рассчитали силы.
И это нормально — просто так устроена человеческая психика.

Но знаете, что самое интересное? За 4 года существования школы это был единственный возврат.

Для меня это показатель того, что:
🔥 мы честно работаем;
🔥 держим слово;
🔥 и отвечаем за то, что делаем.

Потому что наша школа — это сообщество людей, которые действительно растут.
И если человек хочет учиться — мы его поддержим. Если хочет вернуть — мы не удерживаем 😉

С вами был Денис Кивилёв.
Всем добра и позитива ☀️

#oracle #оптимизация #карьера

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Анкета предзаписи на 7 поток "Оптимизация Oracle SQL"

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

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

Сегодня я покажу
1️⃣ Почему полезно делать количество секций в хэш-секционировании равным степени двойки. 💡
2️⃣ Разберём, как определить, в какую именно секцию попадает значение ключа секционирования.

Видео относится к серии «интересно, но практически бесполезно» 😄 — поэтому можно расслабиться, налить кофе ☕️ и просто насладиться небольшими техническими изысканиями.

Код к примеру

drop table sale_hash;

create table sale_hash(
  sale_id      number(30) not null,
  sale_date    date not null,
  region_id    char(2 char),
  customer_id  number(30) not null
) 
partition by hash(customer_id)
partitions 4;

-- Вставка 16К записей
insert into sale_hash 
select level, sysdate+level, 'NY', level 
 from dual connect by level <= 16000;
commit; 

-- Сбор статистики
begin
  dbms_stats.gather_table_stats(ownname => user, 
   tabname => 'sale_hash'); 
end;
/
 

select t.partition_position, t.num_rows, t.* 
  from user_tab_partitions t where t.table_name = 'SALE_HASH'
 order by t.partition_position;
  
select ora_hash(t.sale_id, 3) + 1 part_num, count(*)
  from sale_hash t
 group by ora_hash(t.sale_id, 3);
 

Cсылка на документацию, где можно подробнее почитать про функцию ORA_HASH.

Всем приятного просмотра и отличного дня! 🌞

#oracle #базыданных #программирование #Denis_Kivilev

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Анкета предзаписи на 7 поток "Оптимизация Oracle SQL"

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

ОБ ЭТОМ ТОЧНО СТОИТ РАССКАЗАТЬ ⬇️

Привет, друзья 👋
На связи Денис.

Хочу поделиться с вами короткой, но показательной историей. На днях мне написал парень, проходивший обучение в нашей школе, о том, что получил налоговый вычет 💸

И вот что важно: наши программы официально дают возможность получить налоговый вычет.
То есть часть стоимости обучения вы можете вернуть обратно 😉

Как это работает:
— Вы оплачиваете обучение.
— Мы выдаём официальную справку для налоговой.
— Вы подаёте заявление и получаете возврат до 13% от суммы оплаты.

✅ Всё абсолютно законно, быстро и без “танцев с бубном”. И вот пример из практики – человек реально получил деньги обратно уже через пару недель после подачи.

💡Так что если вы думали обучаться на каком-либо из направлений в нашей школе, но сомневались из-за бюджета — просто учтите: часть инвестиций в себя можно вернуть.

Учитесь, развивайтесь, и пусть даже налоговая будет на вашей стороне!

Учёба — это не расход, это инвестиция, которая возвращается 💰

#oracle #оптимизация #карьера #Denis_Kivilev

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Анкета предзаписи на 7 поток "Оптимизация Oracle SQL"

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

Dbms_rowid интересный пакет, который может пригодится

Друзья, всем привет! 👋
С вами Денис.
В нашем канале разного уровня специалисты, этот пост зайдет Middle- и Senior-ребятам, но и Junior могут почерпнуть полезное.

Итак, каждый разработчик Oracle хотя бы раз сталкивался с ROWID — уникальным идентификатором строки в базе. Cодержит информацию о типе ROWID, идентификаторе объекта, относительном номере файла (relative file number), номере блока и номере строки в блоке.

Но как разобрать его на части или создать искусственно? Здесь на помощь приходит пакет DBMS_ROWID. Это не просто утилита, а мощный инструмент для глубокого анализа и манипуляций с данными на уровне блоков. В реальной жизни он спасает при отладке, миграциях или оптимизации хранения. Без него сложно понять, где именно лежит ваша запись в файлах данных.

Пакет DBMS_ROWID появился в Oracle для работы с ROWID из PL/SQL и SQL. Он позволяет извлекать информацию о блоках данных, файлах, объектах и даже создавать тестовые ROWID.

Ключевые функции пакета

DBMS_ROWID.ROWID_CREATE — создает ROWID для тестирования. Полезно, когда нужно симулировать запись без реальной БД.

DECLARE
   v_rowid ROWID;
BEGIN
   v_rowid := DBMS_ROWID.ROWID_CREATE(
      rowid_type => sys.dbms_rowid.rowid_type_extended,
      object_number => 12345,
      relative_fno => 1,
      block_number => 100,
      row_number => 5
   );
   DBMS_OUTPUT.PUT_LINE(v_rowid);
END;

DBMS_ROWID.ROWID_INFO — разбирает существующий ROWID на компоненты: тип, номер объекта, файл, блок и строку.

DECLARE
   v_rowid ROWID := 'AAAAAAAABAAAALaAAA';
   v_type NUMBER;
   v_object NUMBER;
   v_file NUMBER;
   v_block NUMBER;
   v_row NUMBER;
BEGIN
   DBMS_ROWID.ROWID_INFO(
      rowid_in => v_rowid,
      rowid_type => v_type,
      object_number => v_object,
      relative_fno => v_file,
      block_number => v_block,
      row_number => v_row
   );
   DBMS_OUTPUT.PUT_LINE('Объект: ' || v_object || ', Блок: ' || v_block);
END;

Другие полезные модули
ROWID_BLOCK_NUMBER возвращает номер блока,
ROWID_OBJECT — номер объекта,
ROWID_RELATIVE_FNO — относительный номер файла,
ROWID_ROW_NUMBER — номер строки в блоке,
ROWID_TO_ABSOLUTE_FNO — абсолютный номер файла,
ROWID_TO_EXTENDED и ROWID_TO_RESTRICTED для конвертации типов,
ROWID_TYPE для проверки типа,
ROWID_VERIFY для валидации.

Для чего использовать DBMS_ROWID
🔸 Диагностика инцидентов — быстро найти физическое местоположение проблемной строки по ROWID из alert.log/trace.
🔸 Анализ ошибок — определить повреждённый блок, файл и объект.
🔸 Контроль миграций/восстановлений — сверка фактического физического размещения строк между средами.
🔸 Анализ распределения данных — понять плотность блоков, выявить горячие сегменты или неэффективную кластеризацию.
🔸 Работа с партиционированием — определить точный партишен/subpartition, где находится строка.
🔸 Точечный доступ к данным — выборка строк по известным физическим координатам без сложных JOIN.
🔸 Служебное логирование — фиксировать ROWID проблемных записей для последующей диагностики.
🔸 Создание воспроизводимых тестов — моделирование ситуаций с повреждёнными или смещёнными строками.

Пост был навеян лекцией в субботу. Показывал ребятам свой код с Магнита, написанный в 17м году. И наткнулся на dbms_rowid.rowid_object(v_rowid). На скрине выше ⬆️

Используете ли вы DBMS_ROWID в проектах? Поделитесь кейсами, когда он выручил, в комментариях 💬

Всем продуктивного дня и удачных запросов! 🌟

#oracle #dbms_rowid #rowid #plsql #oracledev #базыданных #sql

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Анкета предзаписи на 7 поток "Оптимизация Oracle SQL"

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

Почему вам трудно найти работу с зарплатой выше 100К

За последние месяцы ко мне приходит всё больше ребят, которые говорят одно и то же:

🗣 «У меня нормальный опыт, сильный стек, всё знаю, развиваюсь, но на резюме никто не отвечает».
🗣 «Два, три, шесть месяцев, ни одного внятного собеса».

И каждый раз я вижу одну картину: хорошие специалисты, реально понимающие, что делают… но рынок их просто не замечает.

Это и есть главный парадокс сегодняшнего IT. Ты можешь быть умнее, опытнее, продуктивнее, но всё равно проиграть тому, кто просто лучше презентует свой опыт.

📉 В чём настоящая причина?

Многие продолжают жить в логике «я хороший разработчик — меня сами найдут». Но рынок давно перестал работать по этим правилам. Сейчас выигрывает не тот, кто знает, а тот, кто умеет показать свою ценность.

Пока вы сидите и ждёте, кто-то с меньшим опытом, но с правильной стратегией уже получает офферы на 100–150К.

Почему так происходит?

🔹 Вы не понимаете, как работает воронка найма.
HR смотрит 200+ резюме в день. Не зацепили за первые 10 секунд — вас пролистали.

🔹 Ваше резюме не продаёт.
Там перечислены технологии, но нет ценности и результатов.

🔹 Вы ищете вакансии там, где “ищут все”, и тонете среди сотен одинаковых кандидатов.

🔹 Самое главное — вы ждёте, что процесс «сам как-нибудь сложится».

В итоге получаем парадокс: вы сильный специалист, но рынок вас не видит. Не потому что вы слабый, а потому что вы невидимый.

И вот вопрос: почему один человек получает офферы на 120К+, а другой полгода сидит без единого ответа, хотя делает те же задачи? Да просто первый понимает правила игры

В наших программах карьерные блоки были всегда, но мы адаптировали их под текущие реалии рынка.

Сегодня требования к кандидатам сильно изменились, и мы обновили:

🔥 как должно выглядеть резюме, чтобы проходить автоматические фильтры;
🔥 как оформить опыт так, чтобы HR увидел ценность, а не просто «стек»;
🔥 где реально искать вакансии, чтобы не тонуть среди сотен одинаковых откликов;
🔥 и как себя презентовать так, чтобы вам предлагали даже больше, чем вы просите.

Это не про «продажи». Это про умение показать реальную пользу. Потому что рынок не угадывает, а считывает сигнал. И если сигнал слабый, вас просто не заметят.

💻 Анкета предзаписи на ближайший поток здесь

С вами был Денис Кивилёв.
Не ждите, пока вас найдут — сделайте так, чтобы вас невозможно было не заметить 🚀

#oracle #оптимизация #карьера

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Анкета предзаписи на 7 поток "Оптимизация Oracle SQL"

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

Один в поле не воин.

Знаете, часто люди думают, что все эти вебинары, курсы, проекты и контент я делаю один. Но это не так. Потому что один человек просто не способен тянуть всё это на себе…

Да, я могу выстроить архитектуру, рассказать про оптимизацию Oracle, провести стрим и ответить на сотни технических вопросов…
Но чтобы всё это работало, выглядело и доходило до вас — нужна команда.

И сегодня хочу рассказать о тех, кто делает всю эту “машину” живой 👇

Дима – Project manager. Человек, который управляет всей системой курсов, вебинаров и процессов. Если вы видите, что у нас всё идёт чётко и слаженно, это его заслуга 😉 Он тот самый человек, который воплощает в жизнь мои идеи!

Настя – SMM-специалист. Весь контент, который вы видите, проходит через неё. Без неё мой канал был бы просто набором технических заметок 😅

Влада – бизнес-ассистент. Мой тыл и правая рука. Организация, документы, графики, встречи — всё это на ней. Благодаря Владе у меня не горят дедлайны и не рушатся планы. Также она помогает выстроить четкую систему, иначе был бы просто хаос…

Преподаватели. Про них вы уже слышали много раз — Костя, Паша и другие ребята. Это бойцы невидимого фронта, которые держат методологию и качество обучения на высоте. Люди, которые объясняют сложные вещи простым языком, помогают на стримах, отвечают в чатах и ведут практику.

Но есть и те, кого вы почти не видите:

🔹 Юристы. Готовят документы, договора, всё оформляют так, чтобы вам было спокойно и безопасно.

🔹 Техспециалисты. Поддерживают платформу, исправляют баги, делают обновления, следят за доступами.

🔹 Дизайнер. Отвечает за визуал, баннеры, презентации, обложки, стиль.

🔹 Рекламная команда – чтобы о нас узнали те, кому это реально нужно.

🔹 Бухгалтер и админы – чтобы всё сходилось, учитывалось, сохранялось и работало без сбоев.

Иногда происходят комичные ситуации, когда ребята из команды пишут студентам по делу, а им отвечают:

🗣 «Вы кто? Это точно не фейк?»
🗣 «Меня пытаются развести?»

А это просто наша команда, которая максимально старается вам помочь)

Снаружи может казаться, что все просто. Но на деле это огромный айсберг, у которого под водой скрыты десятки процессов, ролей и задач, о которых вы даже не догадываетесь. За каждым уроком, каждым вебинаром, каждым постом стоят не только мои знания, но и труд целой команды, которая живёт этим проектом 😉

С вами был Денис Кивилёв.
И вся моя команда, без которой этот проект не стал бы тем, чем он является сегодня 🚀

#oracle #оптимизация #карьера

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Анкета предзаписи на 7 поток "Оптимизация Oracle SQL"

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

Composite Index: какую колонку поставить первой?

Коллеги, всем привет!

Этот вопрос волнует и Junior-, и Middle-, и даже Senior-разработчиков: как правильно выбрать порядок колонок в составном индексе?
Казалось бы, простой вопрос: есть таблица, есть запрос с условиями по нескольким колонкам — создаём составной индекс. Но в каком порядке расположить колонки? Ответ не так очевиден, как кажется, и зависит от нескольких факторов.

Что такое селективность?
Селективность колонки — это отношение уникальных значений к общему количеству строк. Чем выше селективность, тем меньше строк возвращается при фильтрации по этой колонке.

Примеры:
🔹 Высокая селективность: ID сотрудника, email, номер паспорта (почти все значения уникальны)
🔹 Низкая селективность: пол (M/F), статус (Y/N), тип документа (5-10 значений)

Традиционная рекомендация — ставить первой колонку с наибольшей селективностью. Логика проста: Oracle быстрее отфильтрует большую часть строк.

Пример:

-- Таблица сотрудников
CREATE INDEX idx_emp_composite 
ON employees(employee_id, department_id, status);

Здесь employee_id имеет высокую селективность (уникальные значения), department_id — среднюю (10-20 отделов), status — низкую (активен/неактивен).

Если ваш запрос использует все три колонки или начинается с employee_id, такой индекс будет работать отлично:

SELECT * FROM employees
WHERE employee_id = 12345
  AND department_id = 10
  AND status = 'A';

Но есть нюанс!
Что если ваши запросы чаще фильтруют по department_id и status, а employee_id используется редко? Тогда индекс с employee_id первым становится бесполезным для большинства запросов.

Анализируйте ваши запросы

Первой должна быть колонка, которая чаще всего используется в WHERE-условиях. Даже если её селективность ниже.

Пример:

-- Частый запрос
SELECT * FROM employees
WHERE department_id = 10
  AND status = 'A';

-- Лучший индекс для этого случая
CREATE INDEX idx_dept_status 
ON employees(department_id, status);

Index Skip Scan и низкая селективность

Oracle умеет использовать составные индексы, даже если первая колонка не участвует в запросе — это называется Index Skip Scan. Но это работает эффективно только если первая колонка имеет низкую кардинальность (мало уникальных значений).

Пример:

CREATE INDEX idx_status_empid 
ON employees(status, employee_id);

-- Запрос без первой колонки
SELECT * FROM employees
WHERE employee_id = 12345;

Oracle может ""перепрыгнуть"" через status (всего 2 значения: Y/N) и использовать индекс. Но если первая колонка имеет тысячи уникальных значений, Skip Scan будет неэффективен.

Практический пример

Допустим, у вас таблица заказов. Типичные запросы:

-- Запрос 1: поиск по клиенту и статусу
SELECT * FROM orders
WHERE customer_id = 1001 AND status = 'PENDING';

-- Запрос 2: поиск по дате и статусу
SELECT * FROM orders
WHERE order_date BETWEEN DATE '2024-01-01' AND DATE '2024-12-31'
  AND status = 'SHIPPED';

Решение:

-- Для запроса 1
CREATE INDEX idx_cust_status 
ON orders(customer_id, status);

-- Для запроса 2
CREATE INDEX idx_date_status 
ON orders(order_date, status);

Обратите внимание: status имеет низкую селективность, но он присутствует в обоих запросах, поэтому идёт вторым.

Итого
Выбор порядка колонок в составном индексе — это баланс между:
🔹 Частотой использования колонки в запросах (главный фактор)
🔹 Селективностью колонки (высокая селективность первой — хорошо)
🔹 Возможностью Index Skip Scan (низкая кардинальность первой колонки помогает)

Не существует универсального правила. Анализируйте ваши реальные запросы, смотрите execution plans, тестируйте разные варианты. Конечно же, на курсе по Оптимизации мы это подробно разбираем.

А как вы решаете, какую колонку поставить первой в составном индексе? Напишите в чатике 💬

#oracle #compositeindex #оптимизация

Канал Oracle Developer | Чатик 💬
Мини-курс Оптимизация: Быстрый старт 🚀

Анкета предзаписи на 7 поток "Оптимизация Oracle SQL" 🔥

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