Undo oracle что это

Обновлено: 04.07.2024

Традиционно, данные для отката транзакции хранятся в сегментах отката, до момента фиксации или отмены транзакции, путем выполнения COMMIT или ROLLBACK. Автоматическое управление UNDO, позволяет DBA указать, как долго хранить информацию после завершения транзакции, таким образом позволяя избежать ошибки: snapshot too old, при выполнении длительных запросов.

Это достигается путем установки параметра UNDO_RETENTION. По умолчанию, его значение равно 900 секунд (15 минут), и изменяя этот параметр вы можете гарантированно увеличить, или уменьшить сроки хранения информации для отката.

По большому счету, вы можете переложить на Oracle управление сегментами отката, вместо того, чтобы заниматься этим самому. Для включения автоматического управления, необходимо указать всего лишь один параметр UNDO_MANAGEMENT=AUTO. Если же требуется вернуть ручное управление, то значение параметра выставляется равным MANUAL.

В сегментах отката есть три типа экстентов:

Unexpired - Данные, чей возраст не превысил период хранения, определяемый параметром UNDO_RETENTION
Expired - Данные, чей возраст превысил период хранения, определяемый параметром UNDO_RETENTION. Эти экстенты больше не нужны для согласованного чтения.
Active - Данные, являющиеся частью активной транзакции. Параметр UNDO_RETENTION не применим к таким экстентам, потому что никто не может сказать заранее, как быстро завершится транзакция, и, например, через 900 секунд вы не сможете выполнить откат.

Последовательность использования экстентов выглядит следующим образом:

Новый экстент в табличном пространстве UNDO выделяется по мере возникновения потребности. Если достигается конец текущего экстента, и следующий экстент содержит данные с истекшим сроком жизни, то новые данные (генерируемые текущей транзакцией) будут записаны в этот экстент, содержащий старые данные.
Если это не удается, из-за отсутствия доступных свободных экстентов, и отключена возможность автоматического расширения файла данных (AUTOEXTEND), то Oracle будет пытаться использовать экстенты с истекшим сроком давности из другого сегмента UNDO.
Если попытка использовать экстенты другого сегмента не удается, то Oracle пытается использовать повторно экстенты, имеющие статус UNEXPIRED, в текущем сегменте отката.
Если такая попытка терпит неудачу, то Oracle пытается использовать UNEXPIRED экстенты в других сегментах.
Если все предыдущие попытки не увенчались успехом, то Oracle сообщит о недостатке свободного пространства, например: ORA-30036: unable to extend segment in Undo tablespace

Далее представлены несколько запросов, которые помогут отслеживать использование UNDO:
Статус UNDO:

TABLESPACE_NAME STATUS GB
------------------------------ --------- ----------
UNDOTBS EXPIRED 2.65649414
UNDOTBS UNEXPIRED 5.47167969
UNDOTBS ACTIVE .015625

3 rows selected.

Блоков UNDO в секунду:

Оптимальное значение UNDO RETENTION при текущей активности:

ACTUAL UNDO SIZE [MByte] UNDO RETENTION [Sec] OPTIMAL UNDO RETENTION [Sec]
------------------------ ------------------------- ----------------------------
8000 900 6787
1 row selected.

Подсчет необходимого размера табличного пространства UNDO при текущей нагрузке:

ACTUAL UNDO SIZE [MByte] UNDO RETENTION [Sec] NEEDED UNDO SIZE [MByte]
------------------------ ------------------------- ------------------------
8000 900 1060.85156
1 row selected.

Примеры состояния экстентов

Представленный ниже запрос позволяет увидеть текущее состояние экстентов и их статус. На основании результатов можно сделать определенные выводы и скорректировать, при необходимости, параметры базы данных, касающиеся UNDO:

Запрос суммирует три типа экстентов и показывает разбиение по ним содержимого табличного пространства UNDO. Свободные сегменты не учитываются.

Нормальная ситуация

STATUS MB PERC
--------- ---------- ----------
ACTIVE 10 4
EXPIRED 110 43
UNEXPIRED 25 10

Это пример нормальной ситуации. Система использует экстенты со статусом ACTIVE, некоторые экстенты, со статусом UNEXPIRED, используются для согласованного чтения и экстенты со статусом EXPIRED, могут быть использованы повторно.

Отсуствие свободных/EXPIRED экстентов

STATUS MB PERC
--------- ---------- ----------
ACTIVE 230 90
EXPIRED 0 0
UNEXPIRED 26 10

Если система находится под нагрузкой, и экстентов со статусом EXPIRED нет, или их количество близко к нулю, а общее количество активных (ACTIVE) и не устаревших (UNEXPIRED) экстентов близится к 100%, и табличное пространство UNDO не может быть расширено, то Oracle начинает заимствовать экстенты со статусом UNEXPIRED, для текущих транзакций. Это может привести к ошибке ORA-01555, потому что не удовлетворяется требование UNDO_RETENTION.

Отсуствие свободного пространства в табличном пространстве UNDO

STATUS MB PERC
--------- ---------- ----------
ACTIVE 255 100
EXPIRED 0 0
UNEXPIRED 1 0

Большой период удержания или маленький размер UNDO

STATUS MB PERC
--------- ---------- ----------
ACTIVE 2 1
EXPIRED 0 0
UNEXPIRED 254 99

В этом случае, все UNDO экстенты используются для обеспечения периода удержания (UNDO_RETENTION). Это может быть связано со слишком большим значением времени удержания, или табличное пространство UNDO слишком маленькое. В этом случае DBA должен принять решение, как быть.

Размер UNDO

Хранение данных для отката операций требует определенного места на дисковой системе, и определяется исходя из активности использования базы данных. В самом простом варианте, для расчета, можно применить формулу RETENTION * RATE = SPACE. Плюс добавятся накладные расходы, но в целом общую картину можно получить.

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

Начиная с Oracle 10g, использование становится более эффективным, если одна и та же запись обновляется более одного раза в пределах транзакции. В этом случае экстенты со статусом ACTIVE используются повторно.

Фиксированный размер

Если отменить автоматическое расширение (для файла данных установить AUTOEXTEND=NO), то Oracle автоматически настроит время удержания (UNDO RETENTION), чтобы вписаться в размер табличного пространства. Параметр UNDO_RETENTION будет использоваться по минимуму, но может быть автоматически настроен на большее значение, при наличии свободного пространства.

Проверить настроенное значение для UNDO_RETENTION можно выполнив запрос к представлению V$UNDOSTAT, колонка TUNED_UNDORETENTION.

В Oracle 9i, нет автоматической настройки, но есть возможность изменения времени удержания.

Для определения фиксированного размера табличного пространства, можно воспользоваться советом Undo Advisor.

STATUS MB PERC
--------- ---------- ----------
ACTIVE 2 1
EXPIRED 0 0
UNEXPIRED 254 99

Поскольку Oracle может продлить время удержания, то создается большее количество экстентов со статусом UNEXPIRED. В этом случае возможно заполнение табличного пространства. Если табличное пространство заполнено, проверьте TUNED_UNDORETENTION против UNDO_RETENTION, если настроенное значение больше, то заполненность на 99% не означает наличие проблемы.

Посмотрим на следующий запрос, он рассчитывает UNDO со следующими допущениями: ACTIVE - берется то, что требуется, EXPIRED - пустые и UNEXPIRED расчитывается как деление UNDO_RETENTION на TUNED_UNDORETENTION:

Полученный при выполнении запроса результат покажет, что UNDO_RETENTION = 900 и TUNED_UNDORETENTION равен примерно 1800 секунд:

UNEXPIRED экстенты на самом деле не проблема, потому что автоматически настроенное время удержания (TUNED_UNDORETENTION) в два раза больше чем желаемое, установленное пользователем (UNDO_RETENTION).

Начиная с Oracle 10g Release 2 введено максимальное время удержания. Наиболее длинный период, что встречался в моей практике - 72 часа. При этом пользователи не испытвали никаких проблем при работе с приложениями. Автоматическую настройку можно отключить, используя скрытый параметр _undo_autotune, и установив его значение равным false: _undo_autotune=false. Использовать его без разрешения Oracle не желательно. Дополнительно можно посмотреть документ My Oracle Support: ID 413732.1 : Full UNDO Tablespace In 10gR2.

Фиксированный размер и автоматическая настройка UNDO_RETENTION

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

Усечение (SHRINK) табличного пространства UNDO

Уменьшить табличное пространство UNDO нельзя, можно только увеличить. Если же необходимо уменьшить размер, топ ридется создать новое табличное пространство, обозначить его как используемое по умолчанию, выставив параметр UNDO_TABLESPACE, и удалить старое. Более подробно об этом рассказано в статье "Oracle: Изменение табличного пространства UNDO".

Установка RETENTION GUARANTEE

Следует помнить, что при создании UNDO с опцией RETENTION GUARANTEE, экстенты со статусом UNEXPIRED не будут заимствоваться для других транзакций. Устанавливать эту опцию можно, если планируется использовать целостное чтение или если планируется использовать FLASHBACK.

Но прежде чем выставлять эту опцию, стоит учесть, что вероятность получения ORA-30036 возрастает. И возможно, вам придется выбирать между ORA-30036 и ORA-01555.

Установка параметра UNDO_RETENTION на основании самого длинного запроса

Распространенной практикой является установка параметра UNDO_RETENTION равным времени выполнения самого длинного запроса, что бы избежать ошибки ORA-01555. Для получения информации о самом длинном запросе, за последние 7 дней, выполните запрос:

Так же можно попробовать выполнить запросы к представлениям V$SESSION_LONGOPS и V$TRANSACTION.

Главным достоинством сегментов undo является то что они управляются автоматически, но вы должны установить ограничения в границах которых Oracle будет осуществлять управление. После того как вы рассмотрели объем данных и активность вашей БД вам нужно установить некоторые параметры и определить размеры табличных пространтсв undo.

Ошибки связанные с undo

