УКЦ ФОРС | Обучение IT

🛠️ Формальный заместитель есть. Но во время инцидента все всё равно звонят одному эксперту У резервного специалиста могут быть доступы, документация и записи обучения. Но это ещё не означает, что он сможет: — распознать проблему; — собрать нужные данные; — выполнить разрешённое действие; — остановиться у границы риска; — вовремя эскалировать. Курс даёт знания по технологии. Резервная роль требует ещё практики, полномочий, актуального runbook и проверки на сценарии. Для каждого критичного случая стоит зафиксировать: сценарий → признаки → обязательные артефакты → допустимые действия → граница эскалации → обновление runbook. Резервному специалисту не нужно полностью копировать эксперта. Для одного сценария он только собирает данные, для другого выполняет штатную операцию, для третьего проводит первичную стабилизацию в заранее согласованных границах. Готовность проверяют через парную практику и модельный инцидент в учебной или контролируемой среде. Оценивают не только результат, но и порядок диагностики, соблюдение полномочий и качество эскалации. Своевременно остановиться и передать эксперту полную картину — нормальный результат, а не провал подготовки. Вывод: резервная роль создаётся не вторым сертификатом, а конкретной ответственностью и практикой на критичных сценариях. Поможем определить критичные сценарии и собрать программу для основной и резервной ролей команды. 🔹🔹🔹🔹

🛠️ Запросу нужен один день, но в плане остались все месячные партиции Артефакт: Append -> Seq Scan on events_2026_01 -> Seq Scan on events_2026_02 -> Seq Scan on events_2026_03 ... -> Seq Scan on events_2026_12 Первая реакция — добавить индексы. Но pruning и индекс решают разные задачи. partition pruning отвечает: какие партиции можно исключить? Индекс отвечает: как читать строки внутри оставшейся партиции? Если лишние месяцы не исключены, индекс на каждой партиции не исправит причину. Что проверить: — ключ и способ партиционирования; — границы дочерних таблиц; — фактический WHERE; — типы ключа и параметров; — функции и cast над ключом; — реальные значения параметров; — enable_partition_pruning; — сколько партиций осталось под Append; — какие дочерние узлы реально выполнялись. Append сам по себе не ошибка. Варианты плана: Append -> Seq Scan on events_2026_08 Лишние партиции отсутствуют. Pruning мог пройти при планировании. Subplans Removed: 11 Под-планы могли быть исключены при инициализации. (never executed) Узел не запускался при выполнении. Но это нужно смотреть вместе со всем планом и loops. Почему pruning мог не сработать: — условие не ограничивает ключ партиционирования; — ключ обёрнут в функцию, например date(event_time); — тип параметра отличается от типа ключа; — таблица разделена по выражению, а запрос использует другую форму; — параметры становятся известны только при выполнении; — условие действительно затрагивает несколько партиций. Prepared statement с $1 и $2 не означает автоматического чтения всех партиций. PostgreSQL может исключать их позже — при инициализации или выполнении. И не переписывайте условие по времени механически. Для timestamp, timestamptz и бизнес-дня важны типы и границы. Типичная ошибка — лечить каждый дочерний Seq Scan отдельным индексом. Вывод: сначала проверьте, почему партиции остались в плане. Потом анализируйте Seq Scan, Index Scan и индексы внутри оставшихся партиций. Сохраните признаки, по которым в плане видно, что проблема начинается до выбора индекса — на этапе отбора партиций. 🔹🔹🔹🔹

🛠️ Pod исчез без stack trace, а контроллер создал новый В describe старого Pod: Status: Failed Reason: Evicted Message: The node was low on resource: ephemeral-storage Это не обычный restart контейнера. Kubelet завершил Pod, чтобы защитить узел от нехватки ресурса. Новый Pod, если его создал Deployment или StatefulSet, — это уже другой объект с другим UID. Что проверить первым: kubectl describe pod <pod> kubectl describe node <node> Ключевые признаки: — Reason: Evicted; — Message; — Events; — nodeName; — DiskPressure=True. DiskPressure — это не только свободные гигабайты. Узел может страдать от нехватки inode. Проверяйте: nodefs.available nodefs.inodesFree imagefs.available imagefs.inodesFree В некоторых версиях и конфигурациях также может быть containerfs. Что обычно расходует local ephemeral storage: — writable layer контейнера; — контейнерные логи; — дисковый emptyDir; — временные файлы и кеши. Образы могут давить на imagefs. emptyDir с medium: Memory — это память, не дисковое ephemeral storage. Важно разделять два сценария: DiskPressure на узле → kubelet выселяет Pod Pod превысил свой ephemeral-storage limit → kubelet тоже может выполнить eviction Поэтому смотрите и Node, и Message конкретного Pod, и его requests/limits. Requests и limits не заменяют: — ротацию логов; — контроль emptyDir; — очистку кеша; — мониторинг inode; — управление образами; — резервирование ресурсов узла. Типичная ошибка — искать crash, OOMKilled или проблему probes и не проверить Reason: Evicted. Вывод: Evicted → DiskPressure или limit → nodefs/imagefs/containerfs → байты или inode → logs / writable layer / emptyDir / images → безопасное изменение Сохраните набор артефактов для случая, когда Pod исчезает без явного stack trace приложения. 🔹🔹🔹🔹

