Oracle поддерживает в своем ядре информацию, которая помогает ему гене-
рировать в базе данных числа (выполняющие роль порядковых        назы-
ваемые системными номерами фиксации (SCN, system commit number) и
представляющие состояние (инкарнацию) базы данных в любой момент времени.
Эти числа продвигают вперед изменения базы данных, вызванные структурны-
ми преобразованиями объектов базы данных или зафиксированными операци-
ями DML. Как это обсуждалось ранее в разделе "Конфигурируем 

initrans" 

главы

"Настройка базы данных", каждый блок данных имеет область заголовка, храня­щую слоты транзакций для тех транзакций, которые заявили, что они модифи­цируют данные этого блока. Эти слоты называются также списками заинтересованных транзакций (ITL, interested transaction lists).

В ITL содержатся три важные структуры: идентификаторы транзакций

(TID), адрес блока отмены (UBA, undo block address), указывающий на адрес,

где хранятся образы данных до изменения, и SCN для случаев, когда транзакция уже была зафиксирована. Каждая транзакция, модифицирующая данные из бло­ка данных, включает в слот транзакции свой идентификатор.

Процесс сервера, обслуживающий транзакцию, копирует образы данных до изменения для столбцов, которые должны быть изменены (если применимо) в

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

отложенной очисткой блока.

В области заголовка блока содержится также 

системный номер изменения 

"(SGN, system change number), который не следует путать с системным номером ■"фиксации (SCN, system commit number), даже несмотря на то, что в некоторых документах они могут обозначаться одним акронимом (по-английски, разумеет­ся. - 

Пргш.пер.),ш 

последовательный номер, используемый для указания версии блока. Пользователь, приступая к изменениям, получает новый системный но­мер изменения и начинает с последовательности 1. Это число увеличивается на 

■" •' 1 

для каждой обновленной строки до тех пор, пока изменения не зафиксируют­ся или не будет достигнут последовательный номер 254, после чего пользовате­лю необходимо снова получить SCN. Аналогично слотам транзакции в блоках данных в первом блоке (блоке заголовка) каждого сегмента отката хранится таб­лица транзакций, в которой содержится информация о транзакциях, использу­ющих этот сегмент отката. В нее также включен адрес блока данных (DBA, data block address) последнего блока отмены, использованного      данной транзак­ции. Блок заголовка сегмента отката известен также как блок заголовка отмены

(отмена - это еще один термин, используемый для обозначения отката).

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

инициирования запроса. Далее процесс сервера заново создает образ блока до

изменений, используя текущий номер версии блока и образ данных до измене­ния (из блока отмены в сегменте отката) как SCN, с которого будет начата нуме­рация. Это делается для того, чтобы обеспечить согласованное по чтению изображение блока. Процесс в таком случае получает список транзакций из ITL блока, а затем образ блока до изменений из одного или нескольких сегментов отката (если в ITL блока имеется несколько ID транзакций). Важно отметить, что на самом деле     транзакции никогда не удаляются из ITL.

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

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

транзакций, размещенную в заголовке сегмента отката. Затем Oracle копирует .  SCN из таблицы транзакций сегмента отката в ITL блока данных. В этом случае пользователь снова считывает блок "как есть". Если же это не так, Oracle постро­ит совместимую по чтению версию блока данных, используя текущую версию блока и данные, хранящиеся в сегменте отката блока отмены.

Данные для такого блока строятся заново с использованием образа данных
до изменений, хранящегося в одном из сегментов отката. Затем в хранящихся в
блоке заголовка каждого из сегментов отката таблицах транзакций осуществля-
ется поиск ID транзакций, находящихся в ITL блоков. Если по каким- то причи-
нам процесс сервера не может реконструировать совместимый по чтению
образ (образ до обновления отсутствует в сегменте        запрос заканчивается аварийно с ошибкой "ORA-01555 - Snapshot too old". Если такого, дорогой чи­татель, никогда в вашей среде не случалось, это значит, что либо вы очень удачно сконфигурировали сегменты отката, либо просто родились под счастли­вой звездой. Позже мы обсудим некоторые методы, помогающие избежать ситу­ации "Snapshot too old".

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