Принципы очень просты: во первых, всегда должно быть достаточно места для undo чтобы все транзакции могли работать и, во вторых, всегда должно быть достаточно данных undo чтобы запросы выполнились успешно. Первый принцип требует чтобы табличное пространство undo было достаточно большим чтобы накапливать undo данные для худшего сценария. Должно быть выделено достаточно места для хранения данных во время пиковой нагрузки. Обратите внимание что это не значит в момент максимального количества конкурирующих транзакций; во время обычной работы у вас может быть много транзакций, но суммарное количество данных undo которые они сгенерируют будет гораздо меньше чем сгенерирует одна долгая транзакция запускаемая в конце месяца. Второй принцип требует наличие в табличном пространстве места для хранения неустаревших данных которые могут требоваться для согласованности чтения.

Если транзакции недостаточно места, последний запрос выполнится с ошибкой ORA-30036 “unable to extend segment in undo tablespace”. Запрос будет отменён, но все остальные запросы внутри транзакции останутся выполненными и неподтверждёнными. Алгоритм которы выделяет место для undo сегментов внутри табличного пространтсва undo вызовет такую ошибку только если табличное пространтсво полностью состоит из активных данных.

Если DML запрос выполняется с ошибкой выделения места, он будет отменен. Остальные запросы транзакции которые уже выполнены успешно остаются без изменений и неподтверждены.

Если запрос обнаруживает что блок данных нужный для запроса был изменен после начала выполнения запроса, серверный процесс возьмёт «старые» данные из сегмента undo. Если в undo сегменте этот блок был переписан, запрос вернёт ошибку ORA-1555 ”snapshot too old”.

Если табличное пространство undo недостаточно велико – у Oracle есть выбор: позволить транзакции переписать неустаревшие данные и позволить запросу SELECT не выполнится успешно, или позволить запросу SELECT выполнится успешно, а транзакции вернуть ошибку. По умолчанию транзакции имеют больший приоритет: Oracle перезапишет неустаревшие undo.

Параметры для управления undo и гарантия удержания данных (retention guarantee)

Доступно три параметра для управления undo: UNDO_MANAGEMENT, UNDO_TABLESPACE и UNDO_RETENTION.

У параметра UNDO_MANAGEMENT значения по умолчанию AUTO начиная с версии 11g. Возможно установить это значение в MANUAL, и это приведёт к тому что Oracle не будет использовать сегменты undo. Это позволено для обратной совместимости, и если вы решите использовать это, вам придётся тратить много времени на управление и тюнинг сегментов rollback. Лучше не делайте это. Oracle настоятельно рекомендует использовать значение AUTO и разрешить использование сгементов undo. Этот параметр статический, т.е. если вы измените значение вам нужно перезапустить экземпляр БД. Остальные параметры динамический – их можно изменять во время работы экземпляра.

Если вы используете UNDO_MANAGEMENT=AUTO то вы должны указать UNDO_TABLESPACE. Этот параметр указывает активное табличное пространство, которое должно было быть создано как UNDO TABLESPACE. Все сегменты undo будут создаваться и переводиться в режим online автоматически.

И наконец параметр UNDO_RETENTION, который устанавливается в секундах, не обязательный к выполнению. Этот параметр указывает как долго хранить неактивные undo данные перед тем как обозначить их как устаревшие. Если например самый долгий запрос выполняется тридцать минут, вы можете установить этот параметр в 1800. Oracle постарается хранить все undo данные как минимум 30 минут, и ваш запрос должен всегда выполниться успешно, а не вернуть ошибку ORA-1555. Если вы не установили этот параметр, или установили значение 0, Oracle всё равно будет хранить undo данные так долго, как только возможно. Алгоритм который определяет какие данные устарели всегда будет переписывать самые старые данные; таким образом UNDO_RETENTION всегда имеет максимально допустимое значение от размера табличного пространства.

Можно настроить параметр UNDO_RETENTION как обязательный, и undo данные всегда будут храниться столько сколько указано. По умолчанию Oracle выставляет приоритет для транзакций, а не запросов. Если размера не хватает на хранение старых данных для запросов или записи новых для транзакций, Oracle отдаст предпочтение транзакции и перезапишет неактивное undo чтобы транзакция работала без ошибки ORA-30036. Другими словами сохранение undo это лишь необязательная задача которую Oracle пытается по возможности выполнять. Однако иногда бывает ситуация когда успешное выполнение запроса важнее чем транзакции. Например запрос на закрытие месяца, когда нужно выполнить долгий запрос, а транзакции могут подождать пару часов, пока отчёт выполняется. Или если вам нужны flashback запросы, которые работают с undo данными.

Гарантированное удержание данных (guaranteed undo retention), что означает что данные никогда не будут переписаны пока не пройдёт время указанное в UNDO_RETENTION, включается для табличного пространства. Это свойство можно указать во время создания табличного пространтсва или изменить позже. Когда вы активируете табличное пространтсво для которого указано retention guarantee, все запросы будут выполнены успешно если они выполняются быстрее чем значение UNDO_RETENTION; вы никогда не больше не встретите ошибку “snapshot too old”. Обратной стороной медали будет то что транзакции могут не выполниться из-за нехватки места.

