Oracle ошибка ora 01555

Обновлено: 07.07.2024

500, строку 20001 и т.д. При выполнении запроса блоки считываются в случайном порядке и, вероятно, по несколько раз. Вероятность возникновения ошибки ORA-01555 в этом случае составляет почти 100 процентов. Итак, в одном сеансе выполним:

tkyte@TKYTE816> create rollback segment rbs small

3 (initial 8k next 8k

4 minextents 2 maxextents 3)

5 tablespace rbs test

Rollback segment created.

tkyte@TKYTE816> alter rollback segment rbs small online; Rollback segment altered.

tkyte@TKYTE816> create table t

4 from all objects

tkyte@TKYTE816> create index t idx on t(object id)

2 / Index created.

2 for x in (select rowid rid from t)

5 set transaction use rollback segment rbs small;

7 set object name = lower(object name)

8 where rowid = x.rid;

Пока выполняется этот блок PL/SQL, в другом сеансе выполним:

tkyte@TKYTE816> select object name from t where object id > 0 order by object id;

/91196853 activationactivation ERROR:

ORA-01555: snapshot too old: rollback segment number 10 with name RBS SMALL too small 3150 rows selected.

tkyte@TKYTE816> select count(*) from t; COUNT (*) 21773

Данные извлекаются в нескольких транзакциях

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

