Количество ожиданий в Oracle 10g (Number of Wait Events in Oracle 10g)

Сегодня читала про ожидания в Oracle 10g и наткнулась на эту презентацию, где увидела этот график:
Я знала, что в Oracle 10g появилось очень много новых событий ожидания (wait events) но даже не думала, что настоолько много! Первым делом решила проверить это и посчитала кол-во событий ожидания в версиях 9i и 10g:

В Oracle 9.2.0.8:

SQL> select count(*) from v$event_name;

  COUNT(*)
----------
       406

В Oracle 10.2.0.4:

SQL> select count(*) from v$event_name;

  COUNT(*)
----------
       889

В 10g кол-во ожиданий увеличилось больше чем вдвое: было 406, стало 889! Здесь пишут, что события ожидания в Oracle 10g стали более "descriptive", то есть более описательными, более детальными.

Wait event names in Oracle 10g are more descriptive in the areas of latches, enqueues, and buffer busy waits.

Здесь я писала об одном из таких примеров, когда из ожидания buffer busy waits "родилось и отколось" ожидание read by other session.

Размер redo блоков (Redo log block size)

Сегодня хотела бы написать об размере блоков redo log buffer'а. Все мы знаем, о размере блока базы данных, который устанавливается параметром db_block_size, и который задает размер блоков в файлах данных и размер буфферов в буфферном кеше.

А какая структура у redo log buffer'а? Понятно, что она - цикличная, запись в него выполняется последовательно, не то что в буфферном кеше или в файлах данных, когда чтение и запись выполняется вразброс.

Мне всегда казалось, что если она цикличная и запись в него последовательная, то и думать тут не о чем: значит у него и структура памяти какая-то неразрывная, что ли.

Сегодня, когда пыталась понять смысл латча redo allocation, не могла понять, зачем вообще нужен этот латч... Что тут выделять-то? Память под redo log buffer уже выделена же в SGA. У Стива Адамса прочитала следующее:

The redo allocation latch must be taken to allocate space in the log buffer. This latch protects the SGA variables that are used to track which log buffer blocks are used and free.

Вот так я узнала, что redo log buffer состоит из блоков одинакового размера, а его цикличность - это структура данных, а в памяти они могут находится вразброс.

А теперь, собственно, про размер блоков redo log buffer'а. Стив Адамс пишет здесь:

Although the size of redo entries is measured in bytes, LGWR writes the redo to the log files on disk in blocks. The size of redo log blocks is fixed in the Oracle source code and is operating system specific.

Перевод: Хотя размер redo измеряется в байтах, LGWR пишет red в лог файлы на дисках в блоках. Размер redo блоков зашит в код ядра Oracle и зависит от операционной системы.

То есть размер redo блоков невозможно изменить параметром инициализации как размер блоков данных db_block_size.

Ниже, он приводит размеры redo блоков в разных ОС:

Log Block Size    Operating Systems
512 bytes         Solaris, Windows, UnixWare
1024 bytes        HP-UX, Tru64 Unix
2048 bytes        SCO Unix, Reliant Unix
4096 bytes        MVS, MPE/ix

А так же, фактический размер redo блоков можно узнать следующим способом:

SQL> select max(lebsz) from sys.x$kccle;

MAX(LEBSZ)
----------
       512

Ожидания log file sync

Сессия, ожидает события log file sync, в то время как LGWR сбрасывает redo-информации из redo log buffer в redo log файлы.

Подробней: скажем какая-то сессия апдейтит какую-то таблицу. То есть выполняя апдейт, она генерит redo-информацию и записывает их в redo log buffer. В тот самый момент, когда сессия пишет redo-информацию в redo log buffer, LGWR сидит и ждет. Как только сессия коммитит транзакцию, LGWRу нужно сбросить redo-информацию из redo log buffer в redo log файлы и выдать сессии подверждение, что транзакция закоммичена. И пока LGWR сбрасывает redo-информацию из redo log buffer в redo log файлы, сессия ожидает события log file sync.

Мой коллега говорит, что это ожидание возникает только при commit'е сессии. Том Кайт тоже здесь пишет, что это ожидание возникает только при коммите:

log file sync - это клиентское ожидание события. Именно этого события ваши клиенты ждут, когда говорят "commit". Это ожидание, пока процесс LGWR фактически запишет их данные повторного выполнения на диск и фиксация транзакции будет завершена. Можно "настроить" этот процесс, ускорив работу процесса lgwr (отказавшись от использования raid 5, например) и фиксируя транзакции реже, генерируя меньше данных повторного выполнения (множественные изменения генерируют меньше данных повторного выполнения, чем построчные)

А как же сброс redo-информации из redo log buffer в redo-файлы по истечению 3 секунд, при заполнении redo log buffer'а на 1/3 и тд?

Если кто-то знает точный ответ на этот вопрос, напишите здесь.

"buffer busy waits" и "read by other session"

В Oracle 10g появились ожидания read by other session, которые являются частным и "отколовшимся" случаем ожиданий buffer busy waits. Вот что пишут в документации Oracle о них:

This event ['read by other session'] occurs when a session requests a buffer that is currently being read into the buffer cache by another session. Prior to release 10.1, waits for this event ['read by other session'] were grouped with the other reasons for waiting for buffers under the 'buffer busy wait' event.

Наталья Гусева, одна из суперских ДБА, которых я знаю, подсказала, что read by other session - это тот же buffer busy waits с reason code = 130.

Reason code = 130: Block is being read by another session, and no other suitable block image was found, so we wait until the read is completed. This may also occur after a buffer cache assumed deadlock. The kernel can't get a buffer in a certain amount of time and assumes a deadlock. Therefore it will read the CR version of the block.

Полный список и описание reason code можно почитать здесь, правда там говорится применительно версии 9i.

Ожидания read by other session возникают, когда какая-то сессия пытается прочитать блок из диска в буферный кеш, в тот момент когда другая сессия уже читает ее из диска в буферный кеш.

В моей практике, причины таких внезапных ожиданий в продуктивных базах были - неэффективные планы выполнений, когда планы "сбиваются" по каким-то причинам.

В тестовых базах такие ожидания появлялись, когда кто-то забывал создать индексы после переноса схемы.

Новый шаблон в новом году

Сегодня обновила шаблон блога на новый, захотелось сделать очередное "что-то новое" в новом году.

Новый шаблон очень необычный, по крайней мере для блога по Ораклу, но мне нравится.

Я его скачала на этом сайте - они раздают бесплатные шаблоны для блогов Blogspot.com, видимо, зарабатывают на рекламе.