Использование данных отмены Undo Oracle для обеспечения согласованности чтения

Стас Белков

Стас Белков

Автор статьи. Известный специалист в мире IT. Консультант по продуктам и решениям Oracle. Практикующий программист и администратор баз данных. Подробнее.

Oracle Undo - табличное пространство для сохранения старых данных для отменыOracle использует специальные структуры, именуемые записями отмены (undo records) для обеспечения автоматической согласованности чтения на уровне операторов. Все данные для отдельного запроса берутся по состоянию на определенный момент времени. Ему будут видимы только зафиксированные на момент запуска запроса данные; как только запрос запущен, никакие изменения, проведенные другими транзакциями после запуска запроса, в его результатах не отобразятся.



Если транзакция модифицирует данные, то Oracle сохранит их образ “до того” в записях отмены. Для этого и служит табличное пространство Oracle Undo. Например, если вы изменяете зарплату сотрудника с 10 500 до 11 000,то в записях отмены будет сохранена старая зарплата в 10 500. Когда запрос начинает выполняться, Oracle определяет текущий номер изменений системы, который идентифицирует порядок выполнения транзакций в базе данных. Когда блоки данных читаются для этого запроса, Oracle использует только блоки с SCN-номером, определенным для данного запроса. Когда запрос встретит блоки с более новым SCN-номером, Oracle автоматически обратится к сегментам отмены и воспроизведет данные из информации,хранимой в записях отмены. Любые изменения, проведенные другими транзакциями на протяжении выполнения запроса, будут иметь более новые SCN-номера и, таким образом, будет гарантироваться, что запрос вернет только согласованные данные на момент запуска запроса.

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

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

 

Автоматическое управление отменой Oracle

Автоматическое управление отменой (Automatic Undo Management — AUM) снимает с администратора базы данных бремя управления размерами и выделением места для сегментов отмены и поручает его самому Oracle. Все, что остается вам, как администратору базы данных — это создать табличное пространство адекватного размера (табличное пространство отмены) для хранения информации отмены. Oracle будет динамически создавать сегменты отмены (отката) и подбирать их количество в соответствии с требованиями нагрузки на экземпляр. База данных будет автоматически выделять и освобождать место для сегментов отмены, в соответствии с пропускной способностью транзакций в экземпляре.


Совет. Правильное управление пространством отмены Oracle UNDO подразумевает такую его организацию, что необходимая информация не будет переписываться новыми данными отмены. Путем установки соответствующего размера табличного пространства отмены и интервала undo_retention можно повысить шанс успешного выполнения долго работающих запросов без получения ошибки “snapshot too old” (устаревший снимок). Это также гарантирует возможность средствам Flashback извлекать необходимые старые данные.


Традиционно администраторы баз данных сталкивались с регулярной ошибкой ORA-1555 (устаревший снимок), потому что для некоторых транзакций сегменты отката слишком быстро перезаписывались новой информацией. Когда администратор базы данных использует традиционные сегменты отката, он отвечает за мониторинг сегментов отката и может также изменять количество и размер сегментов отката.AUM исключает большинство противоречий, связанных с блоками отмены и согласованностью чтения.

Традиционные сегменты отката иногда замедляют работу, чтобы освободить занятое ими место — даже после завершения транзакции. Сегменты отмены используют пространство более эффективно, за счет динамического обмена с другими сегментами. По необходимости Oracle автоматически создает и переводит в онлайновый и автономный режимы нужные сегменты отмены. Когда необходимость в сегментах отмены отпадает, Oracle передает занятое ими место другим сегментам. Распространенной практикой является назначение администратором базы данных транзакций на определенный сегмент отката с помощью команды SET TRANSACTION. AUM исключает такую необходимость в ручном назначении сегментов отката, поскольку Oracle теперь автоматически “за кулисами” управляет выделением пространства для данных отмены.

В данных отмены нуждается ряд средств восстановления Flashback, такие как Flashback Query, Flashback Versions Query, Flashback Transaction Query и Flashback Table.

 

Настройка AUM

Чтобы разрешить автоматическое управления пространством отмены, прежде всего, нужно специфицировать автоматический режим отмены в файле init.ora или в SPFILE. По умолчанию в Oracle Database 11g база данных использует AUM. Затем потребуется создать выделенное табличное пространство для хранения данных отмены.Это гарантирует, что данные отмены не попадут в табличное пространство System, а это не слишком хорошо. Вы также должны выбрать длительность сохранения данных отмены.

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

Параметр UNDO_MANAGEMENT

Спецификация AUM в файле параметров инициализации осуществляется добавлением следующей строки: 

UNDO_MANAGEMENT = auto 

По умолчанию в Oracle Database 11g устанавливается автоматическое управление отменой, т.е. при желании параметр инициализации UNDO_MANAGEMENT можно опустить.


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


Параметр UNDO_TABLESPACE

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

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

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

SQL> CREATE DATABASE cust_prod
. . .
UNDO TABLESPACE undotbs_01 datafile
DATAFILE '/u10/orcl/oradata/undotbs01_01.dbf' size 750M;
. . .

На заметку! Создание табличного пространства отмены я рассмотрю в отдельной статье при детальном описании создания базы данных Oracle.


Табличное пространство отмены можно не создавать при создании новой базы данных, и даже если оно создается вместе с базой данных, позднее несложно добавить еще одно такое табличное пространство. Создание табличного пространства отмены подобно созданию любого другого табличного пространства, за исключением того, что в операторе CREATE TABLESPACE присутствует ключевое слово UNDO. Чтобы создать само табличное пространство отмены в существующей базе данных, воспользуйтесь следующим оператором: 

SQL> CREATE UNDO TABLESPACE undotbs_02
DATAFILE 'c:\oracle11g\oradata\finance\undotbs01_01.dbf'
SIZE 500M;
Tablespace created.
SQL>

Добавить место к существующему табличному пространству можно с помощью оператора ALTER TABLESPACE, как показано ниже:

SQL> ALTER TABLESPACE undotbs_01
ADD DATAFILE '/u09/oradata/test/undo01dbf' 500M; 

Для базы данных допускается создавать несколько табличных пространств отмены, но в любой момент времени экземпляр может использовать лишь одно из них.Предположим, что в качестве текущего табличного пространства отмены используется пространство undotbs_01. Следующий SQL-оператор alter system динамически изменит табличное пространство отмены для базы данных: 

SQL> ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_02;

Если вы хотите, чтобы Oracle продолжал использовать новое табличное пространство отмены, только что созданное вами, undotbs_02, потребуется специфицировать это в файле init.ora. В противном случае Oracle всегда будет применять табличное пространство отмены по умолчанию, которое специфицировано в параметре UNDO TABLESPACE оператора создания базы данных.

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

SQL> CREATE UNDO TABLESPACE undotbs_01
DATAFILE '/u10/oradata/prod/undo0101.dbf' SIZE 100M AUTOEXTEND ON;

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

SQL> ALTER TABLESPACE undotbs_01
ADD DATAFILE '/u01/oradata/prod/undo0102.dbf' AUTOEXTEND ON NEXT 5M
MAXSIZE UNLIMITED;

Если по какой-то причине решено, что нужно табличное пространство отмены фиксированного размера, с помощью Undo Advisor можно получить рекомендации относительно идеального размера. В качестве основы для анализа Undo Advisor использует данные, собранные в репозитории автоматической рабочей нагрузки ( Automatic Workload Repository — AWR), так что экземпляр сможет работать достаточно долго после запуска, поскольку Undo Advisor имеет достаточно данных для выдачи своих рекомендаций. Undo Advisor принимает два ввода — ожидаемую длительность самого большого запроса в базе данных, и насколько далеко необходимо вернуться во времени в операциях Flashback, зависящих от данных отмены. Используя большее из двух значений, можно найти идеальный размер табличного пространства отмены на графике Undo Advisor. 


На заметку! Иногда, когда вы запускаете экземпляр или переключаете табличное пространство отмены, требуется несколько минут, чтобы сегменты отмены перешли в онлайновый режим. Чтобы избежать этой проблемы, база данных использует данные из AWR для определения количества сегментов отмены, которые следует перевести в онлайновый режим при перезапуске экземпляра или переключении табличного пространства отмены. Это средство также известно как быстрый подъем (fast ramping up) сегментов отмены.


Oracle Undo Tablespace - хранит старые данные, которые требуется восстановить при отмене действий

Параметр UNDO_RETENTION

Когда транзакция фиксируется, необходимость в данных отмены этой транзакции отпадает. Однако эти данные остаются в табличном пространстве отмены до тех пор,пока не потребуется место для записи новых данных отмены для последующих транзакций. Когда поступают данные отмены новой транзакции, они могут переписать старые данные отмены (от фиксированных транзакций), если свободного места в табличном пространстве отмены недостаточно. Для длительно выполняющихся запросов, которые нуждаются в сохранении данных отмены в целях согласованности, существует возможность, что некоторые данные отмены, которые нужны такому запросу, окажутся переписанными другими, более новыми транзакциями. В этом случае вы можете получить от базы данных сообщение об ошибке (“устаревший снимок”), указывающий на то, что образ данных “до того” транзакции был переписан. Чтобы предотвратить это, Oracle предусматривает параметр конфигурации UNDO_RETENTION, в котором можно задать длительность интервала по своему усмотрению. Обратите внимание, что в старом ручном режиме управления отменой администратор базы данных не имел возможности определить, как Oracle сохраняет информацию отмены.

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

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

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

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

UNDO_RETENTION = 1800

Значение UNDO_RETENTION по умолчанию составляет 900 секунд.


Совет. Пространство отмены должно быть в состоянии вместить любой объем информации в течение заданного периода хранения. Если табличное пространство отмены не может вместить записи отмены на указанный период времени, при выполнении запросов возникает риск получить ошибку типа “устаревший снимок”.


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

SQL> ALTER SYSTEM SET UNDO_RETENTION = 7200 /* два часа

Не существует идеального временного интервала UNDO_RETENTION. Ваш интервал будет зависеть от того, насколько долго по вашему предположению может длиться транзакция. На основе информации о максимальной длительности транзакции в базе данных можно вывести предполагаемое время для указания его в параметре UNDO_RETENTION.

Представление V$UNDOSTAT предоставляет индикатор, который поможет вычислить подходящий интервал сохранения. Запросите V$UNDOSTAT следующим образом: 

SQL> SELECT MAX(maxquerylen) FROM v$undostat;
MAX(MAXQUERYLEN)
----------------
210

Столбец maxquerylen представления V$UNDOSTAT сообщает длительность самого долго выполнявшегося запроса (в секундах) за последние 24 часа. Время, установленное в параметре UNDO_RETENTION, должно быть не меньше того, что указано в столбце maxquerylen. Это само по себе не гарантирует отсутствия проблем с новыми длительными запросами, однако появляется шанс, что самая длительная транзакция сохранит согласованность чтения при использовании табличного пространства отмены.

Oracle предлагает следующие рекомендации для установки интервала сохранения отмены в новой базе данных:

Если вы считаете, что все эти действия со временем сохранения отмены требуют слишком много работы, пойдите по пути наименьшего сопротивления и позвольте Oracle автоматически настроить отмену в базе данных. Oracle автоматически настроит длительность периода отмены для самого долго выполняющегося запроса, и будет собирать информацию о длительности текущих запросов каждые 30 секунд. В зависимости от статистики рабочей нагрузки, Oracle отрегулирует длину периода хранения отмены. Например, в течение дня короткие транзакции могут означать более короткий период хранения отмены, а в процессе выполнения длительных ночных пакетных заданий понадобится намного больший период хранения отмены, чтобы избежать ошибок типа “устаревший снимок”. Если не установить параметр UNDO_RETENTION (или сделать его равным 0), то Oracle автоматически настроит длительность отмены на минимальное значение в 900 секунд.

Подведем итоги относительно автоматической настройки времени хранения данных отмены в Oracle Database 11g Release 1.


Совет. По умолчанию Oracle Database 11g автоматически настраивает период хранения отмены.Oracle рекомендует не устанавливать параметр UNDO_RETENTION, если только это не обусловлено требованиями хранения для Flashback или LOB.


При автоматическом управлении отменой (AUM) база данных сама отвечает за создание, выделение и освобождение сегментов отмены по мере необходимости. Чтобы узнать, какие сегменты отмены находятся в онлайновом режиме, нужно запросить представление DBA_ROLLBACK_SEGS

SQL> SELECT segment_name, tablespace_name, status
FROM dba_rollback_segs;

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

Если параметр UNDO_RETENTION установлен в AUTO, и вы не можете создать определенное табличное пространство отмены для хранения информации отмены, Oracle все равно будет создавать записи отмены в табличном пространстве по умолчанию, именуемом SYS_UNDOTBS, с размером по умолчанию около 200 Мбайт.

Следующий сценарий SQL выводит местоположение и размер табличного пространства отмены в базе данных: 

SQL> SELECT file_name, bytes
2 FROM dba_data_files
3 WHERE tablespace_name='UNDOTBS';
FILE_NAME BYTES
----------------------------------- ---------
/u01/orcl/oradata/undotbs01_01.dbf 209715200
SQL>

 

Установка размеров табличного пространства отмены

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

Сначала создайте маленькое (около 500 Мбайт) табличное пространство отмены, с атрибутом AUTOEXTEND, установленным в ON, что позволит этому табличному пространству расширяться автоматически. Табличное пространство будет автоматически расти, как для поддержки растущего числа активных транзакций, так и их возрастающей длительности.

После того, как со временем база данных достигнет разумного размера, используйте Undo Advisor, чтобы получить рекомендации относительно размера табличного пространства отмены. Используйте максимальное время, указанное в поле Analysis Time Period (Промежуток времени для анализа). Для этой цели можно использовать длительность самого долго выполняющегося запроса (Longest-Running Query), показанную на странице OEM Undo Management. Также потребуется указать значение в поле New Undo Retention (Новая длительность хранения информации отмены) на основе требований Flashback. Если планируется применять средства ретроспективы для таблиц, например,за прошедший период длительностью в 24 часа, укажите в этом поле значение 24.


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


Используя эти два значения (в полях Analysis Time Period и New Undo Retention), инструмент Undo Advisor выдаст рекомендацию относительно соответствующего размера табличного пространства отмены. Для надежности этот размер можно увеличить на 20% и сделать табличное пространство отмены с фиксированным размером, отключив атрибут AUTOEXTEND.

 

Гарантированная длительность хранения отмены

При AUM база данных Oracle собирает данные отмены и сохраняет их в сегментах отмены. Традиционно Oracle использовал данные из сегментов отмены для обеспечения согласованности запросов по чтению, для отката транзакций и восстановления прерванных транзакций. Начиная с Oracle9i, сфера применения данных отмены расширилась — они участвуют в запросах “старых” данных и восстановлении после возникновения логических ошибок в данных. Данные отмены также поддерживают новые средства Flashback на уровне строки и таблицы.

Параметр инициализации UNDO_RETENTION позволяет специфицировать длительность времени хранения данных в сегментах отмены. Oracle Database 11g автоматически настраивает информацию отмены, собирая статистику по самым долго выполняющимся запросам и рейтинге генерации данных отмены в базе. Если вы не установите параметр UNDO_RETENTION или укажете для него нулевое значение, то Oracle автоматически настроит систему отмены на хранение данных в течение 900 секунд, как значение по умолчанию параметра UNDO_RETENTION. Установив значение выше 900 секунд, можно хранить записи отмены дольше и глубже проникать в прошлое. Поскольку несколько средств Flashback в Oracle Database 11g полагаются на данные отмены, необходимо установить параметр UNDO_RETENTION существенно выше значения по умолчанию.(В дополнение к более эффективной работе средств Flashback, это сократит вероятность ошибок типа “устаревший снимок”.)

Гарантированное сохранение информации отмены (guaranteed undo retention) означает просто, что Oracle сохранит данные отмены на протяжении всего заданного периода сохранения, причем не важно как. То есть если задана длительность интервала сохранения в полчаса, то Oracle будет хранить данные отмены полные 30 минут, при любых обстоятельствах. При переполнении пространства, доступного для хранения данных отмены, сгенерированных новыми транзакциями, любая новая транзакция DML потерпит крах, поскольку Oracle не сможет обеспечить хранение информации для ее изменений. Подобным образом достигается компромисс между гарантированной информацией отмены и потенциальными сбоями некоторых операторов DML.


Совет. По умолчанию Oracle не гарантирует сохранения данных отмены; если принято решение гарантировать сохранение данных отмены, время их хранения по умолчанию составляет 900 секунд (15 минут).


Специфицировать гарантированное сохранение отмены для табличного пространства отмены можно при создании базы данных или же при создании нового табличного пространства отмены, указав конструкцию RETENTION GUARANTEE

SQL> CREATE UNDO TABLESPACE undotbs01
2 DATAFILE
3 '/u01/orcl/oradata/undotbs01_01.dbf'
4 SIZE 10M AUTOEXTEND ON
5* RETENTION GUARANTEE;
Tablespace created.
SQL>

Чтобы гарантировать сохранение отмены в базе данных, можно также воспользоваться командой ALTER TABLESPACE: 

SQL> ALTER TABLESPACE undotbs01 RETENTION GUARANTEE;

Для отключения гарантированного сохранения информации отмены служит конструкция RETENTION NOGUARANTEE, применение которой показано в следующем примере:

SQL> ALTER TABLESPACE undotbs01 RETENTION NOGUARANTEE;

Внимание! Большое значение параметра UNDO_RETENTION не гарантирует сохранения данных отмены в течение заданного им времени. Для гарантии сохранения данных отмены в течение заданного времени служит конструкция RETENTION GARANTEE.


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

Управление табличными пространствами отмены

Управление табличными пространствами отмены подобно управлению любыми табличными пространствами в базе данных. Вы добавляете место табличному пространству отмены, добавляя ему новый файл данных, и уменьшаете занятое им место, сокращая размер файла (файлов) данных командой ALTER DATABASE DATAFILE...RESIZE.

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

Поскольку команда DROP TABLESPACE удаляет содержимое табличного пространства отмены, она аналогична команде DROP TABLESPACE...WITH CONTENTS. Если по какой-то причине нужно переключить табличные пространства отмены, после создания нового табличного пространства старое можно удалить.

 

Ошибка типа “устаревший снимок”

Иногда длительная транзакция не может найти нужные ей данные отмены и, следовательно, терпит крах с выдачей хорошо известной ошибки типа “устаревший снимок”(snapshot too old). Вот пример:

SQL> BEGIN
2 purge_data_pkg.main_driver(1502,2005,'N','B','N','N');
3 END;
4 /
begin
*
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 9 with name "_SYSSMU9$" too small
устаревший снимок: сегмент отката номер 9 по имени "_SYSSMU9$"
слишком мал
ORA-06512: at "APPOWNER.PURGE_DATA_PKG", line 2040
ORA-06512: at "APPOWNER.PURGE_DATA_PKG", line 4318
ORA-06512: at line 2
SQL>

Как показывает предыдущий пример, получить эту ошибку можно даже при использовании AUM, поскольку значение параметра UNDO RETENTION слишком мало. Такое случается даже при наличии достаточного свободного места в табличном пространстве отмены. Лучше увеличить значение параметра UNDO_RETENTION, чтобы данные отмены не были переписаны до завершения длительной транзакции. Единственно верный путь избежать ошибки типа “устаревший снимок” — включить гарантированное сохранение данных отмены в базе данных.

 

Управление информацией пространства отмены

С помощью команды SHOW PARAMETER UNDO в SQL*Plus можно посмотреть, какие опции конфигурирования предусмотрены для управления пространством отмены: 

SQL> SHOW PARAMETER UNDO
NAME                TYPE      VALUE
-----------------   -------   -------------
undo_management     string    AUTO
undo_retention      integer   900
undo_tablespace     string    UNDOTBS_01
SQL>

На заметку! Если вы использовали предшествующие версии Oracle, то должны помнить оператор SET TRANSACTION USE ROLLBACK SEGMENT..., который позволял назначить транзакции определенный сегмент отката, чтобы избежать ошибки слишком старого снимка. Этот оператор по-прежнему можно применять, но только при ручном управлении отменой. Если же используется рекомендуемое Oracle средство Automatic Undo Management, то база данных просто проигнорирует этот оператор, не генерируя ошибки.


Если для создания групп потребителей ресурсов в базе данных применяется Database Resource Manager, что является удобным способом группирования пользователей на основе использования ими ресурсов базы, то можно легко предотвратить захват одной транзакцией всего свободного места отмены, тем самым препятствуя получению пространства отмены со стороны новых транзакций. Специальный параметр UNDO_POOL позволяет ограничить максимальное пространство отмены, которое может использовать группа потребителей ресурсов. При достижении предела UNDO_POOL любая транзакция, которая нуждается в дополнительном месте для данных отмены, завершится ошибкой. Только после того, как некоторые текущие транзакции, принадлежащие членам группы потребителей ресурсов, завершатся, этой группе может быть выделено новое пространство для данных отмены.

Следующие представления словаря данных удобны для управления информацией о пространстве отмены.

 

Использование OEM для управления данными отмены

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

Чтобы попасть на страницу Undo Advisor, перейдите по маршруту OEM Home Page => Advisor Central => Undo Management (Домашняя страница OEM => Центр советников => Управление данными отмены) и щелкните на кнопке Undo Advisor (Советник по данным отмены).

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

Страница Undo Management (OEM Home Page => Administration => Instance => Undo Management (Домашняя страница OEM => Администрирование => Экземпляр => Управление данными отмены)) служит для выполнения перечисленных ниже задач.

На рисунке ниже показаны графики рейтинга генерации отмены (Undo Generation Rate) и использования табличного пространства (Undo Tablespace Usage) из нижней части страницы OEM Undo Management. Эти графики оформлены в цвете, так что можно с первого взгляда увидеть, как табличное пространство отмены обрабатывает объем информации отмены, генерируемой вашим экземпляром.

Undo Generation Rate и Undo Tablespace Usage 

 

Вас заинтересует / Intresting for you:

Создание табличных пространств...
Создание табличных пространств... 12057 просмотров Дэйзи ак-Макарова Tue, 21 Nov 2017, 13:18:46
Количество пользовательских та...
Количество пользовательских та... 1489 просмотров Stas Belkov Tue, 21 Nov 2017, 13:18:46
Квоты табличных пространств
Квоты табличных пространств 3505 просмотров Stas Belkov Tue, 21 Nov 2017, 13:18:46
Oracle Personal Edition
Oracle Personal Edition 5963 просмотров Надин Tue, 21 Nov 2017, 13:32:12
Печать
Войдите чтобы комментировать

MaxNiko аватар
MaxNiko ответил в теме #9101 5 года 8 мес. назад
Спасибо за статью!
apv аватар
apv ответил в теме #8838 6 года 4 мес. назад
А кто-то использует UNDO_MANAGEMENT = auto в своих продакшен базах?
ildergun аватар
ildergun ответил в теме #8814 6 года 4 мес. назад
Абсолютно согласен, что требуется грамотно настроить в базе данных Oracle Undo пространство, чтобы данные в нем не переписывались новым потоком отмены. Тогда ужас Админов и Бухгалтеров ошибка ORA-1555 (устаревший снимок) перестанет преследовать и наяву, и в кошмарных снах! ;-)
OraCool аватар
OraCool ответил в теме #8779 6 года 5 мес. назад
Табличное пространство Undo в Oracle просто панацея от корявых ручек пользователей при работе с базой данных.