Если параметр UNDO_RETENTION был установлен и файлы данных табличного пространтсва undo используют режим autoextend, то Oracle автоматически будет увеличивать размер файлов данных для хранения undo данных минимум время указанное в UNDO_RETENTION. Таким образом комбинирование autoextending файлов данных и гарантированного хранения undo данных позволяет выполнять успешно и транзакции и запросы – конечно если у вас достаточно дискового пространтсва. Если у вас недостаточно места – попытка увеличить размер файла будет неуспешной.

У БД может быть одно табличное пространство используемое в обычной работе, где retention guarantee не настроек, и второе для долгих запросов где хранение данных гарантированно.

Оценка размера и мониторинг табличного пространтсва undo

Табличное пространтсво должно быть достаточно большим чтобы хранить undo данные параллельных транзакций в пиковый момент нагрузки, плюс достаточно неустаревших данных для успешного выполнения самого долгого запроса. Также вам возможно придётся добавить места для flashback запросов. Алгоритм прост: расчитать скорость генерации undo при максимальной нагрузке и умножить на длительность самого долгого запроса.

Представление V$UNDOSTAT расскажет вам то что вам надо знать. Так же доступен помошник в Database Control, который покажет информацию в максимально понятной форме.

На рисунке примера мы видим что табличное пространтсво называется UNDO1 и размер 100 Мб. Хранение undo не гарантировано но файлы данных табличного пространство авторасширяемы. Если вы выбрали авто-расширение для файлов, это гарантирует вам что ваши транзакции всегда выполнятся (пока у вас есть место), но Oracle не будет увеличивать их размер для выполнения UNDO_RETENTION; запрос может вернуть ошибку “snapshot too old”. Как-бы то ни-было, вы не должны рассчитывать на auto-extend; ваше табличное пространство должно быть настроено что быть достаточно большим. Кнопка Change tablespace вызовет команду ALTER SYSTEM для изменения активного табличного пространтсва.

Создание и управление табличных пространтсв undo

С точки зрения управления файлами, табличное пространство undo такое же как другие табличные пространтсва: файлы можно добавлять, изменять размер, включать, выключать, перемещать и переименовывать. Но вы не можете указать свойства хранения: не можете указать метод управления пространтсвом сегментов, или uniform extent size. Для создания табличного пространства undo используется ключевое слово UNDO

CREATE UNDO TABLESPACE tablespace_name

DATAFILE datafile_name SIZE size

[ RETENTION NOGUARANTEE | GUARANTEE ] ;

По умолчанию табличное пространство создаётся RETENTION NOGUARANTEE. Это можно или указать явно при создании, либо изменить позднее выполнив

ALTER TABLESPACE tablespace_name retention [ GUARANTEE | NOGUARANTEE ] ;

Пока вы не укажете явно при создании, файлы данных табличного пространтсва undo не будут авто-расширяемы. Но если вы создавали базу данных используя DBCA, то будет включено авто-расширение файлов и максимальный размер файлов будет неограничен. Автоматическое расширение может быть включено или отключено в любое время, как для любого файла данных.

Невозможно создать сегменты в табличном пространстве undo, кроме тех сегментов undo которые будут созданы автоматически. Вначале будет группа из десяти сегментов undo которые создаются при создании табличного пространтсва. Затем буду т создаваться дополнительные сегменты если в базе будет больше чем десять параллельных транзакций. Oracle следит за количество параллельных транзакций и создаёт сегменты при необходимости.

Неважно сколько у вас табличных пространств undo в базе данных, грубо говоря, только одна будет использоваться в определённый момент. Сегменты undo в актвном табличном пространстве имеют статус online (т.е. доступны для использования); а сегменты в других табличных пространствах будут иметь статус offline, т.е. то что они не могут использоваться. Если табличное пространтсво undo изменяется, все сегменты в старом табличном пространтсве будут выключаться, а сегменты нового табличного пространтсва будут включены. Но бывает два исключения, это

RAC база данных. В каждом экземпляре БД должно быть своё табличное пространтсво undo. Это можно контролировать установив разное значение параметра UNDO_TABLESPACE для каждого экземпляра. Каждый экземпляр управляет статусом своих сегментов undo

Если табличное пространтсво undo изменяется путём указания нового значения UNDO_TABLESPACE, то любые сегменты в предыдущем табличном пространстве связанные с активной транзакцией будут online пока транзакция не закончит работу.

Табличное пространство UNDO используется для хранения данных UNDO. При выполнении операций DML (INSERT, UPDATE и DELETE) Oracle записывает старые данные этих операций в сегмент UNDO.

До того, как oracle9i (сегмент отката) использовался для управления данными UNDO, начиная с oracle9i, для управления данными отката можно использовать не только сегмент отката, но и табличное пространство UNDO.

При 10g кажется, что сегмент отката больше не используется для управления данными UNDO, а табличное пространство UNDO используется равномерно.

