зъяны данных фиксированных представлений
Ценность фиксированных представлений 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-
Опрос фиксированных представлений Oracle с помощью SQL создает исключительно сильный эффект влияния измерителя на систему. Получить подробную статистику выполнения в реальном времени просто невозможно. Пример 8.1 иллюстрирует данную проблему. На нашем восьмисотмегагерцевом сервере под Linux типичная скорость не превышает 50 выполнений в секунду для 50-строчного запроса к V$SESSION:
Приговор: SQL непригоден для опроса даже небольших представлений V$ со скоростью 100 раз в секунду.
Пример 8.1. Программа на Perl, демонстрирующая фундаментальное ограничение метода опроса с помощью SQL. Обратите внимание, что разбор выполняется однократно и применяется не построчная выборка, а выборка массивом
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$, результат не соответствует состоянию системы на определенный момент времени. Полученные данные «размазаны» по всему интервалу времени выполнения запроса.
Чтение большой порции данных из памяти не является атомарной операцией. Для создания образа сегмента памяти, обеспечивающего согласованное чтение, необходимо либо заблокировать этот сегмент на время выполнения запроса, либо применить более сложный механизм со-
Рис. 8.1. Проблема, вызванная несогласованностью чтения.: в выходном потоке может быть представлено состояние памяти, никогда в действительности не существовавшее
гласованного чтения, подобный тому, который ядро 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 на величину длительности выполнения всех этих команд. В приведенном примере эта длительность наверняка превысит секунду. Ни одна программа не может просканировать гигабайты (и даже сотни мегабайт) в одной атомарной операции.
Очень трудно согласовать по времени данные из нескольких источников, даже если они входят в одну моментальную копию. А если собранные данные дополняются статистикой операционной системы, проблема еще более усложняется.
< Предыдущая | Следующая > |
---|