Ценность фиксированных представлений Oracle неоспорима. Вскоре мы рассмотрим несколько примеров удачного использования запросов к представлениям V$. Например, каждой строке данных, выводимой ядром Oracle в файл трассировки, могут соответствовать несколько тысяч операций, о которых вы никогда не узнаете, если только не об­ратитесь к данным V$. Однако у фиксированных представлений Oracle есть и недостатки, о которых, возможно, не подозревают многие ана­литики по производительности. Ниже описаны те из них, с которыми мы столкнулись, попытавшись воспользоваться фиксированными представлениями в качестве основного источника данных при диагно­стике проблем производительности.

Избыток источников данных

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

Недостаток подробностей

Некоторые типы детальных данных, с большим трудом получаемые из документированных фиксированных представлений Oracle, легко извлекаются из файлов расширенной трассировки SQL. Например, по данным фиксированных представлений Oracle очень сложно:

Оценить тенденции продолжительности отдельных операций ядра Oracle

Сопоставить отдельные вызовы ввода/вывода соответствующим устройствам

Сопоставить потребление ресурсов отдельным вызовам БД

Выявить рекурсивные отношения между вызовами БД

Подавляющее большинство фиксированных представлений Oracle пре­доставляет только агрегированную статистику в рамках сеанса (напри­мер, V$SESSTAT) либо экземпляра (например, V$SYSSTAT). Скрывая под­робности, агрегированная статистика неоправданно усложняет анализ.

Замечательным исключением являются X$TRACE и V$SESSION_WAIT, пре­доставляющие данные по ходу выполнения. Однако использование представления X$TRACE, по крайней мере, в Oracle9i Release 2, представ­ляется нецелесообразным, т. к. это представление недокументировано, ненадежно и не поддерживается. Представление V$SESSION_WAIT, ко­нечно же, поддерживается, но для того чтобы получить с его помощью данные того же уровня детализации, как и из файла расширенной трассировки Oracle7, пришлось бы опрашивать его с частотой более 100 раз в секунду. С помощью SQL сделать это невозможно (см. раздел «Эффект влияния измерителя при опросе»). А уровень детализации расширенной трассировки Oracle9i потребовал бы опрашивать V$SES-

SION_WAIT 1 000 000 раз в секунду. Эффект влияния измерителя при опросе

Опрос фиксированных представлений Oracle с помощью SQL создает исключительно сильный эффект влияния измерителя на систему. По­лучить подробную статистику выполнения в реальном времени просто невозможно. Пример 8.1 иллюстрирует данную проблему. На нашем восьмисотмегагерцевом сервере под Linux типичная скорость не превы­шает 50 выполнений в секунду для 50-строчного запроса к V$SESSION:

Приговор: SQL непригоден для опроса даже небольших представлений V$ со скоростью 100 раз в секунду.

sessions	50
polls	1000
elapsed	15.734
user-mode CPU	7.111
kernel-mode CPU	0.741
polls/sec	63.557

Сложность правильного выбора операций

В данных представлений V$, как правило, нет атрибута принадлежно­сти к сессии. Чтобы понять, к чему это приводит, представьте, что про­филь ресурсов показывает, что время отклика расходуется в основном на ожидание освобождения защелок. Представление V$LATCH указыва­ет на активное использование двух различных защелок в период вы­полнения исследуемой пользовательской операции. Какая из защелок отвечает за ее время отклика? Это может быть и одна, и вторая, и даже обе. Как узнать, отвечает ли за данную активность тот сеанс, за кото­рым вы наблюдаете, или какой-то другой сеанс, случайно совпавший с вашим по времени? Ответы на эти вопросы только на основе данных из V$ за выбранный промежуток времени требуют гораздо большего времени, чем получение ответа на этот же вопрос от данных расширен­ной трассировки SQL.