1, откат транзакции

Когда для изменения данных выполняется операция DML, данные UNDO сохраняются в сегменте UNDO, а новые данные сохраняются в сегменте данных. Если возникает проблема с операцией транзакции, необходимо откатить старую транзакцию, чтобы отменить изменение транзакции.

Пользователь А выполнил заявление UPDATE emp SET sal=9999 WHERE empno=7788 Позже выяснилось, что зарплата сотрудника 7963 должна быть изменена, а не зарплата сотрудника 7788, тогда изменение транзакции можно отменить, выполнив инструкцию ROLLBACK.

Когда команда ROLLBACK выполнена, Oracle запишет обратно данные 800 UNDO сегмента UNDO в сегмент данных.

2, прочитайте последовательность

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

Когда пользователь A выполняет оператор UPDATE emp SET sal=1000 WHERE empno=7788 В это время запись UNDO будет сохранена в сегменте отката, а новые данные будут сохранены в сегменте EMP, предполагается, что данные не были представлены в это время, и пользователь B выполняет SELECT sal FROM emp WHERE empno=7788 В это время пользователь B получит данные UNDO 800, и эти данные будут получены в записи UNDO.

Сеанс B (здесь мы моделируем, открывая новое окно SQL), если вы продолжаете использовать сеанс A, запрос по-прежнему 1000.

3. Восстановление транзакции

Восстановление транзакций является частью обычного восстановления, оно автоматически завершается сервером Oracle.

Если во время работы базы данных происходит сбой процедуры (например, сбой питания, сбой памяти, сбой фонового процесса и т. Д.), То при перезапуске сервера оракула фоновый процесс SMON автоматически выполняет обычное восстановление, а после выполнения обычного восстановления oracl перезапускается. Сделайте все непримененные записи. Откатите незафиксированные транзакции.

4, Flashback запрос (FlashBack Query)

Flashback-запрос используется для получения данных базы данных в определенный момент времени, он 9i Недавно добавленная функция, при условии, что текущее время - 09:00, а пользователь выполняет его в 10:00. UPDATE emp SET sal= 1000 WHERE empno=7369 Сформулируйте, измените и отправьте транзакцию (начальная зарплата сотрудника составляет 800), чтобы получить зарплату сотрудника до 10:00, пользователи могут использовать функцию запроса обратной связи.

Усовершенствование функции Oracle10g Flashback Query

Запрос Flashback Oracle 9i может предоставить представление данных только в определенный момент времени и не может сказать пользователю, что такие данные прошли через несколько транзакций и как их изменить (UPDATE, INSERT, DELETE и т. Д.), И эта информация находится в сегменте отката Да, в Oracle10g Oracle дополнительно усиливает характеристики запроса на возврат, предоставляя следующие два типа запроса на возврат:

Flashback Versions Query
Flashback Transaction Query

Запрос версии Flashback позволяет новому предложению VERSIONS запрашивать версию данных между двумя точками времени или SCN. Эти версии можно различить по транзакции. Запрос версии Flashback возвращает только отправленные данные, а незафиксированные данные не отображаются.

Запрос версии флэшбэка Oracle10g может получить все операции транзакции над таблицей данных, используя предложение VERSIONS и вводя в таблицу данных серию псевдостолбцов (version_starttime и т. Д.). ), VERSIONS_XID является важной основой, представляющей идентификатор транзакции разных версий.

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

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

Восстановление данных Каштан

Пользователь обновил или случайно удалил пакет данных (при условии большого объема данных),

Вот фрагмент данных для демонстрации: первоначальная зарплата 7369 с номером работы составляет 800, а обновленная зарплата - 1000

В это время пользователь хочет восстановить, предполагая, что момент удаления - после 2016-11-13 09:00:00, затем мы находим SCN (номер изменения системы) до 9 часов.

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

1. Получить текущий SCN

2. Извлечь данные о точке scn в таблицу emp.

Можно видеть, что данные до этого момента времени 7369 равны 800.

3. Затем вы можете выполнить операцию восстановления на основе этих данных.

С точки зрения приложения ORA-01555

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

3. Consistent = y используется при выражении exp. Этот параметр предназначен главным образом для обеспечения того, чтобы все таблицы везде были согласованы в определенный момент времени во время exp, чтобы избежать таблиц с отношениями первичного и внешнего ключей из-за разных моментов времени Несоответствие разрушает целостность данных. Эту операцию рекомендуется выполнять, когда система находится в режиме ожидания.

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

Отмена Oracle имеет два способа: один - использовать отмену табличного пространства, а другой - использовать сегмент отката.

Мы проходим undo_management Параметры для управления, какой метод использовать,

Если установлено значение auto, используется табличное пространство UNDO, и в это время необходимо указать табличное пространство UNDO.

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

Отменить значение параметра конфигурации

UNDO_MANAGEMENT режим управления отмены, разделенный на автоматический и ручной
UNDO_TABLESPACE Таблица отмены, используемая в настоящее время

