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

🛠️ В таблице далеко не два миллиарда строк, а INSERT уже не получает новый ID

Причина может быть не в количестве строк.

А в sequence.

Sequence — не счётчик сохранённых записей. Она выдаёт значения.

Если nextval() вернул номер, а транзакция потом откатилась, значение не возвращается обратно.

Поэтому:

count(*)
MAX(id)
last_value

могут различаться.

Что может расходовать sequence:

— rollback после nextval();
— конфликтующая вставка;
— прямой вызов nextval();
— CACHE;
— другие потребители sequence.

Gaps сами по себе не означают проблему.

Проблема начинается, когда генератор приближается к пределу.

С чего начать:

SELECT pg_get_serial_sequence('public.orders', 'id');

Затем параметры sequence:

SELECT
schemaname,
sequencename,
data_type,
max_value,
increment_by,
cycle,
cache_size,
last_value
FROM pg_sequences
WHERE schemaname = 'public'
AND sequencename = 'orders_id_seq';

И данные таблицы:

SELECT max(id), count(*)
FROM public.orders;

Важно: last_value — не точный следующий ID. При cache он может быть больше последнего реально выданного значения, а иногда может быть NULL.

Проверяйте оба предела:

тип ID-колонки
и
MAXVALUE sequence

Расширить integer до bigint недостаточно, если sequence осталась со старым пределом. Менять только sequence тоже бессмысленно, если колонка не принимает новый диапазон.

При NO CYCLE после исчерпания диапазона следующий nextval() завершится ошибкой.

CYCLE для PK — опасный вариант: sequence может вернуться к уже существующим ID и получить конфликт уникальности.

Главная ошибка — считать MAX(id) реальным показателем остатка sequence.

Сохраните проверку, которую стоит добавить для старых таблиц с постоянно растущим ID.

🔹🔹🔹🔹

🛠️ Подрядчик передал документацию, но при инциденте команда всё равно звонит ему

Формально handover завершён:

— wiki есть;
— схемы есть;
— runbook есть;
— демонстрации проведены.

Но первый нестандартный сбой снова требует внешнего эксперта.

Частая причина: передали знания о системе, но не проверили способность самостоятельно её эксплуатировать.

Handover лучше строить вокруг рабочих сценариев:

операция
→ рабочий артефакт
→ типовой сбой
→ действия команды
→ граница эскалации

Например: диагностика деградации сервиса.

Команда должна уметь:

— подтвердить симптом;
— построить временную линию;
— определить затронутый компонент;
— собрать логи, метрики и change history;
— выполнить согласованные диагностические шаги;
— понять, когда нужна эскалация.

Демонстрации недостаточно.

Пока подрядчик показывает решение, он использует свой контекст: знает, какой лог открыть, какую ошибку игнорировать, где runbook устарел и когда нельзя продолжать.

Проверка начинается, когда тот же сценарий выполняет внутренняя команда без пошаговых подсказок.

Практика не обязана идти в production. Можно использовать тестовый стенд, модельный инцидент, обезличенные артефакты или controlled lab.

Оценивайте не только финальный ответ:

— правильно ли выбран первый артефакт;
— отделён ли симптом от гипотезы;
— соблюдены ли границы доступа;
— вовремя ли выполнена эскалация;
— достаточно ли данных передано следующему уровню.

Runbook тоже нужно тестировать. После практики он должен становиться точнее: ссылки, доступы, критерии остановки и границы ответственности проверяются действием.

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

В УЦ ФОРС, мы поможем собрать программу обучения вокруг задач, которые команда должна принять в собственную эксплуатацию.

🔹🔹🔹🔹

🛠️ Метрика уже изменилась, а Zabbix показывает старое значение ещё несколько минут

Ситуация:

14:02 — на сервере уже видно проблему
14:07 — новое значение появляется в Zabbix
14:07 — после обработки value trigger меняет состояние

Это не всегда задержка приложения.

Сначала проверьте, не запаздывает ли сама цепочка мониторинга.

Первый артефакт:

Administration → Queue

Queue показывает delayed items — те, которые уже должны были обновиться, но задерживаются.

Важно: это логическое представление, а не обязательно физическая очередь сообщений.

Что смотреть:

1. Overview
Массовая задержка или несколько отдельных items?
2. By proxy
Проблема по всей системе или за конкретным proxy?
3. Details
Какие hosts/items задерживаются и насколько?

Не делайте вывод:

Queue большой → увеличим pollers

Причиной могут быть server processes, proxy, сеть, agent, SNMP endpoint, HTTP API, DNS, external check или другая зависимость.

Для наблюдения есть internal item:

zabbix[queue,,]

Он считает monitored items в заданном диапазоне delay.

Если используется proxy, различайте:

proxy ещё не собрал value

и

proxy собрал value,

но ещё не отправил его на server

Для backlog полезны:

zabbix[proxy_history]
zabbix[proxy_buffer,...]

Точный набор зависит от версии Zabbix и режима proxy buffer.

Что собрать:

— реальное время события;
— timestamp value в Zabbix;
— Queue overview;
— Queue by proxy;
— Queue details;
— item type;
— server/proxy internal metrics;
— proxy history/buffer backlog;
— состояние сети и endpoint.

Типичная ошибка — поздний alert сразу считать проблемой приложения.

Вывод: перед разбором наблюдаемого сервиса проверьте свежесть самих данных мониторинга.

Сохраните артефакты, которые стоит проверить, когда мониторинг начинает показывать прошлое вместо настоящего.

🔹🔹🔹🔹

🛠️ Объект удалили, но он часами остаётся в Terminating

В YAML:

metadata:
deletionTimestamp: "2026-08-19T08:15:00Z"
finalizers:
- example.com/cleanup

Первая мысль:

«Удалим finalizer вручную».

Но так можно убрать объект из API и потерять cleanup, ради которого finalizer был установлен.

Как работает finalizer:

delete request
→ API server ставит deletionTimestamp
→ объект остаётся в API
→ controller выполняет cleanup
→ controller удаляет finalizer
→ объект исчезает окончательно

Finalizer — не код. Это строковый ключ, например:

example.com/cleanup

Логику выполняет controller или operator.

Поэтому вопрос не «как стереть finalizer», а «какой компонент должен его снять и почему он не завершил cleanup».

Что проверить:

kubectl get exampleresource demo -n production -o yaml
kubectl describe exampleresource demo -n production

И точечно:

kubectl get exampleresource demo -n production \
-o jsonpath='{.metadata.deletionTimestamp}{"\n"}{.metadata.finalizers}{"\n"}'

Дальше смотрите:

— controller/operator;
— его Pod или Deployment;
— RBAC и ServiceAccount;
— events;
— logs;
— доступность внешнего API;
— состояние внешнего ресурса.

Частые причины:

— controller не работает;
— потерял права;
— внешний API недоступен;
— cleanup завершён частично;
— внешний ресурс уже в неожиданном состоянии;
— reconciliation падает с ошибкой.

Важно: events могут не содержать всю причину. Логи controller часто важнее.

Ручное удаление finalizer не всегда приводит к утечке, но риск есть. Последствия зависят от того, что именно этот finalizer должен был гарантировать.

Типичная ошибка:

объект завис
→ стерли finalizers
→ объект исчез
→ решили, что cleanup завершён

Вывод:

deletionTimestamp
→ finalizers
→ ответственный controller
→ cleanup
→ events/logs
→ внешний ресурс
→ причина сбоя
→ штатное снятие finalizer

Сохраните диагностическую последовательность для ресурсов, зависших в Terminating.

🔹🔹🔹🔹

🛠️ Restart=always настроен, но systemd больше не поднимает сервис

В status:

Main process exited, status=1/FAILURE
Scheduled restart job
Start request repeated too quickly

Причина не в том, что Restart=always перестал работать.

Restart attempts тоже подчиняются start rate limiting:

StartLimitIntervalSec=
StartLimitBurst=

Сценарий простой:

процесс стартует
→ быстро падает
→ systemd запускает его снова
→ стартов за короткий интервал слишком много
→ systemd блокирует следующий start

Главное — не перепутать причину и следствие.

Start request repeated too quickly объясняет, почему systemd сейчас не запускает unit.

Но первичная проблема — почему приложение много раз завершилось.

Проверьте:

systemctl status example.service
journalctl -u example.service
systemctl cat example.service

Ищите первое падение в серии:

— exit code;
— signal;
— Result;
— сообщение приложения перед exit;
— временную последовательность рестартов.

RestartSec= — пауза перед restart.

StartLimitIntervalSec= + StartLimitBurst= — ограничение числа запусков в интервале.

reset-failed может сбросить failed state и счётчики, но не исправляет приложение.

Типичная ошибка — сразу увеличить StartLimitBurst.

Если сервис падает из-за той же ошибки, вы просто продлите restart loop.

Вывод:

причина падения
→ Restart=
→ RestartSec=
→ частота start attempts
→ StartLimit*
→ только потом изменение unit

Сохраните, что проверять до изменения StartLimitBurst и StartLimitIntervalSec.

🔹🔹🔹🔹

🛠️ После обновления ОС PostgreSQL пишет collation version mismatch

Не спешите выполнять:

ALTER COLLATION ... REFRESH VERSION;

Эта команда уберёт warning, но не проверит, что зависимые объекты перестроены.

Почему это важно?

Collation задаёт правила сравнения и сортировки строк.

Если после обновления glibc или ICU правила изменились, индексы и другие объекты могли остаться построенными по старому порядку.

Что проверить:

— точный warning;
— имя collation;
— collprovider;
— записанную версию collversion;
— фактическую версию через pg_collation_actual_version(oid);
— явные зависимости через pg_depend;
— не затронута ли default collation базы.

Для default collation базы есть отдельные сущности:

pg_database.datcollversion
pg_database_collation_actual_version(oid)
ALTER DATABASE ... REFRESH COLLATION VERSION

После этого определяют scope rebuild.

Для индексов может потребоваться REINDEX, но REINDEX DATABASE не должен быть первой реакцией. Нужно оценить размер объектов, блокировки, WAL, диск, репликацию и окно обслуживания.

Типичная ошибка:

warning
→ REFRESH VERSION
→ warning исчез
→ считаем, что всё исправлено

Но REFRESH VERSION только обновляет записанную версию в системном каталоге.

Правильный порядок:

mismatch
→ зависимости
→ безопасный rebuild
→ проверка
→ REFRESH VERSION

Вывод: collation mismatch — это не косметика. После обновления ОС нужно проверить, какие объекты могли зависеть от старых правил сравнения.

Сохраните последовательность проверки collation после обновления ОС или ICU.

🔹🔹🔹🔹

🛠️ Формальный заместитель есть. Но во время инцидента все всё равно звонят одному эксперту

У резервного специалиста могут быть доступы, документация и записи обучения. Но это ещё не означает, что он сможет:

— распознать проблему;
— собрать нужные данные;
— выполнить разрешённое действие;
— остановиться у границы риска;
— вовремя эскалировать.

Курс даёт знания по технологии. Резервная роль требует ещё практики, полномочий, актуального 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
kubectl describe 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//limits:
Max open files 4096 4096 files
открытых FD: 3987

Причина может быть в RLIMIT_NOFILE — лимите файловых дескрипторов процесса.

FD — это не только файл. Лимит расходуют сокеты, pipe, epoll, eventfd, inotify и другие объекты.

Поэтому сетевой сервис может упасть на accept(): для нового соединения нужен новый дескриптор, а процесс уже близко к лимиту.

Что проверить:

1. Фактический лимит процесса

cat /proc//limits

Не ориентируйтесь только на ulimit -n в административной shell: systemd-сервис может запускаться с другим LimitNOFILE.

2. Текущее число FD

ls /proc//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

🛠️ Часовой отчёт упал с 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.

🔹🔹🔹🔹