Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Этот CHECKPOINT  [new]
a
Guest
Коллеги, проконсультируйте по следующему вопросу. Например у нас есть незафиксированная транзакция. Буферный кеш активно используется и в конце концов настало время вытеснить этот измененный блок из кеша. DBWR пинает LGWR, чтобы тот скинуд реду для этого/этих измененных блоков в лог файлы. LGWR сделал это. DBWR записывает этот/эти блоки на диск - транзакция для которых все еще не зафиксирована. Происходит несколько чекпоинтов, например мы сами выполняем команду ALTER SYSTEM CHECKPOINT. Все заголовки датафайлов обновлены, информация о последнем чекпоинте добавлена также в лог и управляющий файлы. После этого происходит падение экземпляра (отключается энергия). ... Началось восстановление БД - инстанс рековери. Процесс SMON читает контролфайл и заголовки датафайлов и видит, что в датафайлах SCN END установлен в бесконечность, поэтому он принимает решение начать восстановление БД. После сканирования всех датафайлов и определения наименьшего значения чекпоинт SCN - он начинает сканировать онлайн лог файлы на предмет поиска RBA. Нашел. Потом все понятно - накат и откат незафиксированных транзакций.

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

Спасибо
31 авг 11, 07:56    [11204057]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
kraynopp
Member

Откуда: Пенза
Сообщений: 120
a,

Это всё описано в документации. Для отката транзакции будет использоваться undo tablespace, а не журналы.
31 авг 11, 08:21    [11204092]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
Ссылочку не подскажете?

Понятно, что для отката UNDO используется, которое в свою очередь будет восстанавливаться из лог файлов. Но как восстановятся UNDO блоки на момент SCN, когда наша транзакция была активна - ведь реконструкция UNDO блоков начнется с того SCN, который будет соответствовать минимальному значению чекпоинта в датафайлах, значение которого, после выполнения наших несколких ALTER SYSTEM CHECKPOINT будет больше, чем значение SCN, при котором выполнялась транзакция.
В этом и вопрос.
31 авг 11, 08:40    [11204131]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
a, при crash recovery собственно recovery начинается со thread checkpoint, и по незакрытому thread и видно что надо crash recovery делать. У тебя может упасть узел кластера и это будет crash recovery.
При нормальной работе полная контрольная точка, которая обновляет инфу в заголовках датафайлов может вообще раз в сто лет происходить и работать инкрементальные контрольные точки, да и DBWR будет пихать LGWR только если совсем уж криво настроено.
31 авг 11, 08:58    [11204167]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
wurdu, Понятно - thread checkpoint, предположим мы в дополнение к нашим сделанным ранее чекпонтам сделали несколько раз и переключение журнала и, соответственно,незакрытому thread будет другой.
31 авг 11, 09:38    [11204260]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
a
wurdu, Понятно - thread checkpoint, предположим мы в дополнение к нашим сделанным ранее чекпонтам сделали несколько раз и переключение журнала и, соответственно,незакрытому thread будет другой.
Ну и что. Мы применяем изменения начиная с thread checkpoint. Т.е. изменения, которые были потеряны в результате падения. После их применения мы получаем состояние файлов базы до падения. Дальше она открывается и происходит rollback.
31 авг 11, 10:09    [11204365]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
Я наверное что-то упустил (поправьте где не прав):