UNDO_RETENTION указывает, как долго данные не могут быть перезаписаны.

АВТО означает, что отмена находится в автоматическом режиме управления.

900 означает, что данные об отмене не могут быть перезаписаны в течение 900 секунд.

UNDOTBS1 - табличное пространство отмены, используемое в настоящее время

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

Использовать сегмент отката

Когда undo_management установлен в MENUAL При использовании сегмента отката системы записи об отмене записываются в сегмент SYSTEM в табличном пространстве SYSTEM.

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

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

Когда undo_management установлен в AUTO При использовании табличного пространства UNDO для управления сегментом отката в это время у нас будет несколько сегментов отмены, и эти сегменты будут храниться в табличном пространстве UNDO, так что производительность БД будет улучшена.

В настоящее время наша база данных имеет 58 отмененных сегментов. По умолчанию кажется 10.

В дополнение к результатам, просматриваемым через таблицу dba_segment, вы также можете использовать v r o l l s t a t с v роллстат и в Сверните два представления для просмотра информации, эти два представления будут отображать всю информацию о сегменте отката, включая сегмент системы и сегмент отмены.

Используйте следующий SQL для просмотра соотношения между простоями и без простоя в табличном пространстве отмены:

UNEXPIRED и EXPIRED - отмененные табличные пространства, которые использовались,

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

Вот параметр: UNDO_RETENTION Этот параметр используется для указания максимальной продолжительности хранения записей отмены в секундах. Это динамический параметр, который можно изменить в любое время при работе экземпляра. Обычно значение по умолчанию составляет 900 секунд, что составляет 15 минут.

undo_retention указывает только срок действия данных отмены, но это не означает, что данные отмены будут сохраняться в табличном пространстве отмены в течение 15 минут. Например, когда начинается новая транзакция, если табличное пространство отмены уже заполнено, Данные новой транзакции будут автоматически перезаписывать данные отправленной транзакции, независимо от того, истек ли срок действия данных ，

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

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

Если табличное пространство для отмены достаточно велико, а база данных не так занята, то значение параметра undo_retention не повлияет на вас, даже если вы установите его равным 1, пока нет транзакции для перезаписи данных отмены, оно будет продолжать действовать. Короче говоря, обратите внимание на размер табличного пространства отмены, чтобы убедиться, что в нем достаточно места для хранения.

Только в одном случае табличное пространство отмены может гарантировать, что данные в отмене должны быть действительными до истечения времени, указанного в undo_retention, то есть для табличного пространства отмены. Retention Guarantee После указания oracle не будет перезаписывать данные отмены в табличном пространстве отмены, срок действия которого не истек.

Запрет на отмену гарантии сохранения табличного пространства

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

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

Если пространство заполнено, данные новой транзакции будут автоматически перезаписывать данные транзакции, которые были зафиксированы, даже во время отмены удержания. Если не указано удержание
Гарантийный режим, чтобы гарантировать, что он не покрыт undo_retention.

Что касается введения принципа автоматической настройки Oracle UNDO, автоматическое управление табличным пространством, функция автоматической настройки наименьшего срока хранения информации UNDO была добавлена в более поздней версии Oracle 10gr2, больше не только на основе установки параметра UNDO_RETENTION, принцип настройки заключается в следующем :

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

2 Когда UNDO TABLESPACE равен AUM, Oracle динамически корректирует минимальное время хранения информации об отзыве на максимальное время запроса (MAXQUERYLEN) этого периода плюс 300 секунд или больше параметра UNDO_RETENTION, т.е. MAX ((MAXQUERYLEN + 300), UNDO_RENTION );

При включенной автоматической настройке фактическое минимальное время хранения информации об отзыве можно узнать, запросив V U N D O S T A T В виде инжир на из T U N E D U N D O R E T E N T I O N колонка Выиграть Получить 。 в в наиболее короткая Protect Сохранить Время между далеко далеко большой в Предполагать набор из U N D O R E T E N T I O N 。 в нет закон на U N D O T A B L E S P A C E делать фаза должен ремонт изменение из ситуация состояние ， Можно к через прошлое ремонт изменение скрытый формула Женьшень число ” U N D O A U T O T U N E ” за F A L S E выключи близко от шаг мелодия отлично специальный секс 。 к на Предполагать набор Здоровье эффект задний ， V Столбец TUNEDUNDORETENTION в представлении UNDOSTAT получен. Самое короткое время хранения часто намного дольше, чем установленное UNDORETENTION. Когда UNDOTABLESPACE нельзя изменить соответствующим образом, функцию автоматической настройки можно отключить для FALSE, изменив неявный параметр «UNDOAUTOTUNE». После того как вышеуказанные настройки вступят в силу, V Столбец TUNED_UNDORETENTION в представлении UNDOSTAT больше не обновляется, а минимальное время хранения информации об отмене фиксируется в значении параметра UNDO_RETENTION. Этот параметр может быть установлен динамически без перезапуска базы данных.