🛠️ CPU и память в норме, но сервис пишет Too many open files Артефакт: accept: Too many open files /proc/<pid>/limits: Max open files 4096 4096 files открытых FD: 3987 Причина может быть в RLIMIT_NOFILE — лимите файловых дескрипторов процесса. FD — это не только файл. Лимит расходуют сокеты, pipe, epoll, eventfd, inotify и другие объекты. Поэтому сетевой сервис может упасть на accept(): для нового соединения нужен новый дескриптор, а процесс уже близко к лимиту. Что проверить: 1. Фактический лимит процесса cat /proc/<pid>/limits Не ориентируйтесь только на ulimit -n в административной shell: systemd-сервис может запускаться с другим LimitNOFILE. 2. Текущее число FD ls /proc/<pid>/fd | wc -l Это снимок, не доказательство утечки. 3. Динамику FD растут с нагрузкой и освобождаются → возможно, лимит мал для штатной конкурентности FD растут и не возвращаются → возможна утечка или долгое удержание ресурсов 4. Типы дескрипторов Посмотрите, что накапливается: socket, pipe, anon_inode, файлы, соединения к базе, клиентские подключения. Важно различать: EMFILE — лимит конкретного процесса ENFILE — системный предел Типичная ошибка — сразу поднять LimitNOFILE. Если это штатная нагрузка, повышение может быть оправдано. Если это утечка, новый лимит только увеличит время до повторного инцидента. Вывод: сначала лимит процесса, число FD, динамика и источник роста. Только потом настройки приложения и unit. Сохраните порядок проверки: лимит процесса → фактическое число FD → динамика → источник утечки → настройки unit. 🔹🔹🔹🔹

🛠️ В логах появилось предупреждение о XID wraparound. Почему это не обычный VACUUM? Артефакт: WARNING: database "billing" must be vacuumed within ... transactions База пока работает, поэтому предупреждение легко отложить. Но wraparound связан не с размером таблицы и не только с dead tuples. PostgreSQL использует ограниченное циклическое пространство transaction ID. Старые версии строк нужно вовремя замораживать, чтобы после оборота XID они не выглядели как версии «из будущего». Важно различать: очистка dead tuples → повторное использование места freeze → защита от XID wraparound Даже почти статичная таблица может нуждаться в freeze. С чего начать диагностику: SELECT datname, age(datfrozenxid) AS xid_age FROM pg_database ORDER BY xid_age DESC; datfrozenxid — не средний возраст строк. Его удерживает самое старое отношение внутри базы. После этого ищут таблицу или TOAST с максимальным возрастом relfrozenxid. Одного факта «VACUUM запускался» недостаточно. Нужно проверить: — снизился ли age(relfrozenxid); — завершился ли vacuum; — не был ли он отменён; — не находится ли старый XID в TOAST; — не мешают ли долгие транзакции или prepared transactions; — как быстро система расходует XID; — насколько близко значение к настройкам конкретной версии и системы. Anti-wraparound autovacuum запускается даже при отключённом обычном autovacuum. Отменять его как «неудобную фоновую уборку» опасно. Если предупреждения игнорировать, PostgreSQL перестанет назначать новые XID. Записывающие операции начнут завершаться ошибками, хотя read-only-нагрузка ещё может работать. Типичная ошибка: anti-wraparound autovacuum грузит диск → отменим → запустим обычный VACUUM потом Так можно сократить оставшийся запас XID. Не начинайте с VACUUM FULL, массового VACUUM FREEZE или изменения freeze-параметров без анализа версии, таблиц и окна обслуживания. Вывод: риск wraparound нужно искать до аварийного сообщения — по возрасту datfrozenxid, relfrozenxid, TOAST-отношений и динамике расходования XID. Сохраните набор признаков, по которым риск XID wraparound нужно искать до аварийного сообщения. 🔹🔹🔹🔹

🛠️ Каждая роль знала свою часть миграции. Почему команда всё равно потеряла время на rollback? Сценарий: разработчик подготовил изменение → DBA оценил миграцию → DevOps запустил выкладку → мониторинг показал деградацию → команда обсуждает rollback Проблема часто возникает не из-за полного отсутствия знаний, а на стыках ответственности. Во время инцидента внезапно появляются вопросы: — какое отклонение критично; — кто принимает решение об остановке; — какие метрики нужны DBA; — совместима ли старая версия приложения с изменённой схемой; — что именно откатывает pipeline; — кто проверяет данные после rollback. Разработчик понимает код и назначение изменения. DBA оценивает влияние на БД. DevOps управляет выкладкой. Эксплуатация видит метрики и алерты. Но для общего решения нужна согласованная цепочка: изменение → риск → выкладка → наблюдение → решение → проверка результата Что можно отработать вместе: — обязательные проверки до миграции; — baseline-метрики; — критерии остановки; — передачу данных между ролями; — порядок решения о rollback; — проверку сервиса и данных после отката; — фиксацию выводов после инцидента. Межролевое обучение не означает одинаковый курс для всех. Общая часть отвечает на вопрос: «как мы действуем вместе?» Профильные модули — на вопрос: «что каждый специалист должен уметь на своём участке?» Вывод: для миграций, релизов и инцидентов важно отрабатывать не только инструменты, но и передачу контекста, критерии остановки и общий порядок действий. Поможем собрать программу обучения вокруг общих рабочих сценариев команды, а не только вокруг отдельных ролей. 🔹🔹🔹🔹

🛠️ Август в УКЦ ФОРС: курсы для работы с инфраструктурой, данными и ИИ В августовском расписании — программы для администраторов, разработчиков, DevOps-инженеров и специалистов, которые внедряют инструменты искусственного интеллекта в рабочие процессы. Выбирайте направление под текущую задачу команды или следующий профессиональный шаг. KUBERNETES Kubernetes: от основ до CI/CD 10–14 августа Курс для тех, кому важно системно разобраться в работе Kubernetes и связать эксплуатацию контейнерных приложений с процессами CI/CD. POSTGRESQL Администрирование PostgreSQL 16. Базовый курс 5–7 августа Администрирование PostgreSQL 16. Настройка и мониторинг 10–14 августа Администрирование PostgreSQL 16. Резервное копирование и репликация 17–18 августа PostgreSQL 16. Оптимизация запросов 19–21 августа Tantor Postgres: DBA1-18. Администрирование PostgreSQL 18 24–28 августа В расписании представлены программы для разных рабочих задач: от базового администрирования до мониторинга, резервного копирования, репликации и оптимизации запросов. MONGODB Основы MongoDB 7.0 17–18 августа Программа для знакомства с базовыми принципами работы MongoDB и подходами к использованию документоориентированной СУБД. ИИ И НЕЙРОСЕТИ Курс по нейросетям для пользователей: работа с локальными и облачными моделями 24–25 августа Курс посвящён практической работе с современными ИИ-инструментами и выбору между локальными и облачными моделями для разных задач. DOCKER Технология контейнеризации Docker 24–28 августа Программа для специалистов, которым нужно разобраться в контейнеризации приложений и системно использовать Docker в разработке и эксплуатации. Августовский репертуар позволяет выбрать как короткий курс по конкретной рабочей задаче, так и последовательную траекторию обучения по PostgreSQL, контейнерным технологиям или работе с данными. 🔹🔹🔹🔹

🛠️ Задача осталась в processing, а воркер давно упал. Причём здесь SKIP LOCKED? Запрос очереди: SELECT id FROM jobs WHERE status = 'pending' AND retry_at <= now() ORDER BY created_at, id FOR UPDATE SKIP LOCKED LIMIT 10; SKIP LOCKED помогает воркерам не ждать строки, уже заблокированные другим потребителем. Но он не отвечает на вопросы: — жив ли воркер; — завершил ли он обработку; — нужно ли вернуть задачу; — безопасен ли повтор; — сколько попыток уже было. Есть две разные модели. Первая — держать транзакцию до конца обработки: BEGIN → заблокировать задачу → выполнить работу → поставить done → COMMIT Для короткой локальной операции это может быть допустимо. Для долгого HTTP-вызова — длинная транзакция и долгий row lock. Вторая — быстро заявить задачу: BEGIN → выбрать задачу → status = processing → worker_id, lease_until → COMMIT → выполнить работу Транзакция короткая, но восстановление после падения воркера теперь должно делать приложение. Поэтому нужны: — worker_id; — lease_until; — attempt_count; — retry_at; — last_error. Если lease истёк, задачу можно вернуть или отправить на разбор. Но нельзя автоматически возвращать все старые processing: долгие задачи могут ещё выполняться. Важно: выбор и переход в processing должны быть атомарны. Если сначала сделать SELECT, завершить транзакцию, а потом отдельным UPDATE поставить processing, другой воркер может забрать ту же задачу. ORDER BY created_at, id помогает с порядком среди доступных строк, но не гарантирует строгий FIFO при SKIP LOCKED: заблокированная старая задача может пропускаться. Чек-лист: — захват и processing в одной транзакции; — транзакция короткая; — есть lease и владелец; — done проверяет владельца; — retry ограничены; — повторная обработка безопасна; — старые pending и processing видны в мониторинге. Вывод: SKIP LOCKED — это механизм конкурентного получения доступных строк, а не полноценная очередь. Надёжность строится вокруг lease, retry, владельца и правил восстановления. Сохраните сценарий для проверки PostgreSQL-очередей, где несколько воркеров забирают задачи параллельно. 🔹🔹🔹🔹

🛠️ Часовой отчёт упал с ORA-01555. Нужно ли сразу увеличивать UNDO_RETENTION? Артефакт: ORA-01555: snapshot too old Таймлайн: 01:00 — запуск отчёта 02:04 — ошибка Параллельно шли массовые UPDATE, загрузка данных и расчётные процедуры. ORA-01555 означает: запросу понадобились undo-записи для согласованного чтения, но они уже оказались недоступны. Пока отчёт читает данные, другие транзакции могут их менять. Oracle использует undo, чтобы восстановить нужную версию данных для consistent read. Риск определяется не только SQL, а сочетанием: длительность чтения + интенсивность DML + доступное undo + фактическое retention Что собрать до изменения параметров: — точное время начала и ошибки; — обычную и фактическую длительность отчёта; — какие batch-задачи шли параллельно; — были ли массовые UPDATE, DELETE или загрузки; — сколько undo они генерировали; — хватало ли места в undo tablespace; — какое retention реально обеспечивалось; — повторяется ли ошибка в том же окне. UNDO_RETENTION может помочь, но сам по себе не гарантирует решение. Его нужно рассматривать вместе с размером undo tablespace, режимом работы undo и скоростью генерации изменений. Возможные решения после диагностики: — ускорить или сократить запрос; — перенести отчёт в другое окно; — развести отчёт и тяжёлые batch-задачи; — изменить размер или настройки undo; — пересмотреть архитектуру длительной выгрузки. Типичная ошибка: ORA-01555 → увеличить параметр → снова запустить отчёт в том же окне Без анализа нагрузки ошибка может повториться. Вывод: сначала восстановите контекст инцидента: сколько читал отчёт, какие изменения шли одновременно и как долго реально сохранялось undo. Сохраните список вопросов для разбора долгих отчётов и выгрузок, которые падают на consistent read. 🔹🔹🔹🔹

