Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Контрольная точка  [new]
Ruslan2005
Member

Откуда:
Сообщений: 148
Вот решил обсудить механизм нормальных и инкрементальных контрольных точек в 9i.
Насколько я понял нормальная точка вызывается:

• при переключении оперативных журнальных групп (log switch).
• при выполнении команды ALTER SYSTEM CHECKPOINT;
• при выполнении команды SHUTDOWN NORMAL/ TRANSACTIONAL/IMMEDIATE;
• при восстановлении после сбоя экземпляра (instance recovery) или сбоя носителя (media recovery).
• при выполнении команд ALTER TABLESPACE XXX OFFLINE NORMAL/TEMPORARY, ALTER TABLESPACE XXX READ ONLY/BEGIN BACKUP;
• при выполнении команды ALTER DATABASE DATAFILE XXX OFFLINE;

То есть по сути при обычном режиме без действий администратора это только первый пункт.При наступление нормальной контрольной точки происходит следующие:
Определяется checkpoint SCN момент на который будет согласована информация во всех структурах базы данных
Процесс DBWR дает сигнал процессу LGWR записать в журнальные файлы всю информацию из log buffer, которая “защищает” изменения в блоках данных до checkpoint SCN включительно. DBWR ждет LGWR.
DBWR записывает в файлы данных все “грязные” блоки, последние изменения которых были сделаны до checkpoint SCN включительно.
• После окончания записи DBWR дает сигнал CKPT обновить информацией о прошедшей контрольной точке заголовки всех online-файлов данных табличных пространств
Теперь о механизме срабатывания инкрементальной контрольной точке. Её наступление характеризуется след изменениям
Каждые 3 секунды DBWR просыпается и выясняет не произошло ли превышение одного из параметров
LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT, FAST_START_IO/MTTR_TARGET. Если это проиозошло то он начинает запись буферов из грязного списка на диск и по окончании вносит соот. запись в контрол-файл. Причем как выяснилось размер LOG_CHECKPOINT_INTERVAL Oracle неявно корректирует так, чтобы он не превосходил 90% размера наименьшего журнального файла.
Исходя из этого решил провести эксперимент
анализировал состояние полей ACTUAL_REDO_BLKS и TARGET_REDO_BLKS вьюшки V$Instance_Recovery на 2 базах, где

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

Target_Redo_Blks Целевое (к которому Oracle стремится) количество блоков журнального файла, которое должно быть прочитано при восстановлении. Текущий минимум из последующих четырех ( трех для версии 9i и выше) столбцов.

Log_File_Size_Redo_Blks 90% размера наименьшего журнального файла в блоках журнала. Фиксирован. Это максимальное количество журнальных блоков, необходимых для того, чтобы не произошло переключения журнала до завершения контрольной точки.

Log_Chkpt_Timeout_Redo_Blks Количество блоков журнального файла, которое должно быть прочитано при восстановлении, чтобы выполнить требование параметра инициализации LOG_CHECKPOINT_TIMEOUT. Динамический. Увеличивается, если количеств журнальных блоков, записанных за LOG_CHECKPOINT_TIMEOUT секунд, растет (скорость записи в журнал растет), и уменьшается в противном случае вплоть до 0.

Log_Chkpt_Interval_Redo_Blks Количество блоков журнального файла, которое должно быть прочитано при восстановлении, чтобы выполнить требование параметра инициализации LOG_CHECKPOINT_INTERVAL. Фиксирован. Равен LOG_CHECKPOINT_INTERVAL.

Fast_Start_IO_Target_Redo_Blks Количество блоков журнального файла, которое должно быть прочитано при восстановлении, чтобы выполнить требование параметра инициализации FAST_START_IO_TARGET. Динамический. Растет, если отметка контрольной точки движется по другой причине (LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT). Мало изменяется, если отметку контрольной точки двигает сам параметр FAST_START_IO_TARGET. В Oracle9i считается устаревшим, всегда имеет значение NULL и поддерживается только в целях совместимости.

на первой базе (база для отчетов) изменений практически нет - ACTUAL_REDO_BLKS росло по мере и постепенно приближалось к границе TARGET_REDO_BLKS, однако её не достигало потому что через каждые 10 минут срабатывала нормальная контрольная точка и сбрасывала счетчик ACTUAL_REDO_BLKS снова на 0 и все по новой
на второй базе на которой идут активные транзакции скорость записи в редолог примерно в 70 раз выше происходила картина похожая на первый случай, но с одним различием счетчик ACTUAL_REDO_BLKS сбрасывается каждые примерно 2-4 секунды не достигая предельное значения TARGET_REDO_BLKS причем вызвано это не наступлением контрольной точки и как мы видим не наступлением инкрементальной контрольной точки до значения Target_Redo_Blks не достигнуто (различие примерно на 3 порядка от наибольшего ACTUAL_REDO_BLKS). Вот и вопрос чем же вызвана то что оракл фактически записывает грязные блоки в файлы данных с такой интенсивностью хотя вроде бы условий для этого еще не наступает?
извиняюсь за долгий монолог. но старался расписать все как можно детальней чтоб не было лишних вопросов.
12 мар 09, 15:28    [6917507]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
Ruslan2005,
"• при выполнении команды ALTER DATABASE DATAFILE XXX OFFLINE;"
это не так... и автор статьи об этом уже не раз напоминал.
автор
Вот и вопрос чем же вызвана то что оракл фактически записывает грязные блоки в файлы данных с такой интенсивностью хотя вроде бы условий для этого еще не наступает?

ну DBWR пишет на диск не только при наступлении контрольной точки...
12 мар 09, 15:35    [6917589]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Ruslan2005
Member

Откуда:
Сообщений: 148
то есть вы хотите сказать что грязные блоки записываются в датафайлы что собственно и показывает уменьшение поля ACTUAL_REDO_BLKS не только при наступление контрольной точки (нормальной или инкрементальной)? а когда еще?
12 мар 09, 15:41    [6917635]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
DВА
Member

Откуда:
Сообщений: 5439
Ruslan2005
то есть вы хотите сказать что грязные блоки записываются в датафайлы что собственно и показывает уменьшение поля ACTUAL_REDO_BLKS не только при наступление контрольной точки (нормальной или инкрементальной)? а когда еще?

да собственно все время :)
работа у него такая
12 мар 09, 15:44    [6917671]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
Ruslan2005
то есть вы хотите сказать что грязные блоки записываются в датафайлы что собственно и показывает уменьшение поля ACTUAL_REDO_BLKS не только при наступление контрольной точки (нормальной или инкрементальной)? а когда еще?

ну как минимум, согласно LRU алгоритму при заполнении буферного кеша сга....
12 мар 09, 15:45    [6917682]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Серафимный Шестикрыл
Member [заблокирован]

Откуда: С луны свалился
Сообщений: 2922
Ruslan2005
то есть вы хотите сказать что грязные блоки записываются в датафайлычто собственно и показывает уменьшение поля ACTUAL_REDO_BLKS


Вы путаете теплое с мягким:

SQL> edit
Wrote file afiedt.buf

  1  select y.name, y.value from v$sysstat y
  2* where name like '%DBWR%'
SQL> /

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
DBWR checkpoint buffers written                                     1683654
DBWR thread checkpoint buffers written                              1616980
DBWR tablespace checkpoint buffers written                                0
DBWR parallel query checkpoint buffers written                            0
DBWR object drop buffers written                                      19711
DBWR transaction table writes                                         11349
DBWR undo block writes                                              1743421
DBWR revisited being-written buffer                                      24
DBWR make free requests                                                   0
DBWR lru scans                                                            0
DBWR checkpoints                                                       2118

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
DBWR fusion writes                                                        0

12 rows selected.

SQL> select ACTUAL_REDO_BLKS from v$instance_recovery;

ACTUAL_REDO_BLKS
----------------
          179055

SQL> truncate table t;

Table truncated.

SQL> select ACTUAL_REDO_BLKS from v$instance_recovery;

ACTUAL_REDO_BLKS
----------------
          179424

SQL> select y.name, y.value from v$sysstat y
  2  where name like '%DBWR%'
  3  /

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
DBWR checkpoint buffers written                                     1683654
DBWR thread checkpoint buffers written                              1616980
DBWR tablespace checkpoint buffers written                                0
DBWR parallel query checkpoint buffers written                            0
DBWR object drop buffers written                                      23003
DBWR transaction table writes                                         11349
DBWR undo block writes                                              1743421
DBWR revisited being-written buffer                                      24
DBWR make free requests                                                   0
DBWR lru scans                                                            0
DBWR checkpoints                                                       2120

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
DBWR fusion writes                                                        0

12 rows selected.
12 мар 09, 15:57    [6917811]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Ruslan2005
Member

Откуда:
Сообщений: 148
Серафимный Шестикрыл
Ruslan2005
то есть вы хотите сказать что грязные блоки записываются в датафайлычто собственно и показывает уменьшение поля ACTUAL_REDO_BLKS


Вы путаете теплое с мягким:

SQL> edit
Wrote file afiedt.buf

  1  select y.name, y.value from v$sysstat y
  2* where name like '%DBWR%'
SQL> /

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
DBWR checkpoint buffers written                                     1683654
DBWR thread checkpoint buffers written                              1616980
DBWR tablespace checkpoint buffers written                                0
DBWR parallel query checkpoint buffers written                            0
DBWR object drop buffers written                                      19711
DBWR transaction table writes                                         11349
DBWR undo block writes                                              1743421
DBWR revisited being-written buffer                                      24
DBWR make free requests                                                   0
DBWR lru scans                                                            0
DBWR checkpoints                                                       2118

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
DBWR fusion writes                                                        0

12 rows selected.

SQL> select ACTUAL_REDO_BLKS from v$instance_recovery;

ACTUAL_REDO_BLKS
----------------
          179055

SQL> truncate table t;

Table truncated.

SQL> select ACTUAL_REDO_BLKS from v$instance_recovery;

ACTUAL_REDO_BLKS
----------------
          179424

SQL> select y.name, y.value from v$sysstat y
  2  where name like '%DBWR%'
  3  /

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
DBWR checkpoint buffers written                                     1683654
DBWR thread checkpoint buffers written                              1616980
DBWR tablespace checkpoint buffers written                                0
DBWR parallel query checkpoint buffers written                            0
DBWR object drop buffers written                                      23003
DBWR transaction table writes                                         11349
DBWR undo block writes                                              1743421
DBWR revisited being-written buffer                                      24
DBWR make free requests                                                   0
DBWR lru scans                                                            0
DBWR checkpoints                                                       2120

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
DBWR fusion writes                                                        0

12 rows selected.


с данным примером согласен но я просматривал и у меня по базе каждые 2-4 секунды идет рост по
DBWR checkpoint buffers written хотя никаких контрольных точек не происходит.
12 мар 09, 16:01    [6917850]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Ruslan2005
Member

Откуда:
Сообщений: 148
DВА
Ruslan2005
то есть вы хотите сказать что грязные блоки записываются в датафайлы что собственно и показывает уменьшение поля ACTUAL_REDO_BLKS не только при наступление контрольной точки (нормальной или инкрементальной)? а когда еще?

да собственно все время :)
работа у него такая

вообще я считал что запись то есть перемещение из грязных списков в датафайлы происходит только при контрольных точках? как я понимаю еще сюда может вмешиваться фактор наличия свободных блоков в LRU?если их мало то сброс в датафайлы происходит и без наступления контрольной точки (неважно какого вида полной или инкрементальной)?
12 мар 09, 16:05    [6917892]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Серафимный Шестикрыл
Member [заблокирован]

Откуда: С луны свалился
Сообщений: 2922
Ruslan2005
хотя никаких контрольных точек не происходит.


А как вы это определяете ?
12 мар 09, 16:08    [6917917]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
Ruslan2005
DВА
Ruslan2005
то есть вы хотите сказать что грязные блоки записываются в датафайлы что собственно и показывает уменьшение поля ACTUAL_REDO_BLKS не только при наступление контрольной точки (нормальной или инкрементальной)? а когда еще?

да собственно все время :)
работа у него такая

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

блок может быть записан на диск как в следствии контрольной точки, так и в следствии того, что он был вытеснен из буферного кеша.. к примеру, товарищь сделал апдейт, закомитил и ушел. Больше данные из этого блоки никому не были нужны. Touch count у блока не увеличивался, и его тихонько выпихнули на диск. При этом, если данные из блока никто не считывал, то на диск он попадет грязненьким
12 мар 09, 16:14    [6917968]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Ruslan2005
Member

Откуда:
Сообщений: 148
Серафимный Шестикрыл,

по логу в случае нормальной контрольной точки никаких переключений журналов за этой время нет
и инкрементальной тоже нет так как параметры которые её определяют и отражены в V$Instance_Recovery полями ACTUAL_REDO_BLKS и TARGET_REDO_BLKS весьма далеки в своих значениях друг от друга.однако запись явно идет так как DBWR checkpoint buffers written растет каждые 2-4 сек и значение ACTUAL_REDO_BLKS прыгает от 0 до 500-600 в том время как TARGET_REDO_BLKS установлено в районе 180 000.
12 мар 09, 16:15    [6917986]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Серафимный Шестикрыл
Member [заблокирован]

Откуда: С луны свалился
Сообщений: 2922
pravednik
При этом, если данные из блока никто не считывал, то на диск он попадет грязненьким


А если считывали, то на диск он попадет чистеньким ?
12 мар 09, 16:16    [6917992]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Инкрементал Чекпоинтович
Guest
Жду прихода ламера-Попрошайки. Попкорна нет, но есть семечки
12 мар 09, 16:20    [6918039]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
Серафимный Шестикрыл
pravednik
При этом, если данные из блока никто не считывал, то на диск он попадет грязненьким


А если считывали, то на диск он попадет чистеньким ?

с "чистеньким" заголовком, который проапдейтится актуальной инфой из анду, принесенной селектом, который его затребует
12 мар 09, 16:26    [6918113]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Ruslan2005
Member

Откуда:
Сообщений: 148
шутники)))
ладно суть объяснений pravednik'a понятно это повидимому есть либо некое пороговое значение времени нахождения слабоиспользумого буфера в списке LRU или пороговое значение для объема dirty списка после которого происходит его очистка и запись буфера в датафайл. так?
12 мар 09, 16:33    [6918194]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Серафимный Шестикрыл
Member [заблокирован]

Откуда: С луны свалился
Сообщений: 2922
pravednik
с "чистеньким" заголовком, который проапдейтится актуальной инфой из анду, принесенной селектом, который его затребует


Ну-ка, ну-ка вот с этого места развей мысль...
12 мар 09, 16:35    [6918221]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
Серафимный Шестикрыл
pravednik
с "чистеньким" заголовком, который проапдейтится актуальной инфой из анду, принесенной селектом, который его затребует


Ну-ка, ну-ка вот с этого места развей мысль...

вы, уважаемый, провокатор еще тот ;)))

я имел ввиду отложенную очистку блока...уверен, что для вас этого будет достаточно.
12 мар 09, 16:44    [6918308]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Инкрементал Чекпоинтович
Guest
Серафимный Шестикрыл
pravednik
с "чистеньким" заголовком, который проапдейтится актуальной инфой из анду, принесенной селектом, который его затребует


Ну-ка, ну-ка вот с этого места развей мысль...
"Тьфу, тьфу..." - летела лузга от семечек из рта сытого и довольного, развалившегося в кресле перед 22-дюймовым монитором и периодически запивающего семечки чаем из большой темно-синей кружки Инкрементал Чекпоинтовича...
12 мар 09, 16:45    [6918318]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Серафимный Шестикрыл
Member [заблокирован]

Откуда: С луны свалился
Сообщений: 2922
Ruslan2005
так?


Дабы тут не развлекать Равниныча, запасшегося семечками,
рекомендую

Steven Adams about DBWR

Ну и заодно DSI405, поройся у китайцев.
12 мар 09, 16:48    [6918342]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Серафимный Шестикрыл
Member [заблокирован]

Откуда: С луны свалился
Сообщений: 2922
pravednik
вы, уважаемый, провокатор еще тот ;)))


я белый и пушистый, но большая сволочь.

pravednik

я имел ввиду отложенную очистку блока...уверен, что для вас этого будет достаточно.


Не-а, не угадал :)
Дело в том, что понятие чистоты, точнее, "грязноты" блока никакого отношения к его "очистке" не имеет. И это становится понятно, если подумать, почему DBWR вдруг приспичило этот блок
записать на диск.
12 мар 09, 16:52    [6918378]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Серафимный Шестикрыл
Member [заблокирован]

Откуда: С луны свалился
Сообщений: 2922
Инкрементал Чекпоинтович
периодически запивающего семечки чаем


В ужосе

Ты заболел ?
12 мар 09, 16:53    [6918392]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Контрольная Бочка
Guest
Серафимный Шестикрыл
Инкрементал Чекпоинтович
периодически запивающего семечки чаем


В ужосе

Ты заболел ?
"Не дождетесь!"
С велотренажера недавно слез. Ну и пить хоцца
12 мар 09, 17:09    [6918550]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Ruslan2005
Member

Откуда:
Сообщений: 148
Серафимный Шестикрыл,

спасибо почитаем но хоть в верном направлении мыслю в моем последнем сообщении?
12 мар 09, 17:12    [6918576]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
Серафимный Шестикрыл
Member [заблокирован]

Откуда: С луны свалился
Сообщений: 2922
Ruslan2005
в верном направлении мыслю в моем последнем сообщении?


В верном :) Но есть нюансы и они зависят от версии.
Когда будешь разбираться, погляди, например, на заголовки буферов
в версиях 9 и 10 ;)
12 мар 09, 17:14    [6918592]     Ответить | Цитировать Сообщить модератору
 Re: Контрольная точка  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
Серафимный Шестикрыл

Не-а, не угадал :)
Дело в том, что понятие чистоты, точнее, "грязноты" блока никакого отношения к его "очистке" не имеет. И это становится понятно, если подумать, почему DBWR вдруг приспичило этот блок
записать на диск.

хм...тогда проясните, если несложно, правильно ли я мыслю в следующем моменте....
Наверно стоит разделить поянтия "Буфер" и "Блок"
Буфер - место в кеше под блок.
Блок - собсна, блок на диске.
То есть понятие грязноты Буфера никакого отношение к очистке блока не имеет.
Грязность буфера определяется flag из x$bh ну или из v$bh..
Грязность блока в моем понимании, определяет Flag
Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0007.005.000005f5  0x00c009f8.02bc.0b  --U-    1  fsc 0x0000.002dd0fc
0x02   0x0008.017.00000606  0x00c0021b.031f.09  C---    0  scn 0x0000.002dcc55
0x03   0x0001.017.000005f3  0x00c007a3.02d8.08  C---    0  scn 0x0000.002dcc73
то есть транзакция уже закомичена, но не очищена
или
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0007.005.000005f5  0x00c009f8.02bc.0b  C---    0  scn 0x0000.002dd0fc
0x02   0x0004.01d.000005dd  0x00c002b7.0232.01  ----    1  fsc 0x0000.00000000
0x03   0x0001.017.000005f3  0x00c007a3.02d8.08  C---    0  scn 0x0000.002dcc73
транзакция еще активна...
при этом буфер может как находится в кеше и быть и грязным и нет.
+
Start dump data blocks tsn: 0 file#:1 minblk 91009 maxblk 91009
Block dump from cache:
Dump of buffer cache at level 4 for tsn=0, rdba=4285313
BH (0x75bd8148) file#: 1 rdba: 0x00416381 (1/91009) class: 1 ba: 0x75802000
  set: 6 bsz: 8192 bsi: 0 sflg: 0 pwc: 0, 15 lid: 0x00000000,0x00000000
  dbwrid: 0 obj: 73621 objn: 73621 tsn: 0 afn: 1
  hash: [0x773e3958,0x842fd4c0] lru: [0x763de468,0x76be6f58]
  ckptq: [NULL] fileq: [NULL] objq: [0x80fa2548,0x80fa2548]
  st: XCURRENT md: NULL tch: 1
  flags: block_written_once redo_since_read gotten_in_current_mode
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [1]
  cr pin refcnt: 0 sh pin refcnt: 0
  buffer tsn: 0 rdba: 0x00416381 (1/91009)
  scn: 0x0000.002dd0fc seq: 0x01 flg: 0x06 tail: 0xd0fc0601
  frmt: 0x02 chkval: 0x0a45 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x0000000075802000 to 0x0000000075804000