По умолчанию Undo_retention составляет всего 15 минут. Это значение по умолчанию, как правило, не является удовлетворительным.
Системные Требования. Общая рекомендация - изменить его на 3 часа, чтобы в случае возникновения ситуации было больше времени.

конечно, Чем больше параметр undo_retention, тем больше требуется табличное пространство для отмены , Это необходимо объединить с вашей собственной системой для установки этого параметра.

Имитация ОТМЕНА табличного пространства заполнена

Решение

Есть два метода обработки,

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

Добавить файлы данных

Переключить UNDO табличное пространство

1. Создайте новое табличное пространство UNDOTBS2

2. Переключитесь на вновь созданное табличное пространство UNOD, операция выглядит следующим образом

3. Переведите исходное табличное пространство UNDO в автономный режим:

4. Удалите исходное табличное пространство UNDO:

Если это просто отбросить табличное пространство UNDO, будут удалены только записи в контрольном файле, и файл не будет удален физически.

Удаление табличного пространства отмены может быть выполнено только тогда, когда оно не используется. Если используется табличное пространство отмены (например, транзакция не удалась, но восстановление не было успешным), команда сброса табличного пространства завершится неудачно. Вы можете использовать содержимое при удалении табличных пространств.

Большинство случаев, когда отмена повреждена, вызваны ненормальным временем простоя. Когда об ошибке сообщают во время запуска, DB не может быть запущен.
Например: ORA-00600: внутренний код ошибки, аргументы: [4194]

Когда в журнале оповещений появляется ORA-600 + [4194], можно сделать вывод, что табличное пространство отмены повреждено. В случае отмены повреждения лучше всего использовать резервную копию для восстановления, в противном случае ее можно восстановить только некоторыми специальными методами.

Способ 1: использовать системный сегмент

Когда мы используем поврежденную табличную область отмены, мы можем сначала использовать системный сегмент для запуска БД,
После запуска заново создайте табличное пространство UNDO, для запуска используйте отмену. Действуйте следующим образом:

(1) Создайте pfile с помощью spfile, а затем измените параметры:

Как создать PFILE через SPFILE?

pfile file-Linux и другие платформы в каталоге $ ORACLE_HOME / dbs,
Oralce читает при запуске экземпляра $ORACLE_HOME/dbs Следующий файл инициализации.

(2) Используйте модифицированный pfile для перезапуска БД

(3) Удалить исходное табличное пространство и создать новое табличное пространство UNDO

(4) Закройте базу данных, измените параметры pfile, а затем создайте spfile с новым pfile и запустите базу данных в обычном режиме.

Если используется значение по умолчанию, оно может быть сокращено как:

Способ 2: пропустить поврежденный сегмент

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

(1) Измените pfile и добавьте параметры:

Значения этих полей можно просмотреть через журнал предупреждений. Вы также можете просмотреть его с помощью следующей команды:

(2) Запустите БД с измененным pfile
Поскольку поврежденные сегменты были пропущены, БД может нормально запускаться.
(3) Создайте новое табличное пространство UNDO и переключитесь

В недавней нити обсуждения на OTN -форуме задавался вопрос:

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

Нить обсуждения содержит некоторые интересные ответы, но по большей части они описывают то, как работают undo и redo вместо объяснения, почему проектировщики Oracle corp . выбрали именно тот способ по реализации undo и redo , который они выбрали. Поделюсь своими мыслями о том, зачем [естественно, автор статьи – не я].

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

Undo (в некоторой форме) должна существовать, если нам нужна согласованность по чтению [ read - consistency ]. Никто другой не должен видеть наши изменения в данных до тех пор, пока мы не подтвердим [ commit ] их, более того, наши изменения не должны быть видны даже тем запросам, которые начали исполняться до момента подтверждения нами наших изменений – таким образом, мы должны сохранить где-нибудь более ранние версии данных. Именно здесь получаются вещи, несколько алогичные (но очень умные) с Oracle .

Взглянем более пристально на следующую redo -запись [ redo record ]. Эта запись сгенерирована в середине транзакции во время изменения значения из 42 в 43 четвёртого поля строки таблицы.

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

Мысленный эксперимент №1. Я выполняю продолжительную транзакцию, а множество других сессий выполняют маленькие запросы и короткие транзакции. Другие сессии должны будут видеть данные такими, какими они были перед моими изменениями. Если бы они должны были посетить redo , чтобы увидеть эти данные, тогда онлайновый файл redo -лога должен был быть произвольно большим, чтобы гарантировать наличие всей необходимой информации. И эта информация требуется для журналирования изменений и вперёд, и назад для всех сессий по всем транзакциям, которые начали выполняться с момента старта моей транзакции. Что, скажем, случится, если файлы redo -лога заполнятся?

Мысленный эксперимент №2. Если моя продолжительная транзакция потерпит неудачу и её нужно будет откатить, то необходимые мне обратные изменения будут перемешаны со всеми изменениями – и прямыми, и обратными – которые сделал кто-нибудь ещё с момента старта моей транзакции. В итоге моя сессия, возможно, остановится для совершения множества случайных вводов-выводов с целью найти обратные изменения. Конечно, мы могли бы повысить эффективность этой задачи (и решить №1 лучшим образом) посредством ведения каждой отдельной транзакцией своего собственного лог-файла – но тогда мы увеличим сложность оперирования с самим файлом (открытие и закрытие файлов при каждом старте и останове транзакции), и применения для восстановления файлов redo -лога в правильном порядке.