l cnt number default 0; for x in (select rowid rid, loop

t.* from t where object id

if (mod(l cnt,100) then

set transaction use rollback segment rbs small; end if; update t

set object name = lower(object name) where rowid = x.rid; l cnt := l cnt + 1; end loop; commit;

ERROR at line 1:

ORA-01555: snapshot too old: rollback segment number 10 with name RBS SMALL too small ORA-06512: at line 4

Здесь выполняется случайное чтение таблицы Т по индексу. Мы изменяем по одной строке за раз в цикле. После изменения 100 строк транзакция фиксируется. Рано или поздно мы повторно обратимся в запросе к блоку, уже измененному оператором UPDATE, и этот блок уже не удастся восстановить по сегментам отката (поскольку данные в них давно перезаписаны). Теперь мы попали в неприятную ситуацию: процесс изменения завершился неудачей на полпути.

Можно, как было показано в главе 4, придумать более изощренный метод изменения данных. Например, найти минимальный и максимальный идентификатор OBJECT ID. Можно поделить этот диапазон на поддиапазоны по 100 строк и делать изменения, записывая в другую таблицу информацию об успешно выполненных действиях. Это позволит реализовать процесс, который должен быть реализован одним оператором и одной транзакцией, в виде множества отдельных транзакций, организованных с помощью сложного процедурного кода таким образом, чтобы они могли быть перезапущены в случае сбоя. Например:

Snapshot too old

Ответ Тома Кайта

Мне кажется, документ службы поддержки <Note:40689.1> очень хорошо раскрывает эту тему:

Обзор

Терминология

Предполагается, что читатель знаком со стандартными терминами Oracle, такими как "сегмент отката" и "SCN". В противном случае, необходимо сначала прочитать руководство Oracle Server Concepts и другую соответствующую документацию Oracle.

Кроме этого, ниже кратко рассмотрены два ключевых понятия, которые помогут понять причины возникновения ошибки ORA-01555 :

Это понятие описано с руководстве Oracle Server Concepts и поэтому детально не обсуждается. Однако для понимания этой статьи соответствующий раздел руководства надо прочитать и понять, если вы его еще не поняли.

Сервер Oracle обеспечивает многоверсионную согласованность по чтению, ценную возможность, гарантирующую получение согласованного представления данных (отсутствие "грязных чтений").

Это лучше всего проиллюстрировать примером: рассмотрим транзакцию, изменяющую таблицу с миллионом строк. При этом для изменения данных, очевидно, надо посетить большое количество блоков данных. Когда пользователь фиксирует транзакцию, сервер Oracle НЕ проходит повторно по всем этим блокам, чтобы зафиксировать изменения. Это действие выполнит следующая транзакция, которая обратится к любому блоку, затронутому изменением, - она "очистит" его (отсюда и термин " отложенная очистка блока ").

При любом изменении блока базы данных сервером Oracle (блока индекса, таблицы, кластера), он сохраняет указатель в заголовке блока данных, который идентифицирует сегмент отката, использовавшийся для хранения данных отката для изменений, выполненных транзакцией. (Они понадобятся, если в дальнейшем пользователь решит не фиксировать изменения и захочет их "отменить".)

При фиксации сервер просто помечает соответствующую запись в заголовке сегмента отката как зафиксированную. Теперь, когда один из измененных блоков посещается снова, сервер Oracle проверяет заголовок блока данных, показывающий, что блок был изменен в определенный момент. Серверу надо разобраться, было ли это изменение зафиксировано или оно еще не зафиксировано. Для этого сервер Oracle оперделяет, какой сегмент отката использовался предыдущей транзакцией (по заголовку блока), а затем определяет по заголовку этого сегмента отката, была ли транзакция зафиксирована или нет.

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

Это поведение сервера в очень упрощенном виде проиллюстрировано ниже. Мы пройдем по стадиям изменения блока данных.

СТАДИЯ 1 - Нет изменений

СТАДИЯ 2 - Изменяется строка 2

Описание:

Мы изменили строку 2 блока 500. Обратите внимание, что заголовок блока данных изменен и указывает на сегмент отката 5, слот транзакции 3 (5.3), и что транзакция помечена как незафиксированная (Active).

СТАДИЯ 3 - Пользователь фиксирует транзакцию

Описание:

Затем пользователь выполняет фиксацию. Учтите, что при этом изменяется только слот соответствующей транзакции в заголовке сегмента отката - транзакция помечается как зафиксированная. С данными в блоке не делается ничего .

СТАДИЯ 4 - Другой пользователь выбирает данные блока 500

Объяснение ошибки ORA-01555

Есть две основные причины возникновения ошибки ORA-01555 , которые являются следствием попыток сервера Oracle получить "согласованный по чтению" образ данных:

Сами данные отката перезаписаны, так что сервер Oracle не может откатить (зафиксированные) записи транзакции для получения достаточно давней версии блока.
Слот транзакции в таблице транзакций сегмента отката (которая хранится в заголовке сегмента отката) перезаписан, и сервер Oracle не может откатить заголовок сегмента отката до такой степени, чтобы можно было получить исходный слот транзакции в сегменте отката.

СИТУАЦИЯ 1 - ДАННЫЕ ОТКАТА ПЕРЕПИСАНЫ

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

Сеанс 1 начинает запрос в момент времени T1 при QENV 50
Сеанс 1 выбирает блок B1 в ходе этого запроса
Сеанс 1 изменяет этот блок при SCN 51
Сеанс 1 выполняет другие действия, генерирующие данные отката.
Сеанс фиксирует изменения, выполненные на шагах 3 и 4.
(Теперь другие транзакции могут переписывать соответствующие данные отката)
Сеанс повторно обращается к тому же блоку B1 (возможно, в поисках другой строки).

Теперь сервер Oracle может понять по заголвоку блока, что блок был изменен, причеми, позже, чем требуемая QENV (которая соответствовала SCN 50). Поэтому необходимо получить образ блока по состоянию на эту QENV.

Если достаточно старую версию блока можно найти в буферном кэше, она и будет использована, иначе необходимо откатить текущий блок, чтобы сгенерировать другую его версию, соответствующую требуемой среде QENV.

СИТУАЦИЯ 2 - ПЕРЕПИСАН СЛОТ ТРАНЗАКЦИИ В СЕГМЕНТЕ ОТКАТА

Сеанс 1 начинает запрос в момент времени T1 при QENV 50
Сеанс 1 выбирает блок B1 в ходе этого запроса
Сеанс 1 изменяет этот блок при SCN 51
Сеанс 1 фиксирует изменения.
(Теперь другие транзакции могут переписывать соответствующие данные отката)
Сеанс (сеанс 1, другой сеанс или несколько других сеансов) затем использует тот же сегмент отката для выполнения ряда зафиксированных транзакций.

Каждая из этих транзакций использует слот в таблице транзакций сегмента отката, так что со временем придется использовать слоты с начала таблицы (слоты в таблице используются циклически) и все их переписывать. Учтите, что сервер Oracle свободно может повторно использовать эти слоты, потому что все транзакции зафиксированы.

Затем, сервер Oracle пытается найти слот транзакции в заголовке сегмента отката, на который указывает заголовок блока данных. При этом сервер понимает, что это слот был преписан и пытается откатить изменения, выполненные в заголовке сегмента отката, чтобы получить исходную запись слота транзакции.

Можно также обнаружить вариант слота транзакции, переписанный при очистке блока. Эта ситуация кратко описана ниже:

Сеанс 1 начинает запрос при QENV 50. После этого другой процесс изменяет блоки, которые понадобятся сеансу 1. Когда сеанс 1 встречает эти блоки, он определяет, что блоки изменились и еще не были очищены (с помощью отложенной очистки блоков). Сеанс 1 должен определить, были ли в дальнейшем изменены строки блока, существовавшие при QENV 50.

Для этого сервер Oracle должен просмотреть соответствующий слот таблицы транзакций сегмента отката, чтобы определить значение SCN для фиксации. Если этот SCN - после QENV, сервер Oracle должен попытаться построить прежнюю версию блока, а если до, достаточно просто выполнить очистку блока, и он будет вполне соответствовать QENV.

( Примечание: Обычно сервер Oracle может использовать алгоритм определения значения SCN блока в ходе очистки блока, даже если транзакции в сегменте отката был переписан. Но в этом случае сервер Oracle не может гарантировать, что версия блока не изменилась с момента начала запроса).

Решения

СИТУАЦИЯ 1 - ДАННЫЕ ОТКАТА ПЕРЕПИСАНЫ

Увеличьте размер сегмента отката, что снизит вероятность переписывания необходимых данных отката.
Сократите количество фиксаций (та же причина, что и для решения 1).
Выполняйте обработку данных по частям, а не всей таблицы сразу (та же причина, что и для решения 1).
Добавьте дополнительные сегменты отката. Это позволит распределить изменения по большему количеству сегментов отката, тем самым, сократив вероятность перезаписи требуемых данных отката.
При выборе данных в нескольких транзакциях можно изменить код так, чтобы этого не делать.
Сделайте так, чтобы внешний select не обращался к одним и тем же блокам в различные моменты времени по ходу обработки. Для этого:
- Используйте полный просмотр таблицы вместо поиска по индексу
- Добавьте избыточную сортировку, так, чтобы все данные извлекались, сортировались, а затем полученные блоки данных просматривались последовательно.

СИТУАЦИЯ 2 - ПЕРЕПИСАН СЛОТ ТРАНЗАКЦИИ В СЕГМЕНТЕ ОТКАТА

ПЕРЕЗАПИСЬ ДАННЫХ ОТКАТА

ПЕРЕЗАПИСЬ СЛОТА ТРАНЗАКЦИИ В СЕГМЕНТЕ ОТКАТА

Специальные случаи

Резюме

Оригинал обсуждения этого вопроса можно найти здесь.

Результаты опроса подписчиков. Возможно, первый из серии авторских выпусков, посвященных индексам. Или перевод очередного блестящего ответа Тома Кайта. Следите за новостями на сайте проекта Open Oracle.

curblk будет все время увеличиваться, по достижению конца экстента увеличится curext и wraps. При чем это будет происходить даже после commit и неактиквости предыдущих транзакций.

Также в этом аспекте надо рассмотреть понятие блокирующей транзакции. Это активная транзакция которая не позволяет записывать ниже своих блоков в rollback segment информацию для транзакций, начавшихся позже. Поэтому если мы достигли верхнего экстента в нашем rollback segment и есть некая транзакция лежащая ниже в блоках, то произойдет не переход транзакции на первый экстент а расширение существующего rollback segment. Так если мы достигли предела по памяти в текущем табличном пространстве то выдастся ошибка.
С одной стороны неконтролируемые блокирующие транзакции – это не есть гуд.
С другой стороны контролируемые блокирующие транзакции – могут сыграть на руку в деле о “Неперзаписываемости непротиречивых данных»

По тому свойству что
1) Транзакциям всегда назначаются более верхние блоки и по заполнению экстента и более верхние экстенты rollback segment, даже если расстояние между эти экстентом и первым екстентом нашего rollback segment будет большим и активных транзакций между ними не будет.
2) Не назначается начальный екстент по завершению кол-ва экстентов rollback segment пока ниже есть активная транзакция, а делается попытка создать новый экстент в rollback segment.

То есть всего то нужно перед большим селектом данных
1) записать в каждый rollback segment откатную информацию для транзакции и не завершать ее до завершения селекта
2) Мониторить место в табличном пространстве, чтобы всегда хватало места для последующих выделений екстентов. И также мониторить выделение экстентов в существующих роллбеках.

перед выполнением долгоиграющего запроса необходимо в каждом rollback segment открыть одну такую блокирующую транзакцию . Достаточно даже одной UNDO_RECORD для этого. то есть например есть таблица t1 (id integer).
Далее перед началом селекта мы открываем столько сессий сколько у нас открытых роллбек сегментов в системе, каждой сессии назначается свой роллбек сермент (set transaction use rollback segment RBS_NAME)
И делается insert into t1 values (1);
И все. когда в каждом сегменте будут такие блокирующие транзакции то никакая следующая не перезатрет блоки старой транзакции, потому что выделяться будут более старшие (в номерах) блоки и экстенты, а при достижением конца rollback segment будет попытка создать новый экстент из за блокирующей транзакции.

Единственно я никак не могу проверить, а перезапишется ли transaction slot в заголовке rollback segment содержащий неактивную транзакции если транзакций много в системе. Но это на самом деле достаточно низкая вероятность и вероятность попадания уменьшается с ростом размера блока.
в 8 Кб блоке слотов для транзакций 0x8C штук