1. Момент времени t1, SCN=100 у нас есть незафиксированная транзакция, THREAD CHECKPOINT=x1;
2. Момент времени t2, (у нас произошло несколько чекпоитнов, в том сичле и ALTER SYSTEM CHECKPOINT + несколько раз мы переключили журналы ALTER SYSTEM SWITCH LOGFILE + произошло вытеснение наших измененных буферов незафиксированной транзакции на диск, маленький буферный кеш например) SCN=200, THREAD CHECKPOINT=x2;
3. Момент времени t3, экземпляр падает;
4. Момент времени t4, экземпляр запускается, SMON начинает инстанс рековери - читает управляющий файл и определяет чекпоинты каждого файла данных, на основании этой информации он сканирует лог файлы для определения начала точки восстановления (реду записей, которые будут накатываться на файлы данных и UNDO);
5. И на этом шаге не могу понять, как же Oracle откатит нашу незафиксированную транзакцию - ведь фактически чтение лог файлов будет происходит начиная с момента времени t2???
1 сен 11, 05:52    [11209886]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18483
Есть еще заголовки сегментов откатов, где видно, какие транзакции завершены, какие нет
При открытии БД они будут просканированы и запущен откат незавершенных транзакций
Как-то так...
1 сен 11, 05:58    [11209887]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Для начала, надо определиться, что в Оракле уже давно инкрементальные контрольные точки, которые не обновляют заголовки датафайлов, а в контролфайле обновляют только checkpoint progress record. Соответственно, при старте упавшего экземпляра читается checkpoint progress record и с момента последней инкрементальной контрольной точки начинается recovery. Чекпоинты каждого файла не важны, т.к. обновляются при полной контрольной точке, которая случается достаточно редко. Теперь я не могу понять, почему тебя смущает, что crash recovery начнется с момента в будущем. Хоть через год. Все прошлые изменения на диске. Мы накатываем изменения, которые не успели записаться. Цель - получить базу в состоянии до падения. Когда мы ее получаем, какие проблемы откатить эту старую транзакцию? Вся же информация по ней в базе.
1 сен 11, 06:25    [11209893]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
Спасибо за ответ Вячеслав, да конечно в заголовках сегметов отката в таблицах транзакций эта инфа есть о незафиксированных транзакциях. Совсем забыл про это !!!
Скажите а с какой целью (в литературе рекомендуется), в случае потери всех лог файлов CURRENT группы, советуют сделать ALTER SYSTEM CHECKPOINT и потом ALTER SYSTEM SWITCH LOGFILE (если эти два действия не помогут -тогда восстановление), только ли для того чтобы попытаться скинуть грязные блоки из кеша на диск??
Поясните пожалуйста
1 сен 11, 06:28    [11209896]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
a
Спасибо за ответ Вячеслав, да конечно в заголовках сегметов отката в таблицах транзакций эта инфа есть о незафиксированных транзакциях. Совсем забыл про это !!!
Скажите а с какой целью (в литературе рекомендуется), в случае потери всех лог файлов CURRENT группы, советуют сделать ALTER SYSTEM CHECKPOINT и потом ALTER SYSTEM SWITCH LOGFILE (если эти два действия не помогут -тогда восстановление), только ли для того чтобы попытаться скинуть грязные блоки из кеша на диск??
Поясните пожалуйста
Для CURRENT такое не могут рекомендовать. При невозможности записи в current, LGWR роняет базу. А вот для ACTIVE действительно рекомендуют, т.к. если этого не сделать, то при падении базы потребуется incomplete recovery, т.к. crash recovery уже не выполнишь.
1 сен 11, 06:43    [11209899]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
Спасибо wurdu за ответ, да просто запутался я. Нет, меня не смущает, что восстановление начинается с момента в будещем, просто я почему-то забыл, что инфа в UNDO сегментах при падении никуда не исчезает (смешно конечно - но вот забыл, почему -то думал что они будут просто чистые и все ...).Wurdu а предыдущий вопросу можете прокомментировать??
Спасибо

P.S. Wurdu не подскажете где можно почитать про checkpoint progress record
1 сен 11, 06:49    [11209900]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
Да, конечно, ошибся, для ACTIVE группы. Просто в литературе приведен пример, что например в случае потери всех членов акивной группы лог файлов попытаться сделать чекпоинт и если он пройдет группа должна стать неактивной. Но если все лог файлы потеряны - как может тогда пройти чекпоинт?
1 сен 11, 06:55    [11209902]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18483
Почему бы ему и не пройти. ACTIVE -- это просто DBWR не сбросил данные, которые уже можно сбросить (они уже защищены редо в ACTIVE группе). Поэтому DBWR просто сбрасывает все эти записи и ACTIVE группа становится INACTIVE, т.е. уже ненужной при crash recovery
1 сен 11, 06:58    [11209903]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
a
Да, конечно, ошибся, для ACTIVE группы. Просто в литературе приведен пример, что например в случае потери всех членов акивной группы лог файлов попытаться сделать чекпоинт и если он пройдет группа должна стать неактивной. Но если все лог файлы потеряны - как может тогда пройти чекпоинт?
Чекпоинт сбрасывает содержимое buffer cache на диск. Ну потерялась у тебя active круппа. Buffer cache остался, диск остался. Мы сбросили. После этого содержимое этой группы нам не нужно для восстановления, т.к. все данные, которые она защищает, на диске. Можно ее очищать.
1 сен 11, 06:59    [11209905]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
а
P.S. Wurdu не подскажете где можно почитать про checkpoint progress record
Есть отличная статья Сергея Маркеленкова "Об алгоритмах и пользе инкрементальных контрольных точек в СУБД Oracle" в Oracle Magazine за август 2005 г. Но с сайта она удалена и я не знаю, можно ли ее найти в инете. У меня есть, когда-то скачал. Фрагменты из нее есть здесь: Инкрементальная контрольная точка
1 сен 11, 07:09    [11209908]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
Все понятно Вячеслав и Wurdu. Спасибо большое. Я думал следующее: когда мы пытаемся выполнить чекпоинт и лог группа со статусом ACTIVE у нас потеряна мы не сможем этого сделать по той причине, что при чекпоинт фиксируется в этом оперативном лог файле/файлах. Но он-то будет это делать не в ACTIVE группе, а в CURRENT - таким образом, возможно все пройдет хорошо и активную группу мы просто, когда она у нас станет неактивной, просто пересоздадим.

Wurdu, если будет у Вас возможность скиньте мне пожалуйста инфу, которая у Вас есть мне на мыло: oracle@tf.nk.nornik.ru
1 сен 11, 08:39    [11209968]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18483
Чекпоинт не фиксируется в логе -- незачем
1 сен 11, 08:48    [11209980]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
Так, понял. Спасибо. Буду учить
1 сен 11, 08:55    [11209992]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
Лог Чекпоинтович
Guest
Вячеслав Любомудров
Чекпоинт не фиксируется в логе -- незачем
Слава, почитай про opcode 23.1 (Layer 23 opcode 1), про _two_pass
1 сен 11, 19:14    [11215075]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18483
Где?
В DSI ?
2 сен 11, 02:05    [11215880]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
Интересно, на каком этапе измененному блоку присваивается RBA адрес - ведь насколько это я понял в чекпоинт очереди все блоки уже имеют RBA - то есть они уже защищены LGWR.
2 сен 11, 10:34    [11216612]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18483
Лог Чекпоинтович
Вячеслав Любомудров
Чекпоинт не фиксируется в логе -- незачем
Слава, почитай про opcode 23.1 (Layer 23 opcode 1), про _two_pass
По здравому размышлению, таки да. Жесткий чекпоинт должен писаться в лог, ведь это обновление заголовка датафайла
5 сен 11, 01:35    [11226014]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
a
Интересно, на каком этапе измененному блоку присваивается RBA адрес - ведь насколько это я понял в чекпоинт очереди все блоки уже имеют RBA - то есть они уже защищены LGWR.
Присваивается на этапе изменения блока. К примеру:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

update tst set name = '1111111111';

1 row updated.

select dbms_rowid.ROWID_RELATIVE_FNO(rowid) fno, dbms_rowid.rowid_block_number(rowid) blockno from tst;

       FNO    BLOCKNO
---------- ----------
         1     100193

select decode(bitand(flag,1),0,'No', 'Dirty') flag_0, decode(bitand(flag,8), 0, 'No', 'Private redo') flag_3, 
    lrba_seq, lrba_bno from x$bh where FILE#=1 AND DBABLK=100193 and state = 1;

FLAG_ FLAG_3         LRBA_SEQ   LRBA_BNO
----- ------------ ---------- ----------
No    Private redo          0          0

commit;

Commit complete.

select decode(bitand(flag,1),0,'No', 'Dirty') flag_0, decode(bitand(flag,8), 0, 'No', 'Private redo') flag_3, 
    lrba_seq, lrba_bno from x$bh where FILE#=1 AND DBABLK=100193 and state = 1;

FLAG_ FLAG_3         LRBA_SEQ   LRBA_BNO
----- ------------ ---------- ----------
Dirty No                  168     284664
Т.е. в начале изменения пишутся в private redo (и, насколько я понимаю, redo для undo пишется в in-memory undo). Блок не меняется, не становится грязным но флаг 3 выставляется. После commit изменения из private redo сбрасываются, блок меняется, становится грязным, присваивается low rba, блок вставляется в CKPTQ. Это конкретный частный случай. Понятно, что из private redo сброс может происходить и без commit, а, например, по мере заполнения. Также private redo может не использоваться (RAC, supplemental logging и т.д.).
5 сен 11, 03:42    [11226070]     Ответить | Цитировать Сообщить модератору
 Re: Этот CHECKPOINT  [new]
a
Guest
Спасибо Wurdu, очень доходчиво.
5 сен 11, 06:17    [11226092]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить