Документация Oracle на русском языке





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

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

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

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Изъяны данных фиксированных представлений

зъяны данных фиксированных представлений

Ценность фиксированных представлений Oracle неоспорима. Вскоре мы рассмотрим несколько примеров удачного использования запросов к представлениям V$. Например, каждой строке данных, выводимой ядром Oracle в файл трассировки, могут соответствовать несколько тысяч операций, о которых вы никогда не узнаете, если только не об­ратитесь к данным V$. Однако у фиксированных представлений Oracle есть и недостатки, о которых, возможно, не подозревают многие ана­литики по производительности. Ниже описаны те из них, с которыми мы столкнулись, попытавшись воспользоваться фиксированными представлениями в качестве основного источника данных при диагно­стике проблем производительности.
Избыток источников данных
По данным фиксированных представлений можно построить прибли­зительный профиль ресурсов заданного сеанса. Как это сделать, рас­сказывается в данной главе. Однако профиль ресурсов лишь указывает на то, какие данные действительно будут нужны: не изучив его, невоз­можно определить направление дальнейшего поиска. Следовательно, единственный способ обрести уверенность в том, что собрана вся ин­формация, которая может понадобиться, состоит в том, чтобы учесть все потенциально полезные данные для выбранных диапазонов време­ни и операций. Сделать это с помощью фиксированных представлений практически невозможно.
Недостаток подробностей
Некоторые типы детальных данных, с большим трудом получаемые из документированных фиксированных представлений Oracle, легко извлекаются из файлов расширенной трассировки SQL. Например, по данным фиксированных представлений Oracle очень сложно:
Оценить тенденции продолжительности отдельных операций ядра Oracle
Сопоставить отдельные вызовы ввода/вывода соответствующим устройствам
Сопоставить потребление ресурсов отдельным вызовам БД
Выявить рекурсивные отношения между вызовами БД
Подавляющее большинство фиксированных представлений Oracle пре­доставляет только агрегированную статистику в рамках сеанса (напри­мер, V$SESSTAT) либо экземпляра (например, V$SYSSTAT). Скрывая под­робности, агрегированная статистика неоправданно усложняет анализ.
Замечательным исключением являются X$TRACE и V$SESSION_WAIT, пре­доставляющие данные по ходу выполнения. Однако использование представления X$TRACE, по крайней мере, в Oracle9Release 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 раз в секунду.
Пример 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 по диагностике на основе фиксированных представлений, стала неизлечимая проблема с получением данных в заданной времен­ной области. В том случае, когда граница интервала наблюдения попа­дает в середину события, важно знать, какая часть события должна быть включена в этот интервал, а какая - отброшена. Например, если в момент времени сделан запрос к 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 на величину дли­тельности выполнения всех этих команд. В приведенном примере эта длительность наверняка превысит секунду. Ни одна программа не может просканировать гигабайты (и даже сотни мегабайт) в одной ато­марной операции.
Очень трудно согласовать по времени данные из нескольких источни­ков, даже если они входят в одну моментальную копию. А если собран­ные данные дополняются статистикой операционной системы, пробле­ма еще более усложняется.

 



jAntivirus