Управление Undo
Управление Undo
Главным достоинством сегментов undo является то что они управляются автоматически, но вы должны установить ограничения в границах которых Oracle будет осуществлять управление. После того как вы рассмотрели объем данных и активность вашей БД вам нужно установить некоторые параметры и определить размеры табличных пространтсв undo.
Ошибки связанные с undo
Принципы очень просты: во первых, всегда должно быть достаточно места для undo чтобы все транзакции могли работать и, во вторых, всегда должно быть достаточно данных undo чтобы запросы выполнились успешно. Первый принцип требует чтобы табличное пространство undo было достаточно большим чтобы накапливать undo данные для худшего сценария. Должно быть выделено достаточно места для хранения данных во время пиковой нагрузки. Обратите внимание что это не значит в момент максимального количества конкурирующих транзакций; во время обычной работы у вас может быть много транзакций, но суммарное количество данных undo которые они сгенерируют будет гораздо меньше чем сгенерирует одна долгая транзакция запускаемая в конце месяца. Второй принцип требует наличие в табличном пространстве места для хранения неустаревших данных которые могут требоваться для согласованности чтения.
Если транзакции недостаточно места, последний запрос выполнится с ошибкой ORA-30036 “unable to extend segment in undo tablespace”. Запрос будет отменён, но все остальные запросы внутри транзакции останутся выполненными и неподтверждёнными. Алгоритм которы выделяет место для undo сегментов внутри табличного пространтсва undo вызовет такую ошибку только если табличное пространтсво полностью состоит из активных данных.
Exam tip
Если 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, который покажет информацию в максимально понятной форме.
На рисунке 8-8 показан экран управления undo в Database Control. Из домашней страницы перейдите на вкладку Server и затем перейдите по ссылке Automatic Undo Management в разделе Database Configuration.
На рисунке примера мы видим что табличное пространтсво называется UNDO1 и размер 100 Мб. Хранение undo не гарантировано но файлы данных табличного пространство авторасширяемы. Если вы выбрали авто-расширение для файлов, это гарантирует вам что ваши транзакции всегда выполнятся (пока у вас есть место), но Oracle не будет увеличивать их размер для выполнения UNDO_RETENTION; запрос может вернуть ошибку “snapshot too old”. Как-бы то ни-было, вы не должны рассчитывать на auto-extend; ваше табличное пространство должно быть настроено что быть достаточно большим. Кнопка Change tablespace вызовет команду ALTER SYSTEM для изменения активного табличного пространтсва.
Дополнительная информация на вкладке System Activity, показанная на рисунке 8-9, рассказывает вам что пиковая геренация undo всегд 1664Кб в минуту, и самый долгий запрос был 25 минут. Отсюда следует что минимальный размер табличного пространтсва undo будет 1664*25=40265 Кб, что всего лишь 40 Мб. Елси текущий размер меньше, это оторазится в секции помошника Undo. Пока что не было ошибок транзакций, и ошибок запросов вызванных недостатком места или перезаписью данных undo.
Создание и управление табличных пространтсв 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 ] ;
Exam tip
Пока вы не укажете явно при создании, файлы данных табличного пространтсва undo не будут авто-расширяемы. Но если вы создавали базу данных используя DBCA, то будет включено авто-расширение файлов и максимальный размер файлов будет неограничен. Автоматическое расширение может быть включено или отключено в любое время, как для любого файла данных.
Невозможно создать сегменты в табличном пространстве undo, кроме тех сегментов undo которые будут созданы автоматически. Вначале будет группа из десяти сегментов undo которые создаются при создании табличного пространтсва. Затем буду т создаваться дополнительные сегменты если в базе будет больше чем десять параллельных транзакций. Oracle следит за количество параллельных транзакций и создаёт сегменты при необходимости.
Неважно сколько у вас табличных пространств undo в базе данных, грубо говоря, только одна будет использоваться в определённый момент. Сегменты undo в актвном табличном пространстве имеют статус online (т.е. доступны для использования); а сегменты в других табличных пространствах будут иметь статус offline, т.е. то что они не могут использоваться. Если табличное пространтсво undo изменяется, все сегменты в старом табличном пространтсве будут выключаться, а сегменты нового табличного пространтсва будут включены. Но бывает два исключения, это
RAC база данных. В каждом экземпляре БД должно быть своё табличное пространтсво undo. Это можно контролировать установив разное значение параметра UNDO_TABLESPACE для каждого экземпляра. Каждый экземпляр управляет статусом своих сегментов undo
Если табличное пространтсво undo изменяется путём указания нового значения UNDO_TABLESPACE, то любые сегменты в предыдущем табличном пространстве связанные с активной транзакцией будут online пока транзакция не закончит работу.