Схожие аргументы применимы и ко второму пути. Ядро Oracle сооб­щает о событии ожидания освобождения защелки только в том случае, когда запрос на получение защелки прошел спинфазу1, но был отверг­нут, вследствие чего процесс ядра совершает системный вызов, освобождающий процессор для другого, произвольно выбранного процесса. Если попытка получения защелки оказалась успешной, в файл трас­сировки ничего не попадает, даже если процессу ядра Oracle потребо­валось для этого множество спин-итераций [Millsap (2001c)].

Сочетание данных расширенной трассировки SQL и хорошего инстру­мента для работы с данными V$, такого как тестовый инструментарий Тома Кайта (описанного ниже в этой главе), предоставляет куда боль­ше возможностей, чем каждое из этих средств в отдельности.

Сложность выбора временной области

Еще одной причиной, побудившей меня прекратить большой проект hotsos.com по диагностике на основе фиксированных представлений, стала неизлечимая проблема с получением данных в заданной времен­ной области. В том случае, когда граница интервала наблюдения попа­дает в середину события, важно знать, какая часть события должна быть включена в этот интервал, а какая - отброшена. Например, если в момент времени t сделан запрос к V$SESSION_WAIT и обнаружено вы­полняющееся событие db file scattered read, то как определить, сколь ко времени прошло с начала его выполнения? Оказывается, это можно выяснить с точностью 0,01 секунды, только если вы в состоянии вы­полнять опрос со скоростью 100 и более раз в секунду.

Еще одна неприятность возникает, когда сеанс завершает соединение раньше, чем получены все необходимые данные фиксированных пред­ставлений в конце предполагаемого интервала наблюдения. Если не успеть опросить различные представления V$, содержащие информа­цию о сеансе, до того как соединение прервется, нужные вам данные будут потеряны навсегда. Опять-таки, опрос с высокой частотой спосо­бен помочь в решении данной проблемы, но для этого надо обращаться к разделяемой памяти Oracle средствами, отличными от SQL.

Чувствительность к переполнению и другие ошибки

Еще одна слабая сторона фиксированных представлений - их чувстви­тельность к ошибкам переполнения. Дело в том, что n-разрядная пере­менная счетчика может принимать только 2n-1 различных значений. Когда n-битное беззнаковое целое в ядре Oracle достигает значения 2n-1, при следующем приращении его значение обнуляется. Ошибки пере­полнения приводят к тому, что в определенный момент «накопленные» значения статистики оказываются меньше, чем некоторое время назад. Если разработчик ядра выбрал для переменной счетчика целое со зна­ком, то некоторые значения после определенного порога становятся от­рицательными. Восстановить данные после переполнения несложно, но это еще один момент, требующий внимания при анализе данных V$ и никогда - при анализе данных расширенной трассировки SQL.

Ситуация усугубляется наличием проблем со статистикой CPU used by this session, включая ошибки Oracle с номерами 2327249, 2707060, 1286684 и другие. Если нельзя доверять системным средствам измере­ния основных составляющих времени отклика оптимизируемой систе­мы, то и результат всей работы находится под вопросом.

Отсутствие данных о длительности вызовов БД

Посмотрите определения представлений V$ и, я уверен, вы нигде не найдете эквивалента статистики e. Не зная фактической продолжи­тельности вызова БД, невозможно даже обнаружить наличие неучтен­ного времени, которое должно быть сопоставлено данному вызову. Ра­зумеется, если невозможно судить о наличии такого неучтенного вре­мени, то невозможно его и измерить. Как рассказывается в главах 6, 9 и 12, измерение неучтенного времени пользовательской операции -ключ к обнаружению, например, свопинга, по полученным от Oracle данным, независимым от операционной системы.

