Транзакция на протяжении своей недолгой жизни может только один раз ис­пользовать один сегмент отката для сохранения в нем образа данных до обнов­ления. Однако в один экстент сегмента отката могут быть записаны данные из нескольких транзакций. Когда происходит перенос и процесс сервера не может вести запись в экстент, в котором уже содержатся данные из одной или несколь­ких активных транзакций, требуется расширить сегмент отката. Перенос и рас­ширение являются функциями времени и количества генерируемой информации отмены. Если у транзакции до момента фиксации сделанных ею изменений проходит слишком много времени, это может привести к чрезмер­ному расширению сегмента отката. Перенос без расширения (признак слишком

малого сегмента отката) вызовет переписывание зафиксированных изменений

и может выдать для долготекущих запросов ошибку "ORA-01555 - Snapshot too old".

Но размер и число сегментов отката должны зависеть от транзакционной де­ятельности базы данных. Потребности систем OLTP лежат очень далеко от по­требностей хранилища данных или системы DSS. У системы OLTP наблюдается тенденция иметь большое число коротких транзакций, в то время как транзак­ций хранилища данных значительно меньше по общему их количеству, но они намного более продолжительны по времени. Большинство систем попадают в гибридную категорию, где часть транзакций похожа по типу на транзакции OLTP, а часть - на транзакции хранилищ данных. Поэтому управление сегмента­ми отката и их конкуренцией в подобных случаях становится очень сложным.

Какой размер выбрать     сегментов отката?

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

1.        Поставляемое Oracle представление V$TRANSACTION содержит в
столбце        число блоков данных, применяемых транзакциями для

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

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

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

SQL> select Max(Used_Ublk) 2        from V$TRANSACTION; MAX(USED_UBLK)

250

SQL>

2.        После того как были сняты многократные показания и определена

требуемая величина (максимальное количество информации отмены),

нужно умножить ее на размер блока данных базы данных, чтобы

получить размер информации в байтах.

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

■

4. В результате получаются значения 

initial 

и 

next 

экстентов для сегмента отката.

Предположим, что максимальное значение Max(Used_Ublk) равно 250. Если
размер блока базы данных составляет 8192 байта, максимальное количество ин-
формации отмены, генерируемой каждой транзакцией, составит 2048000 байт
(250x8192). Округление этой величины до ближайшего кратного степени 2 дает
нам 2097152 или 2 Мбайта. Следовательно, размер экстентов 

initial и next ддя^ет-

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

размера. Каждому сегменту отката требуется как минимум два экстента (

minextents), 

выделяемые ему при создании. Работа по моделированию и тестированию, вы­полненная в прошлом в лабораториях Oracle, показала, что если 

minextents 

поло­жить равным 20 (a 

initial w. next 

выбрать равными 2 Мбайта, как было только что вычислено), вероятность появления ошибки "Snapshot too old" существенно снижается. Мы с вами разные, но во всех случаях нашей целью является избежа­ние динамического расширения сегментов отката, а если возможно, то и конку­ренции.

Обратной стороной создания 

minextents 

равным 20 для каждого сегмента от-
ката обычно является номинальная потеря дискового пространства. Хотя дина-
мическое расширение одного экстента может не быть таким уж дорогим, для
сегментов отката стоимость обычно возрастает довольно быстро, если постоян-
но выделять и освобождать (с использованием параметра        экстенты. Это
может отрицательно влиять на производительность. Поэтому установите 

minex-

tents 

равным 20 (в некоторых случаях значение может быть меньше, а в некото-
рых - больше). Очень легко оценить объем отката, сгенерированного за один
типичный деловой день. Можно просуммировать столбец 

writes 

представления
V$ROLLSTAT для каждого сегмента отката. Еще один метод - проследить за чис-
лом расширений для каждого сегмента отката в течение дня.

Для долго длящихся обновлений в среде хранилищ данных или для пакетных
заданий, которые выполняют очень много действий DML, при определении
размера сегмента отката требуется проделать некоторую работу. Необходимо
определить количество генерации отмены для типичного задания, обновляю-
щего или удаляющего строки. В представлении V$ROLLSTAT в столбце 

writes 

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

один сегмент отката, использующийся этим заданием. Запишите текущее значе­ние writes. Выполните задание и снова проверьте значение 

writes. 

Разница между ними равна количеству информации отката, генерируемой заданием. Скорее всего, это будет большое число. Затем можно решить, какие значения выбрать для 

initial, next 

и 

minextents 

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

Чтобы убедиться, что больший сегмент отката используется предпочтитель­но для пакетных заданий, примените команду set transaction use rollback seg­ment rbsO 1, 

где rbsOl - 

сегмент отката. Можно также использовать для установки определенного сегмента отката в блоке кода PL/SQL пакет PL/SQL dbms_transaction.use_rollback_segment. Однако такая установка будет дейст­вовать только в течение одной транзакции, т. е. до первого отката или фикса­ции изменений. Помните, что установку транзакции на определенный сегмент отката необходимо выполнить первым оператором транзакции сразу же после фиксации результатов или отката предыдущей транзакции.

Сколько сегментов отката необходимо?

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

число одновременно выполняющихся транзакций/4,

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

В представлении V$ROLLSTAT имеются еще два столбца, о которых необхо-
димо кратко упомянуть, - это 

optsizt и shrinks. 

Помимо задания параметров 

initial,

next 

и 

minextcnts, 

сегмент отката может быть определен как имеющий размер

optimal. 

Если размер сегмента отката выйдет за указанные параметром 

optimal

пределы, Oracle автоматически освободит или сократит экстенты, чтобы воз-
вратить размер сегмента к его установке по параметру 

optimal. 

Таким образом,
Oracle пытается сохранить размер сегмента на уровне 

optimal. 

В столбце 

shrinks

находится число таких случаев уменьшения размера для сегментов отката. Од-
нако освобождение этих сегментов не происходит мгновенно после заверше-
ния транзакции. Здесь уместно отметить, что транзакция, увеличившая размер
сегмента отката сверх размера 

optimal, 

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

Установка параметра 

optimal 

для контроля размера сегментов отката может

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

optimal 

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

optimal. 

Вместо этого полезно рассмотреть вариант с сокращением размеров сегментов вручную.

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

optimal, 

является напрасная потеря дисковой памяти. Другим подводным камнем, который встречается при использовании 

optimal, 

является потенциальное возникновение ошибки ORA-01555. По этой

причине мы избегаем применения подобной установки. Кроме

того, нет различий в производительности при использовании общедоступных или частных сегментов отката (ключевое слово public (общедоступный) задействуется при создании сегмента отката). Мы рекомендуем для обеспечения лучшей управляемости создавать частные сегменты отката, поскольку общедоступные сегменты живут своей собственной жизнью и переводятся в онлайновое состояние в соответствии с формулой:

TRANSACTIONS/TRANSACTIONS_PER_ROLLBACK_SEGMENT.

Число транзакций, которое может поддерживать определенный сегмент отката, зависит не от параметра

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