🛠️ GIN-индекс есть, но фильтр по JSONB всё равно идёт через Seq Scan Индекс: CREATE INDEX events_payload_gin ON events USING gin (payload); Запрос приложения: SELECT * FROM events WHERE payload->>'status' = 'paid'; План: Seq Scan on events Filter: ((payload ->> 'status') = 'paid') Причина может быть не в том, что PostgreSQL «не видит» индекс. GIN создан на исходной колонке payload, а запрос сравнивает результат выражения: payload->>'status' ->> возвращает text. Поэтому это равенство по вычисленному выражению, а не containment-поиск по всей jsonb-колонке. Сравните: WHERE payload @> '{"status": "paid"}'::jsonb Здесь @> применяется непосредственно к payload. Такая форма может соответствовать GIN-индексу на колонке. А здесь: WHERE payload->>'status' = 'paid' для устойчивого фильтра может потребоваться expression index: CREATE INDEX events_status_idx ON events ((payload->>'status')); Для текстового равенства это обычно B-tree expression index. Но создавать его автоматически не стоит. Проверьте: — часто ли используется именно это выражение; — сколько строк соответствует значению; — не выбирает ли запрос большую часть таблицы; — как часто изменяется JSONB; — есть ли дополнительные фильтры; — что показывают Filter, Index Cond и Recheck Cond; — как меняется план с реальными параметрами. Важно: Seq Scan сам по себе не доказывает проблему. Для маленькой таблицы или низкой селективности он может быть дешевле индекса. И не переписывайте любое равенство на @> только ради GIN. Нужно сохранить правильную семантику для отсутствующих ключей, JSON null, типов значений и вложенной структуры. Вывод: индекс «по JSONB» не является индексом для любого обращения к JSON. Сначала определите точную форму рабочего фильтра, затем выбирайте подходящий индекс. Сохраните пример для случаев, когда «индекс есть», но план всё равно показывает Seq Scan. 🔹🔹🔹🔹

🛠️ УКЦ ФОРС получил статус авторизованного учебного центра Arenadata В образовательном портфеле УКЦ ФОРС появилось новое направление — авторизованное обучение по продуктам Arenadata. Для специалистов это возможность изучать платформы управления и обработки данных по программам, согласованным с разработчиком. Для компаний — готовить команды к внедрению и эксплуатации решений, которые используются в корпоративных контурах работы с данными. Обучение охватывает несколько направлений: Arenadata DB — ADB Распределённая аналитическая СУБД для хранения и обработки больших объёмов данных. Arenadata QuickMarts — ADQM Колоночная СУБД для оперативной аналитической обработки данных. Arenadata Hyperwave — ADH Платформа для хранения, обработки и анализа структурированных и неструктурированных данных. Arenadata Streaming — ADS Инструменты потоковой передачи и обработки данных в реальном времени. Arenadata Catalog — ADC Каталог метаданных, бизнес-глоссарий и инструменты управления качеством данных. Arenadata Enterprise Data Platform — EDP Комплексная платформа для построения корпоративной инфраструктуры работы с данными. Arenadata Prosperity — ADP Универсальная реляционная СУБД на базе PostgreSQL для корпоративных сценариев. Программы могут быть полезны: — администраторам и инженерам сопровождения; — специалистам по хранилищам и большим данным; — разработчикам и архитекторам данных; — аналитикам и командам Data Governance; — компаниям, которые внедряют продукты Arenadata или планируют такое внедрение. Авторизация расширяет возможности УКЦ ФОРС по подготовке специалистов в области современных платформ данных — от СУБД и аналитических хранилищ до потоковой обработки и управления метаданными. 🔹🔹🔹🔹

УКЦ ФОРС | Обучение IT pinned a photo

🛠️ Специальные условия на ближайшие курсы по PostgreSQL 🚨 Планируете систематизировать знания по администрированию PostgreSQL, настройке производительности, резервному копированию или разработке? На ближайшие потоки в УЦ ФОРС действуют сниженные цены. Администрирование PostgreSQL FT.DBA1-18 Tantor Postgres: DBA1-18. Администрирование PostgreSQL 18 📅 24–28 августа 2026 Стоимость по акции: 28 000 ₽ вместо 40 000 ₽ PP.16.DBA1 Администрирование PostgreSQL 16. Базовый курс 📅 5–7 августа 2026 Стоимость по акции: 18 000 ₽ вместо 24 000 ₽ PP.16.DBA2 Администрирование PostgreSQL 16. Настройка и мониторинг 📅 10–14 августа 2026 Стоимость по акции: 24 000 ₽ вместо 32 000 ₽ PP.16.DBA3 Администрирование PostgreSQL 16. Резервное копирование и репликация 📅 17–18 августа 2026 Стоимость по акции: 12 000 ₽ вместо 16 000 ₽ Производительность запросов PP.16.QPT PostgreSQL 16. Оптимизация запросов 📅 19–21 августа 2026 Стоимость по акции: 22 500 ₽ вместо 30 000 ₽ Разработка на PostgreSQL PP.16.DEV1 Разработка серверной части приложений PostgreSQL 16. Базовый курс 📅 1–4 сентября 2026 Стоимость по акции: 22 500 ₽ вместо 30 000 ₽ PP.16.DEV2 Разработка серверной части приложений PostgreSQL 16. Расширенный курс 📅 7–10 сентября 2026 Стоимость по акции: 28 000 ₽ вместо 40 000 ₽ Курсы подойдут специалистам, которым нужно углубить знания по PostgreSQL, закрыть конкретные рабочие задачи или подготовиться к новым обязанностям в команде. 👉 Регистрация и подробные программы Количество мест и срок действия специальных условий рекомендуем уточнить перед регистрацией. 🔹🔹🔹🔹

📚 В плане появился external merge Disk. Нужно ли сразу повышать work_mem? Артефакт: Sort Method: external merge Disk: 184320kB Buffers: shared hit=42817 read=6932, temp read=23140 written=23208 Это значит: сортировка не поместилась в доступную рабочую память и использовала временное дисковое пространство. Но это ещё не готовая настройка. work_mem применяется не один раз на весь запрос. В одном плане могут быть несколько операций: Sort Hash Hash Join HashAggregate ещё один Sort Каждая может использовать память отдельно. Плюс есть parallel workers и другие запросы на сервере. Поэтому опасно делать вывод: увидели Disk → подняли work_mem глобально Сначала проверьте: — какой узел пишет во временные файлы; — сколько строк пришло на вход; — почему промежуточный набор такой большой; — сколько Sort/Hash-операций в плане; — есть ли параллельность; — сколько таких запросов работает одновременно; — какие work_mem и hash_mem_multiplier действуют сейчас. Disk не равен нужному значению work_mem. temp read и temp written — не размер одного временного файла. Иногда решение — не память, а более ранний фильтр, другая форма JOIN, проверка DISTINCT или ORDER BY, уменьшение диапазона данных или подходящий индекс. Но индекс — только диагностическая ветка, не автоматический ответ на любой Sort. Важно: EXPLAIN ANALYZE реально выполняет запрос. Для DML-команд он реально выполняет изменение данных. На production это нужно оценивать отдельно. Вывод: временный файл — симптом. Решение выбирают после анализа узла плана, входного объёма, числа операций и конкурентности. Сохраните признаки, по которым видно, что запрос начал платить диском за сортировку или hash-операции. 🔹🔹🔹🔹

🛠️ В двух программах по БД одинаковые темы. Как понять, где практика глубже? Сравните две формулировки лабораторной работы: «Изучить блокировки PostgreSQL». и: «Воспроизвести цепочку ожиданий, найти блокирующую сессию и обосновать безопасное действие». Обе посвящены блокировкам. Но во второй понятнее: — какой сценарий разбирает участник; — какие данные собирает; — какое решение принимает; — почему должен оценить его безопасность. Первая формулировка не обязательно означает плохую лабораторию — возможно, это только краткое название. Но по нему трудно оценить глубину практики. Что стоит запросить у учебного центра: — пример лаборатории целиком; — учебные или обезличенные артефакты, с которыми работают участники; — диагностические развилки и ошибочные гипотезы; — требование объяснить решение и риски; — формат проверки и обратной связи; — адаптацию заданий под роли и уровень группы. Важно: сложнее не всегда значит лучше. Практика должна соответствовать целям, исходному уровню, длительности курса и формату обучения. И один пример задания не характеризует всю программу, но показывает о практике больше, чем перечень тем и часов. Вывод: сравнивайте не только наличие блоков «индексы», «планы» и «backup», но и то, что участник реально делает, анализирует и обосновывает. Поможем оценить задачи команды и подобрать формат обучения с подходящей глубиной практики. 🔹🔹🔹🔹

🛠️ После deadlock транзакцию повторили. Почему внешний эффект мог выполниться дважды? UPDATE в БД → HTTP-вызов → следующий SQL → 40P01 deadlock_detected → ROLLBACK → retry PostgreSQL отменяет изменения своей транзакции. Но он не может отменить письмо, платёжный запрос или сообщение, уже отправленное другой системе. Причём результат внешнего вызова может быть неизвестен: действие могло выполниться, а ответ — потеряться. После 40P01 часто повторяют всю локальную транзакцию БД: — заново читают данные; — повторно принимают решение; — снова формируют SQL. Повторять только последний statement недостаточно. Но внешний вызов нельзя слепо повторять вместе с транзакцией. Что помогает: Идемпотентный ключ. Одна бизнес-команда использует один ключ во всех retry. Новый UUID на каждую попытку создаёт новую операцию. Получатель должен хранить ключ и корректно возвращать результат повтора. Transactional outbox. Бизнес-изменение и запись события сохраняются одной транзакцией. После commit отдельный relay публикует событие. Outbox не гарантирует exactly-once: сообщение может быть отправлено повторно, поэтому consumer должен учитывать дубликаты. Проверьте: — какие ошибки разрешено повторять; — повторяется ли транзакция целиком; — есть ли внутри внешние эффекты; — ограничено ли число попыток; — используются ли backoff и журналирование; — стабилен ли идемпотентный ключ; — что происходит при неизвестном результате вызова; — готов ли consumer к повторной доставке. Вывод: ROLLBACK защищает состояние PostgreSQL, но не отменяет действия в другой системе. Retry нужно проектировать на уровне всей бизнес-операции. 🔹🔹🔹🔹

🛠️ Нужно добавить FOREIGN KEY на большую таблицу. Что проверить до запуска? Условная миграция: ALTER TABLE orders ADD CONSTRAINT orders_customer_fk FOREIGN KEY (customer_id) REFERENCES customers (id); На большой таблице риск не только во времени проверки. В PostgreSQL 18 обычный ADD FOREIGN KEY берёт SHARE ROW EXCLUSIVE на обе таблицы. Этот режим конфликтует с обычными операциями записи, поэтому миграция может ждать сама и задерживать INSERT, UPDATE и DELETE. Для внешнего ключа проверку старых данных можно вынести в отдельный этап: ALTER TABLE orders ADD CONSTRAINT orders_customer_fk FOREIGN KEY (customer_id) REFERENCES customers (id) NOT VALID; Затем: ALTER TABLE orders VALIDATE CONSTRAINT orders_customer_fk; После первого шага: — новые INSERT и UPDATE уже проверяются; — старые строки ещё не подтверждены полностью; — ограничение остаётся невалидированным. NOT VALID не означает «без блокировок». Первый этап всё равно меняет схему. В PostgreSQL 18 валидация берёт SHARE UPDATE EXCLUSIVE на orders и ROW SHARE на referenced table. Обычный DML может продолжаться, но проверка читает данные, создаёт нагрузку и может конфликтовать с DDL и maintenance-операциями. До запуска проверьте: — версию PostgreSQL и особенности partitioned tables; — наличие нарушений; — lock mode каждой фазы; — длинные транзакции; — длительность и нагрузку проверки; — порядок выката приложения; — обработку lock_timeout, отмены и повторного запуска; — способ убедиться, что constraint действительно валидирован. Важно: lock_timeout только ограничивает ожидание блокировки. Он не гарантирует безопасное завершение миграции. Вывод: разделение на NOT VALID и VALIDATE CONSTRAINT помогает управлять риском, но не заменяет проверку версии, блокировок, данных и поведения приложения. 🔹🔹🔹🔹

🛠️ 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-профилям. 🔹🔹🔹🔹

10 сентября — Tantor JAM 2026 ! Отметим первый юбилей Tantor — пять лет с момента основания компании. За это время мы прошли путь от стартапа до технологического лидера, одного из ведущих российских разработчиков в области управления и хранения данных. Мы создали собственную экосистему продуктов и собрали вокруг себя сильное профессиональное сообщество. Программу скоро представим. Среди главных премьер: ➡️Новое поколение Платформы Tantor, основанное на AI-first подходе. Представим ИИ-администратора БД с целым роем специализированных ИИ-агентов, которые возьмут на себя рутинные операции по работе с СУБД. ➡️Реальные цифры производительности МБД Tantor XData Gen3 на различных профилях нагрузки. Покажем, как enterprise-технологии, ранее доступные только в зарубежных решениях, — независимое масштабирование Compute и Storage, RDMA, распределенная файловая система и полноценный HTAP — становятся доступны в российском ПАКе. ➡️Подробнее расскажем о Tantor Polar — новой распределенной СУБД, открывающей следующий этап развития российских PostgreSQL-технологий с полным сохранением совместимости с экосистемой Postgres. Вас ждут выступления руководителей разработки, общение с инженерами, архитекторами, заказчиками и партнерами, а также праздничная программа в честь пятилетия компании. 📅 10 сентября 2026 года, Москва ↗Регистрация уже открыта. Tantor в Max и VK