Мысленный эксперимент №3. В настоящее время Oracle не приводит в порядок каждый изменённый блок при подтверждении транзакции. Если я подтвержу транзакцию, но не зачищу блок X , как следующая сессия, которая посещает этот блок, узнает, что моя транзакция подтверждена, и когда я её подтвердил. Если бы всё, чем мы бы пользовались, был только один redo -лог, то следующая сессия должна была бы пойти в ту точку redo -лога, которая записала изменение в блок X и идти вперёд до тех пор, пока не найдёт подтверждение записи (или выйти на конец redo -лога, или найти подходящий SCN в redo – и таким образом определить, что моя транзакция не была подтверждена или не была подтверждена «вовремя»). Но тогда каждой redo -записи для выбранной транзакции понадобился бы «указатель вперёд» на следующую redo -запись – это означает, что вы каждый раз создавали бы redo -запись, по которой вы должны вернуться назад, чтобы изменить предыдущую redo -запись. Всё это не выглядит эффективным. Таким образом, нужно иметь механизм хранения бесконечно длинного списка транзакций и их подтверждённых SCN где-нибудь в БД, такое «бесконечно» не является хорошей идеей.

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

Решение Oracle состоит в сохранении «полезных» обратных изменений – undo – в месте, совершенно отличном от redo . Вместо создания третьего типа структуры хранения, Oracle сделал выбор в пользу помещения их в БД с использованием обыкновенных блоков данных. Подумайте о том, как это соотносится с тем, о чём я уже упомянул.

Поскольку блоки undo – это всего лишь блоки БД, они защищены redo -логом и могут быть восстановлены точно так же, как восстанавливается БД, не вводя ничего нового с целью восстановления. Вектор «обратного» изменения, который записан в строке redo -лога, оказался в действительности вектором прямого изменения для undo -блока – мы ввели дополнительную служебную информацию в redo -лог, потому что записываем undo дважды (но именно это мы и проделываем с каждым изменением данных в любом случае – разовая запись в блок и разовая запись в redo -лог). Undo -блоки также выгодны с точки зрения LRU -механизма – если undo -блок часто используется, он остаётся в памяти, и это правильно, потому что более вероятно, что недавно сгенерированные undo являются теми undo , которые мы хотим использовать для обеспечения согласованности по чтению.

Поскольку мы храним все undo в БД, нам не нужно беспокоиться о сессиях, постоянно открывающих и закрывающих файлы. А так как сессии начинают и завершают транзакции – мы должны только выставить некий тип каталога, который регистрирует текущие активные транзакции и указывает на места в табличном пространстве undo , где транзакция вносит свои текущие undo -записи. (Это называется таблицей транзакций [ transaction table ] в заголовке undo -сегмента [ undo segment header ])

Так как мы используем блоки БД в качестве единицы хранения и раздельно храним undo для различных транзакций, то когда я записываю свой undo , моя запись получается прекрасно сгруппированной – я захватываю и заполняю один блок в каждый момент времени. Таким образом, если мне понадобится откатить свою транзакцию, чтение одного блока даст мне множество undo -записей, и я минимизирую случайное чтение операций ввода-вывода, которые мне пришлось бы делать, чтобы прочитать undo -поток в обратном направлении.

Если я начинаю очень продолжительную транзакцию во время генерации другими сессиями undo , существует степень независимости между моими undo и их undo . При поиске компромисса между «все undo помещаются в один файл» и «каждая транзакция получает свой собственный undo -файл», Oracle ввёл множество undo -сегментов – то есть, эквивалент относительно небольшого количества совместно используемых файлов. Это означает, что отдельно взятая продолжительная транзакция ограничивается одним undo -сегментом, и все другие транзакции могут продолжать повторно использовать (переписывать) любое место, оставшееся в табличном пространстве undo более эффективно. (Конечно, мы всё ещё можем столкнуться с ошибками типа «файл заполнен», но стратегия позволяет поддерживать текущую активность БД намного дольше на том же объёме дискового пространства)

Было бы невозможно объяснить все мельчайшие детали тех проблем, которые удалось обойти или минимизировать. Однако, при введении undo в БД и их использовании таким образом, как это делается в Oracle , итог получается следующим: если вы хотите знать, почему Oracle использует табличное пространство undo для согласованности по чтению вместо redo -лога, откат и вычисления точки подтверждения, подумайте обо всех сценариях, которые вам придётся исследовать, и на их основе найти способы решения, имея только redo -лог. Подобные раздумья подадут вам некие идеи дополнительных накладных расходов и дополнительного усложнения, которые придётся вам ввести, и это позволит вам понять, как табличное пространство undo позволяет делать многие вещи (относительно) проще и эффективнее.

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