🛠️ Часовой отчёт упал с 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.
🔹🔹🔹🔹
Артефакт:
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.
🔹🔹🔹🔹