In-Memory Undo (IMU) управление или как теперь оракл работает с undo !

dbstalker, 03 июня

Как известно, Оракл, начиная с версии 10.0, использует новую (как было раньше см. здесь) запатентованную технологию In-Memory Undo (IMU) работы с undo сегментами. В этом посте попробую упрощенно показать, как это работает.

Объяснение основано на вот этом рисунке.

Будем рассматривать транзакцию в четырех промежутках времени:

Время T1. Во времени T1 в буфере 142, содержится запись 136 со значением 105 в некоторой колонке. Это время на рисунок не поместилось.

Время T2. Во времени T2 транзакция изменяет в записи 136 значение поля с 105 на 110, что является результатом выполнения следующих трех основных операций:

  1. буфер 142 изменяется. Эта операция происходит буферном кеше, а не на диске.
  2. Появляется узел IMU, он отражает undo-запись, связанную с изменение буфера 142 и ITL блока 142 указывает на узел IMU. Узлы IMU находятся в коллективном пуле и доступ к ним организован через защелки IMU. Они действуют по алгоритму LRU.
  3. redo-запись, связанная с изменением буфера 142, должна быть записана в redo log буфер. Обратите внимание, что не было никакого использования undo буфера, нет redo-записей, связанных с изменением undo буфера, и нет всего, что связанно управлением сегментов.

Время T3. Во времени T3 транзакция снова изменяет запись 136. Но на этот раз со значения 110 на 115.

  1. изменяется буфер 142
  2. Появляется еще один узел IMU для отражения undo-записи, связанной с изменениями буфера 142. ITL блока 136 указывает на самый последний узел IMU.
  3. изменения буфера 142 записываются в redo log buffer.

Кроме того, нет изменений undo буферов, поэтому изменения undo буфера не записываются в redo log buffer. “Сhain of undo” работает полностью с узлами IMU , чтобы транзакция могла откатиться ко времени T1 и также чтобы другие сессии видели запись136 во время T1.

Время T4. Во времени T4, транзакция завершается. ITL буфера 142 изменяется и commit-вектор записывается в redo log буфер для возможного восстановления когда понадобится. Сommit-тригер вызывает работу LGWR, который сбрасывает redo log буфер в оперативный журнал транзакций. IMU не нужно сбрасывать (очищать) и они могут оставаться в памяти так долго как оракл того захочет. Когда Oracle затирает или уничтожает узлы IMU, ITL буфера142 просто изменяется, чтобы уже указыватьна undo буфер 310 вместо IMU. Но пока это не произошло, любая транзакция, требующая просмотреть буфер 142 до времени T4 сошлется на IMU. Так операции по согласованному чтению (которые включают буферное копирование/клонирование и применение undo), могут выполняться полностью в памяти, используя IMU, и без соответствующих наложений undo блока/буфера. Для клонирования блока, который находится в буфере и должен претерпеть «наложение» undo , undo берется из IMU, а не из undo segment блоков.

Источник: All About Oracle’s In-Memory Undo Craig A. Shallahamer

Тэги: SGA, UNDO, общее

ОднаКнопка

2 комментария

Прокоментировать

Сергей
3 октября 2011 г. в 16:54

Время T2. п.2:
>> ITL блока 136 указывает на узел IMU
нужно: блока 142

dbstalker
4 октября 2011 г. в 16:41

Спасибо!

 

Новый комментарий

Я не спамер: введите суму 3+3



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум

Последние темы:

Нужен поставщик Дропшиппинг
10 декабря, 1 ответа
КИНО КАФЕ!!!!!!!!!!!!!!!!
10 декабря, 1 ответа