DeepEdit!

Если прикладная система имеет высокую интенсивность операций DML
(например, когда выполняется много обновлений и        интенсивная де-

ятельность сегментов отката будет влиять на значение коэффициентов попада­ния в кэш. Отметьте, что в случае операций вставки, предьщущая информация ITL (на момент начала операции DML) и информация, требующаяся для удале­ния строки, хранятся в сегменте отката. Поэтому с технической точки зрения для операции вставки нет образа до обновления. Но если необходимо откатить операцию вставки, Oracle удалит вставленные строки из блока данных.

Для выполнения операций записи в сегменты отката требуется использовать блоки из буферного кэша базы данных, поскольку перед тем, как начать манипу­ляции с блоками сегмента отката, их нужно сначала считать в память. В настоя­щее время поддержка прямой записи в сегменты отката на диске отсутствует. Нельзя ли нам предложить запрос на усовершенствование и имя для нового па­раметра инициализации Oracle - UNDO_DIRbXT_WR1TES. He волнуйтесь, мы просто шутим!

Полезно знать, что блоки сегмента отката используют некоторые из буферов в буферном кэше, применяемые в противном случае для блоков реальных дан­ных или индексов. Необходимо учитывать это при определении размера буфер­ного кэша базы данных, а также при вычислении коэффициентов попадания в кэш (надеемся, вы еще не забыли, что это такое). Запросы, при выполнении ко­торых приходится строить согласованные по чтению представления данных, будут выполняться медленнее, потому что для их работы необходим доступ как к блокам данных, так и к блокам сегментов отката, чтобы заново построить образ

данных блоков, соответствующий значению SCN, имевшему место в момент

старта запроса.

Как мы только что говорили, каждый сегмент отката содержит в своем заго­ловке таблицу транзакций. Размер заголовка равен одному блоку. В нем содер­жится информация обо всех транзакциях, активных в данный момент в сегменте отката, к нему часто происходит доступ и его часто модифицируют. Поэтому блок заголовка сегмента отката будет сохраняться в буферном кэше ба­зы данных в течение длительного времени. Частый доступ к этому блоку заго­ловка внесет свой вклад в повышение коэффициента попадания в кэш буфера базы данных, хотя он и не связан с блоками данных таблиц или индексов. Это может привести (и приводит) к обесцениванию коэффициента попадания в бу­ферный кэш базы данных, но как об этом неоднократно упоминалось ранее, вы­сокое значение коэффициента ни в коем случае не должно означать, что наша база данных работает хорошо. В то же время, если имеется несколько процес­сов, обновляющих данные, количество запросов к блоку заголовка сегмента от­ката увеличивается, что может вызвать некоторые проблемы с конкуренцией. Представьте себе, что это не что иное, как несколько детей, дерущихся за одну игрушку!

Как же узнать, что в нашей базе данных имеет место конкуренция за сегмент отката? Давайте пустим в дело то, о чем мы говорили на протяжении всей книги. Начнем с динамического представления производительности V$SYSTEM_

EVENT. Поскольку блоки сегмента отката происходят из буферного кэша базы

данных, мы можем искать в этом представлении любые ожидания типа 

buffer busy waits. 

В число этих ожиданий следует, наравне с ожиданиями других блоков данных, включить ожидания блоков сегмента отката. Для иллюстрации сказан­ного используем следующий пример:

SQL> select Event, Total_Waits, Time_Waited

2        from V$SYSTEM_EVENT

3        where Event = 'buffer busy waits';

EVENT        TOTAL.WAITS  TIME_WAITEO

buffer busy waits        106021        46654

SQL>

Помните, что значения в представлении        являются куму-

лятивными (накопительными) с момента последнего запуска экземпляра. Вы­полните несколько раз запрос к V$ SYSTEM EVENT для получения значений 

baseline и delta 

для всей системы. Затем можно погрузиться в V$SESSION_EVENT и несколько раз выполнить предыдущий запрос для получения значений 

baseline 

и 

delta 

для сеанса. Вооружившись этой информацией, задайте запрос к V$SESSION_WAIT с целью найти событие (я) 

buffer busy waits 

для активных сеан­сов базы данных. Запишите значения Р1 (номер файла) и Р2 (номер блока), для которых произошло событие 

buffer busy waits 

(эти номера могут быстро менять­ся, но по крайней мере становится ясно, какой файл является источником узких мест). Используйте номер файла для соединения с представлением DBA_DATA_FILES, а номер блока для соединения с представлением DBA_EXTENTS или UET$, чтобы определить имя сегмента, ставшего источни­ком конкуренции. Теперь проверьте представление V$WAITSTAT и выясните,

нет ли ожидания блоков отката (или отмены):

О  SQL> select

2        from VSWAITSTAT

3        where Class in ('undo header',  'undo block');

TIME

CLASS        COUNT

1922 1121

undo header        43931

undo block        34743

2 rows selected. S0L>

И снова нужно несколько раз выполнить этот запрос для определения свя­занных с блоком отмены значений 

baseline 

и 

delta. 

Если для столбцов COUNT и TIME 

delta 

имеет ненулевое значение, это означает некоторую конкуренцию как за блок заголовка сегмента отката, так и за сами блоки сегмента отката. Помни­те, что эти значения являются накопительными с момента последнего запуска экземпляра.

Теперь, когда мы располагаем нужной информацией, как нам подкорректи­ровать конкуренцию? Скажем уклончиво: как когда. Можно добавить еще сег­менты отката или попытаться выяснить, как приложение их использует. Добавление дополнительных сегментов отката - быстрый и простой ответ, но является ли он окончательным? Есть много ситуаций, когда это не так.