Думаю, вы согласитесь со мной в том, что отсутствие в представлениях V$ данных о продолжительности вызовов БД приводит к курьезным последствиям. Некоторые аналитики рассматривают «проблему поте­рянного времени» в файлах трассировки как доказательство того, что данные представлений V$ для анализа производительности имеют при­оритетное значение. Но не забывайте, что данные фиксированных представлений и расширенной трассировки SQL получены с помощью одних и тех же системных вызовов (как рассказывалось в главе 7). Следовательно, для данных из V$ характерны те же самые проблемы «потерь времени», которым, якобы, подвержены файлы расширенной трассировки. Утверждение о том, что «потерянное время» свидетель­ствует о большей достоверности данных из V$, по сравнению с данны­ми расширенной трассировки, столь же разумно, как и совет зажму­риться для большей безопасности, оказавшись наедине с голодным медведем.

Отсутствие согласованности чтения

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

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

В Oracle есть два пути для получения данных V$: можно самостоятель­но считывать их из разделяемой памяти, а можно с помощью SQL об­ращаться за ними к предоставленным Oracle фиксированным пред­ставлениям. Способ с самостоятельным обращением к разделяемой па­мяти имеет значительное преимущество, позволяя избежать огромных дополнительных расходов на обработку SQL, что особенно актуально для сервера Oracle, и без того отягощенного проблемами с производи­тельностью. Однако ни один из способов не обеспечивает согласованно­го чтения данных о производительности. Когда мы обращаемся к пред­ставлению V$, результат не соответствует состоянию системы на опре­деленный момент времени. Полученные данные «размазаны» по всему интервалу времени выполнения запроса.

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

гласованного чтения, подобный тому, который ядро Oracle задейству­ет для реальных таблиц. В противном случае полученные запросом данные могут показать состояние системы, никогда не имевшее места в действительности (рис. 8.1). Чтение сегмента памяти началось в мо­мент времени t0 и завершилось в момент t3. Темные ячейки показыва­ет фрагменты памяти, содержимое которых изменилось за указанный период. Светло-серые ячейки показывают фрагменты, копируемые в выходной поток в указанный момент времени. Вследствие того, что операция чтения большой области памяти не обладает свойством ато­марности, выходной поток может представлять такое состояние памя­ти, которое никогда не существовало на самом деле.

Важность проблемы согласованного чтения возрастает при увеличе­нии длительности запроса. Предположим, что при выборке данных о 2000 сеансов Oracle простым запросом к V$SESSION выполняется после­довательность шагов, показанная в табл. 8.1. Результат запроса пред­ставляет собой не моментальную копию, а набор строк, каждая из ко­торых соответствует слегка отличающемуся состоянию системы, имев­шему место на протяжении 40 секунд времени выполнения запроса.

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

V$BH

V$DB_OBJECT_CACHE

V$FILESTAT V$LATCH

V$LIBRARYCACHE

V$LOCK

V$OPEN_CURSOR

V$PARAMETER

V$PROCESS

V$ROLLSTAT

V$ROWCACHE

V$SESSION

V$SESSION_EVENT

V$SESSION_WAIT

V$SESSTAT

V$SQL

V$SQLTEXT

V$TIMER

V$TRANSACTION

V$WAITSTAT

Хотелось бы верить, что все полученные в одном запросе данные дейст­вительно соответствуют единому моменту времени. Однако это не так. Для фиксированных представлений с небольшим количеством сравни­тельно редко изменяющихся данных данная проблема не очень критич­на. Но для представлений с тысячами строк простые команды SELECT могут дать странные результаты. Еще хуже дело обстоит, если по тако­му длинному списку фиксированных представлений строится момен­тальная копия. Если бы это были настоящие таблицы Oracle, можно было бы, наверное, применить такой способ объединения нескольких запросов в атомарное событие:

Но для фиксированных представлений V$ такой метод неприменим, т. к. это не настоящие таблицы. Каким бы способом вы ни извлекали информацию для своей моментальной копии, полученные данные все­гда будут размазаны по интервалу выполнения всего набора запросов. Время получения состояния из первой строки V$BH будет отличаться от времени обращения к последней строке V$WAITSTAT на величину дли­тельности выполнения всех этих команд. В приведенном примере эта длительность наверняка превысит секунду. Ни одна программа не может просканировать гигабайты (и даже сотни мегабайт) в одной ато­марной операции.

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