Ни в коем случае не хотел вас обидеть или отобрать copyright у Адамса. Я не мог сказать что узнал это от Адамса, потому что узнал это не от него ;-)
кстати каждый день для себя открываю что то новое , и это не значит что это не открыли до меня .
посмотрите на мой ник и вы поймете почему я так радуюсь вновь открытым методам(для себя) и хочу их ессно донести до широких масс ;-)

Ну, а если требуется 100% гарантия - то есть второй способ - уволиться, т.к. обсуждаемый здесь способ 100% гарантию тоже не дает (скажем, одна из блокирующих сессий не запустилась, свалилась и т.д. и т.п.).

Полное решение ORA-1555 Снимок слишком старый Принцип ошибки и решение

Сообщество DBaplus | 2016-02-24 06:47

Будет ли ваша задача управлять базой данных Oracle или разработать, поддерживать приложение на Oracle, обычно вы столкнулись с ошибкой, такой как ORA-01555: Snapshot слишком старый. Эта статья для вас объяснить причины ошибки и лучшего решения.

Давайте посмотрим, что производится ORA-01555:

Где запись ошибки?

Обычно эта ошибка может появиться в следующих файлах:

1 файл журнала тревоги оповещения

ORA-01555: snapshot too old: rollback segment number 107 with name "_SYSSMU107_1253191395$" too small

2 Журнал для отслеживания файлов, когда проблема возникает

По умолчанию ошибка ORA-01555 не генерирует файл журнала отслеживания, когда он возникает. Но вы можете установить следующее событие в системе, чтобы он сгенерирован одновременно в ошибке:

alter system set events '1555 trace name errorstack level 3';

После настройки 1555 событий после появления ошибки будет сгенерирован соответствующий файл журнала, следующим образом:

Корневая причина ошибки в ORA-01555 заключается в том, что блок отменить перезаписан, и оператор запроса не может получить копию данных, построенных во время оператора запроса.

Некоторые из причин известны следующим образом:

1 Увеличивая запись соответствующих данных строки истек

Истечение срока действия вот что текущее время (при возникновении ошибки), время подачи данных превысило набор NONDO_RETEDENY. После того, как записанная запись, соответствующая записи «срок действия» состояния, эта часть пространства может быть повторно использована, и данные могут быть перезаписаны.

Вы можете спросить, почему иногда мы столкнулись с ошибкой ORA-01555, время выполнения запроса намного дольше, чем Undo_retency, иногда он короткий? Это не имеет четкого ответа.

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

Совет: запись отмены, соответствующая активной или необдуманной транзакции, будет помечена как «активное» состояние. После отправки транзакции соответствующая запись отменена как «нерешенная», которая будет длиться в течение определенного периода времени (на этот раз определяется параметром UNDO_RETRION, если используется автоматическое управление сегментом восстановления, он определяется Tuned_undOretention, Значение параметра автоматически оценивается), после этого времени эта запись отменяется как «срок действия», что можно повторно использовать.

2 Состояние записи NEDO соответствующей строки данных не истекло, но он все еще перезаписывается.

Это происходит 2 необходимых условия:

Нечего устанавливать гарантию удержания для отмены табличного пространства

Отменить табличное пространство заполнено

В это время отмена записи «Неуправляемое» государства может быть перезаписано.

Копия чтения консистенции сегмента лоб сегмента 3LOB больше не доступна.

В зависимости от того, как настроен поле LOB, подряд по-прежнему не является ROT, поле LOB режима In-ROT использует тот же алгоритм отменить, как обычный ряд в табличном пространстве.

Поле лобного метода вне строки отличается. Его копии чтения C согласованности имеют следующие два типа управления:

1) старый путь: pctversioin

Этот параметр связан с равномерным чтением данных LOB, что означает, что табличное пространство, в котором поле LOB таблицы необходимо зарезервировать максимальный процент префаты, используемого для LOB, значение по умолчанию 10. То есть до тех пор, пока данные предыдущего изображения поля LOB не покрываются не более чем на 10%, оно не покрывается.

2) Новый путь (автоматическое управление сегмента восстановления): удержание

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

Таким образом, ORA-1555 возникает в заявлении поля Лоб, означает:

Использование предыдущего изображения поля LOB превысило Pctversion, а данные согласованности перезаписываются.

