Некоторые общие сведения об IMU механизме

dbstalker, 15 июня

В версиях 10g и выше, Oracle использует Undo блоки, которые находятся в приватных (для каждого серверного процесса) участках памяти и специально созданы в Shared Pool.

select * from v$sgastat where name like 'KTI%';

Немного общих разрозненных замечаний:

Каждый пул содержит Undo данные транзакции. Undo информация обновляется в заголовке блока данных, но не в undo блоках. Упрощенное описание механизма смотрите здесь. Механизм управляется двумя параметрами _in_memory_undo и _imu_pools.

select KSPPINM,KSPPDESC,KSPPSTVL,KSPPSTDVL,KSPPSTDF from X$KSPPSV a,  x$ksppi b where a.indx=b.indx and ksppinm=any('_imu_pools','_in_memory_undo') 

Пулы защищаются соответствующими защелками «In memory undo latch» (в режиме NOWAIT), тип блокировок - IM (см. v$lock_type). Если транзакция хочет получить защелку и не может, тогда транзакция выполняется без использования IMU механизма.

select name from V$latch where name like '%undo%';
select name from V$latch_children where name like ‘%undo%’;
 

А вот такую картинку вы можете наблюдать в своем alert.log при старте базы данных:

Starting ORACLE instance (normal)
…
ILAT =18         <--  Number of IMU pools/latches
…

В таблице X$BH поле FLAG становится равным 0x8002 (PRIVATE CURRENT) для блока изменяемого транзакцией.

Когда мы модифицируем данные, оракл не применяет изменения немедленно к блокам данных на диске, а размещает данные в IMU пулы в shared pool используя IMU защелки. Этот новый механизм позволяет избежать использования undo data blocks и всех связанных с этим операций, которые в случае не использования IMU были бы задействованы немедленно при старте транзакции. С использованием IMU это происходит только единожды при завершении транзакции. То есть данные сначала помещаются в соответствующий пул в shared pool и только при завершении транзакции копируются в буферный кеш и выполняются все связанные с этим операции. Каждый пул связан с одной транзакцией и поддерживается личной защелкой, что очень хорошо для уменьшения конкуренции. Количество защелок, а значит и пулов по умолчанию равно 10% от значения параметра инициализации TRANSACTIONS.

IMU pools описаны в X$ktifp. Размер каждого пула 65kb.

select ktifpno,ktifppsi from x$ktifp;

Когда пул будет полностью заполнен, то undo data будут сброшены в undo segments. Эта запись происходит в пакетном формате, то есть вся информация сбрасывается единовременно. Есть перечень событий, по которым происходит сброс пулом, их можно увидеть в таблице x$ktiff:

select  KTIFFCAT, KTIFFFLC from  x$ktiff

Статистику сброса IMU пулов можно увидеть таким образом:

select n.name, s.value from v$statname n, v$sesstat s  where n.statistic# = s.statistic#  and s.sid = (select sid from v$mystat where rownum = 1)  and n.name in ('IMU Flushes','IMU commits');

Важно отметить, что механизм IMU включатся параметром инициализации _in_memory_undo. Даже при _in_memory_undo=TRUE есть два исключения, при которых механизм IMU не работает:

  • если "turning supplemental logging on disables IMU" (Note:428167.1).
  • для RAC

В традиционном undo режиме, redo условно генерируется на два вида изменений:

  1. data block changes
  2. Undo block changes

При использовании механизма IMU, redo сформированных на вторую часть не видно в v$sesstat так как на самом деле undo сегменты не изменяются. Вместо этого undo информация помещается в shared pool, а для этих изменений redo не генерируется. Если проверить v$sesstat, то можно увидеть, что объем redo не увеличивается. Но когда undo информация из IMU пула сбрасывается в undo сегменты (чаще всего по команде commit), то на эти изменения redo генерируется. И только тогда можно увидеть увеличение объема redo в v$sesstat. Если исходить из теории, изложенной здесь, то общий объем redo информации будет меньше, чем при традиционном механизме формирования undo. Как происходит на самом деле – смотрите на своей базе.

Информацию по IMU можно почерпнуть из таблиц:

X$KTIFB
X$KTIFF
X$KTIFP
X$KTIFV

Преимущество механизма состоит в том, что уменьшаются издержки (прошу не путать с объемом) для записи redo информации на диск, так как единовременно записывается целый массив (вся redo информация, касающаяся завершенной транзакции ) redo информации как один большой блок или как единая запись (это не касается заголовка (first datablock) undo segment header), то есть не требуется отдельных операций ввода-вывода для записи единичных redo- записей. Но это не гарантирует, что объем redo информации будет меньше.

 

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

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



 

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

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

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

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


 
 

Бизнес форум

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

Расписание автобусов
18 июля, 3 ответа
Отдых в августе
17 июля, 4 ответа