075802000 0000A206 00416381 002DD0FC 06010000  [.....cA...-.....]
075802010 00000A45 00000001 00011F95 002DD0FA  [E.............-.]
075802020 00000000 00030003 00000000 00050007  [................]
075802030 000005F5 00C009F8 000B02BC 00002001  [............. ..]
075802040 002DD0FC 00170008 00000606 00C0021B  [..-.............]
075802050 0009031F 00008000 002DCC55 00170001  [........U.-.....]
075802060 000005F3 00C007A3 000802D8 00008000  [................]
075802070 002DCC73 00050100 001CFFFF 1F3F1F5B  [s.-.........[.?.]
075802080 00001F3F 1F820005 1F701F79 1F5E1F67  [?.......y.p.g.^.]
075802090 00000000 00000000 00000000 00000000  [................]
        Repeat 499 times
075803FD0 002C0000 06C10201 2C000000 C1020100  [..,........,....]
075803FE0 00000005 0201002C 000004C1 01002C00  [....,........,..]
075803FF0 0003C102 012C0000 02C10201 D0FC0601  [......,.........]
Block header dump:  0x00416381
 Object id on Block? Y
 seg/obj: 0x11f95  csc: 0x00.2dd0fa  itc: 3  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0007.005.000005f5  0x00c009f8.02bc.0b  --U-    1  fsc 0x0000.002dd0fc
0x02   0x0008.017.00000606  0x00c0021b.031f.09  C---    0  scn 0x0000.002dcc55
0x03   0x0001.017.000005f3  0x00c007a3.02d8.08  C---    0  scn 0x0000.002dcc73
bdba: 0x00416381

Start dump data blocks tsn: 0 file#:1 minblk 91009 maxblk 91009
Block dump from cache:
Dump of buffer cache at level 4 for tsn=0, rdba=4285313
BH (0x723df348) file#: 1 rdba: 0x00416381 (1/91009) class: 1 ba: 0x720c2000
  set: 6 bsz: 8192 bsi: 0 sflg: 0 pwc: 0, 15 lid: 0x00000000,0x00000000
  dbwrid: 0 obj: 73621 objn: 73621 tsn: 0 afn: 1
  hash: [0x75bd8148,0x842fd4c0] lru: [0x76bdc0c8,0x8434e650]
  obj-flags: object_ckpt_list
  ckptq: [0x8438b948,0x8438b948] fileq: [0x8438b968,0x8438b968] objq: [0x80fa2558,0x80fa2558]
  st: XCURRENT md: NULL tch: 1
  flags: buffer_dirty block_written_once redo_since_read
          gotten_in_current_mode
  LRBA: [0x80.b1.0] LSCN: [0x0.2dd1c8] HSCN: [0x0.2dd1c8] HSUB: [1]
  cr pin refcnt: 0 sh pin refcnt: 0
  buffer tsn: 0 rdba: 0x00416381 (1/91009)
  scn: 0x0000.002dd1c8 seq: 0x01 flg: 0x00 tail: 0xd1c80601
  frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00000000720C2000 to 0x00000000720C4000
0720C2000 0000A206 00416381 002DD1C8 00010000  [.....cA...-.....]
0720C2010 00000000 00000001 00011F95 002DD1C7  [..............-.]
0720C2020 00000000 00030003 00000000 00050007  [................]
0720C2030 000005F5 00C009F8 000B02BC 00008000  [................]
0720C2040 002DD0FC 001D0004 000005DD 00C002B7  [..-.............]
0720C2050 00010232 00000001 00000000 00170001  [2...............]
0720C2060 000005F3 00C007A3 000802D8 00008000  [................]
0720C2070 002DCC73 00050100 001CFFFF 1F3F1F5B  [s.-.........[.?.]
0720C2080 00001F3F 1F820005 1F701F79 1F5E1F67  [?.......y.p.g.^.]
0720C2090 00000000 00000000 00000000 00000000  [................]
        Repeat 499 times
0720C3FD0 002C0000 06C10201 2C000000 C1020100  [..,........,....]
0720C3FE0 00000005 0201002C 000004C1 01002C00  [....,........,..]
0720C3FF0 0003C102 022C0000 02C10201 D1C80601  [......,.........]
Block header dump:  0x00416381
 Object id on Block? Y
 seg/obj: 0x11f95  csc: 0x00.2dd1c7  itc: 3  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0007.005.000005f5  0x00c009f8.02bc.0b  C---    0  scn 0x0000.002dd0fc
0x02   0x0004.01d.000005dd  0x00c002b7.0232.01  ----    1  fsc 0x0000.00000000
0x03   0x0001.017.000005f3  0x00c007a3.02d8.08  C---    0  scn 0x0000.002dcc73


так и нет...
+
Start dump data blocks tsn: 0 file#:1 minblk 91009 maxblk 91009
Block dump from cache:
Dump of buffer cache at level 4 for tsn=0, rdba=4285313
Block dump from disk:
buffer tsn: 0 rdba: 0x00416381 (1/91009)
scn: 0x0000.002dd1c8 seq: 0x01 flg: 0x04 tail: 0xd1c80601
frmt: 0x02 chkval: 0xe454 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002AD806C7FA00 to 0x00002AD806C81A00
2AD806C7FA00 0000A206 00416381 002DD1C8 04010000  [.....cA...-.....]
2AD806C7FA10 0000E454 00000001 00011F95 002DD1C7  [T.............-.]
2AD806C7FA20 00000000 00030003 00000000 00050007  [................]
2AD806C7FA30 000005F5 00C009F8 000B02BC 00008000  [................]
2AD806C7FA40 002DD0FC 001D0004 000005DD 00C002B7  [..-.............]
2AD806C7FA50 00010232 00000001 00000000 00170001  [2...............]
2AD806C7FA60 000005F3 00C007A3 000802D8 00008000  [................]
2AD806C7FA70 002DCC73 00050100 001CFFFF 1F3F1F5B  [s.-.........[.?.]
2AD806C7FA80 00001F3F 1F820005 1F701F79 1F5E1F67  [?.......y.p.g.^.]
2AD806C7FA90 00000000 00000000 00000000 00000000  [................]
        Repeat 499 times
2AD806C819D0 002C0000 06C10201 2C000000 C1020100  [..,........,....]
2AD806C819E0 00000005 0201002C 000004C1 01002C00  [....,........,..]
2AD806C819F0 0003C102 022C0000 02C10201 D1C80601  [......,.........]
Block header dump:  0x00416381
 Object id on Block? Y
 seg/obj: 0x11f95  csc: 0x00.2dd1c7  itc: 3  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0007.005.000005f5  0x00c009f8.02bc.0b  C---    0  scn 0x0000.002dd0fc
0x02   0x0004.01d.000005dd  0x00c002b7.0232.01  ----    1  fsc 0x0000.00000000
0x03   0x0001.017.000005f3  0x00c007a3.02d8.08  C---    0  scn 0x0000.002dcc73
bdba: 0x00416381
13 мар 09, 11:17    [6921578]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить