Содержимое журналов повторного выполнения

dbstalker, 10 октября

Формируемые данные для журналов повторного выполнения представляют собой запись, состоящую из векторов изменений. Эти вектора описывают изменения, сделанные в

  1. блоке сегмента данных таблицы
  2. блоке данных сегмента отката
  3. таблице транзакций сегментов отката.

Я попытаюсь ответить на такие вопросы:

Что собой представляет вектор изменения (change#)?

Вектор изменения - описание любого изменения, сделанное в любом (одном !) блоке БД.

Он состоит из заголовка, массива длин изменений и массива изменений.

Заголовок состоит из Change number, Change type, Class(соответствует полю class в x$BH), Absolute File Number, Relative Database Block, Address, System Change Number, Sequence Number (relative to SCN), Operation Code.

Заголовок вектора изменения может быть, например, таким:

CHANGE #2 TYP:0 CLS: 1 AFN:5 DBA:0x0144d023 SCN:0x0000.0ac67cce SEQ: 4 OP:11.5

Что собой представляет redo -запись?

Redo -запись ( redo record ) состоит из заголовка и одного или нескольких векторов изменения. Каждая redo-запись содержит данные undo и redo для атомарного изменения. То есть, чаще всего запись содержит вектор изменения в блоке сегмента данных таблицы, вектор изменения в блоке данных сегмента отката и вектор изменения в таблице транзакций сегментов отката.Некоторым изменениям не требуется undo

Атомарное изменение (единое целое) – применяются все вектора записи или ни одного.

Заголовок состоит из следующей информации :

Thread	      Thread Number
RBA	      Redo Byte Address
LEN	      Length of record in bytes
SCN	      System Change Number
 	      Date and Time of Change

Например:

REDO RECORD - Thread:1 RBA: 0x003666.000000cf.0010 LEN: 0x019c VLD: 0x01 SCN: 0x0000.00eb1279 SUBSCN:  1 05/08/2007 15:44:12

Что собой представляет RBA?

RBA может, например, быть таким: 0x003666.000000cf.0010

RBA имеет длину в 10 bytes и идентифицирует адрес начала redo-записи. Адрес включает в себя Log sequence number (0x3666),Block number within redo log (0xcf),Byte number within block (0x10)

Что собой представляет SCN?

Например, SCN:0x0000.0ac67cc3

Определяет номер закомиченной версии данных, имеет длину 6 bytes и состоит из Wrap (2 bytes) и Base (4 bytes).

Что собой представляет файл журнала повторного выполнения?

Файл включает все изменения совершенные

  • DML командами: INSERT, UPDATE, DELETE, SELECT FOR UPDATE, но не содержит текста этих команд
  • в словаре DDL -командами, включает текст этих команд

Запись в файл проводится последовательно.

На рисунке показано, какие данные содержаться в журнале на примере небольшой транзакции :

В статье использовались материалы «Redo Internals» Julian Dyke Independent Consultant

Себе и вам на заметку интересная статья: "Анализируем Redo-логи".

7 комментариев

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

Vladimir
7 мая 2008 г. в 09:54

У меня снова возникли вопросы к статье:
1) Что из себя представляет массив изменений в векторе изменений? Его заголовок описан, пример приведен, все ясно. Массив длин изменений тоже вроде как понятно - "длина изменений" (хотя, что это такое - остается неясным), а вот "массив изменений" - темная лошадка. Рисунок, честно говоря, ничего не проясняет.
2) Далее: redo-запись состоит из своего заголовка и одного или нескольких векторов изменений. Вроде как понятно, что в поле RBA заголовка redo-записи есть участок "Byte number within block", который отвечает за номер измененного байта в блоке данных. Если я неправильно понимаю, поправьте. А что, если redo-запись содержит несколько векторов изменений, как тогда указывается номер байта в блоке данных? Простым перечислением?
3) Последний рисунок вообще не пояснен. Что означает UNDO и UNDO Header, совершенно непонятно - это redo-информация сегментов отката? Нельзя ли поподробнее про Slot. А также получается, что в redo-журналах хранится избыточная информация (в пользу надежности системы), ведь undo в нем нужны на случай сбоя системы, а потом лежат мертвым грузом? Так как в случае наката от какого-то состояния БД в прошлом будут использована только redo-информация?
P.S.: кстати, рисунки большие и некрасивые в отличие от появившихся рисунков к статье "Формат блока в ORACLE".

dbstalker
12 мая 2008 г. в 12:50

По поводу первого вопроса: что собой представляет redo-запись лучше всего видно в дампе. Выполните команду, например, ALTER SYSTEM DUMP LOGFILE 'K:\oracle\oradata\my_db\redo01.log'. B папке user_dump_dest посмотрите полученый файл. Картина прояснится. По поводу второго вопроса: RBA (Redo Byte Address) -КАЖДАЯ redo-запись имеет этот адрес, который определяет её начало. В нём НЕ содержится адреса изменяемого блока. По поводу третьего вопроса. Думаю, когда Вы посмотрите дамп своего редо лога, то первая часть вопроса отпадет. по поводу оставшейся части: почитайте мой пост http://my-oracle.it-blogs.com.ua/post-69.aspx, там немного розписано для чего нужна undo информация в redo логах. И не забывайте, что восстановление возможно на любой момент в прошлом.В этом случае также не обойтись без undo информации.

Vladimir
12 мая 2008 г. в 16:13

Спасибо за ответы. Начну сразу с третьего вопроса: статью я читал, но в ней нигде явно не написано, что состояние БД можно восстановить на любой момент времени. Правда, как я понимаю, восстановление возможно начиная с момента, на который снят дамп БД путем наката по данным redo-журналов. Все ясно.
По поводу первого вопроса. Вот что я смог получить:
REDO RECORD - Thread:1 RBA: 0x021c18.00000003.00f0 LEN: 0x003c VLD: 0x01

SCN: 0x000a.7a9897ef SUBSCN: 1 05/12/2008 15:16:48

CHANGE #1 TYP:0 CLS: 1 AFN:74 DBA:0x1299d873 SCN:0x000a.6ef39438 SEQ: 1 OP:4.1

Block cleanout record, scn: 0x000a.7a9897ef ver: 0x01 opt: 0x01, entries follow...

itli: 1 flg: 1 scn: 0x000a.790aa931

Здесь первые две строки - это заголовок redo-записи, далее идет заголовок вектора изменения. А вот что такое "Block cleanout record, scn: 0x000a.7a9897ef ver: 0x01 opt: 0x01, entries follow...

itli: 1 flg: 1 scn: 0x000a.790aa931 " - непонятно..

dbstalker
12 мая 2008 г. в 18:08

По поводу восстановления по времени: если у Вас версия ниже 10g, то есть такая команда recover database until time. Для версии 10g и выше там совсем другая история: там возможен как накат вперед так и назад. Теперь относительно Block cleanout record.Это, скорее всего, отложенная очистка блока. Чтобы с этим разобраться, опять советую почитать статью Скулкина Дмитрия Управление пространством внутри блока данных. А так же мой очень-очень упрощенный пост Очистка блоков данных. В тему,наверное, будет еще и пост Типы блокировок , так как Block cleanout record появляется, когда ITL(список заинтересованных транзакций), который находится в заголовке блока, не обновился, хотя транзакция завершилась.

Vladimir
14 мая 2008 г. в 09:26

Да, стало понятно, спасибо.

Andrey
7 октября 2010 г. в 09:43

Решил написать программку, которая на стэндбае по команде ALTER SYSTEM DUMP LOGFILE создает файлик с содержимым архивлога, затем проверяет на наличие ошибок, затем накатывает этот архивлог на стэндбай. Столкнулся с тем, что на промышленной базе команда ALTER SYSTEM DUMP LOGFILE отрабатывает быстро, а на стэндбае долго - минут 15-20. С чем такое может быть связано? Как можно исправить?

dbstalker
7 октября 2010 г. в 17:16

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

 

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

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



 

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

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

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

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


 
 

Бизнес форум

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

Кейс: Льем на Gardenin c Instagram
22 февраля, 1 ответа
Житло
20 февраля, 1 ответа
покер
19 февраля, 2 ответа