В качестве альтернативы, изображение поля LOB превышает значение удержания, до того, как произойдет запрос, изображение поля LOB некоторых строк было перезаписано, поэтому триггер ORA-1555.

1 Проверьте информацию журнала ошибок

1) Откатный откатчик слишком маленький

ORA-01555: Снимок слишком старый: откат сегмента номер с именем "" Слишком маленький (внимание . Имя раздела отката здесь пусто)

ORA-22924: snapshot too old

Это описание ошибки заключается в том, что доступ к удаленным данным является тип поля LOB. Поле LOB Доступ к ошибке ORA-1555 обычно вызывается следующими причинами:

Повреждение секции Лоб

Проверка ссылки MOS Документ Эта проблема:

Document 452341.1 ORA-01555 And Other Errors while Exporting Table With LOBs, How To Detect Lob Corruption

Если нет повреждения LOB, проверьте значение Runtion / Pctversion.

Обратитесь к Mos Documentation, подтвердите, что необходимо отрегулировать сплав / pctversion:

Document 846079.1 LOBs and ORA-01555 troubleshooting

ORA-01555: snapshot too old: rollback segment number 107 with name "_SYSSMU107_1253191395$" too small

Этот отчет об ошибке ORA-1555 является ошибкой при доступе к пространству табличного пространства отмены табличного пространства, и использует следующий метод для диагностики проблемы.

2) Когда потребление запроса слишком длинно

Когда возникают некоторые ошибки ORA-1555, количество секунд, когда сбой запроса во время журнала предупреждения или журнал приложения:

ORA-01555 caused by SQL statement below (Query Duration=1974 sec, SCN: 0x0002.bc30bcf7):

Если вы найдете журнал ошибок, длительность = 0 или трудоемкость очень короткое, проверьте следующий документ:

Document 1131474.1 ORA-01555 When Max Query Length Is Less Than Undo Retention, small or 0 Seconds

Если запрос превысит значение UNDO_RETRION, рассмотрите увеличение раздателя, при при запомнении размера табличного пространства отменить.

Продолжайте смотреть на текст, если запрос равен или близко к Undo_retriion.

2 Проверьте файл данных UNDO

Если файл данных UNDO не выключает автоматическое расширение, это может привести к высоким значением Tuned_undoRetenceence, поэтому пространственное назначение от отмены смещены с большим количеством пространства. Как это сломано? Используя функцию автоматического расширения файла данных, даже если вы храните доступное пространство, вы также приносите Maxsize.

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

3 Проверьте tuned_undoretention.

1) Tuned_undoRetection меньше, чем maxquerylen

Эта ситуация указывает на то, что пространство от отмены имеется пространство пространства, а фактически сохраненная запись отмены меньше, чем теоретическая.

Раствор должен расширить пространство отменить таблично.

2) Tuned_undoRetention намного больше, чем maxquerylen

Обычно файлы данных в табличном пространстве отмены выключены. Внутренний алгоритм является как можно дольше, чтобы отменить записи, поэтому значение Tuned_redention будет относительно высоким.

Решение состоит в том, чтобы установить все файлы данных UNDO в автоматические расширения и плюс опция Maxsize.

Долгосрочные операторы для выполнения запросов также получат ценность Tuned_redention. Эта ситуация есть. Чтобы оптимизировать оператор SQL, чтобы избежать чрезмерных данных отмены в табличном пространстве отмены.

Через следующее утверждение, какие операторы запроса потребляются дольше:

3) Государство представляет собой высокую долю отказа от активных / не выдержанных

Следующие случаи могут привести к большому количеству активных / нерешенных состояний UNDO:

Undo_retency или Tuned_doRetention Value большой

Большое количество данных отмены генерируется в определенный момент времени. Диагностировать следующее утверждение:

Большое количество погибших отката

Используйте запрос данных во Flashback

Для получения информации о состоянии государства активно вы можете увидеть:

Document 1337335.1 How To Check the Usage of Active Undo Segments in AUM

Рекомендуется установить значение Undo_retriion по меньшей мере половины maxquerylen. Если возникает ошибка ORA-1555, она соответственно большая.

На данный момент закончено, что принципы и диагностики ошибок ORA-01555 завершены.

About Me

Эта статья исходит из WeChat Public Number Reprement статьи, если есть нарушение, пожалуйста, свяжитесь с саженцами пшеницы вовремя

QQ: 642808185 Если вы добавите QQ, укажите название статьи, которую вы читаете.

[Авторское право, артикул разрешено, но адрес источника должен быть проложена в режиме связи, иначе исследуется юридическая ответственность]

Читайте также: