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





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

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


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



 

DeepEdit!

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

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

Эволюция модели времени отклика

волюция модели времени отклика


В 1980-х годах, когда была изобретена большая часть «методов на­стройки», функция трассировки SQL в Oracle еще не поддерживала выдачу информации о продолжительности событий ожидания - строк WAIT - в файл трассировки. Доступ имелся только к таким данным, как c, e и tim. Конечно, если основное время отклика было потрачено на по­требление времени процессора, то данные c и e могут предоставить практически всю необходимую информацию о производительности на­ших вызовов базы данных. Однако если какая-то часть времени откли­ка вызова базы данных не связана с потреблением времени процессо­ра, то анализ сильно усложнялся.
Рассмотрим статистику для вызова выборки, полученную от приложе­ния, работающего с версией Oracle 8.1.7.2:
FETCH #1:c=80741,e=151841,p=9628,cr=34304348,cu=10,mis=0, r=0,dep=0, og=4,tim=87762034
Фактическая продолжительность данного вызова составила 1518,41 с, и только 807,41 из них было потрачено на процессоре. На что же пошли остальные 711,00 секунд времени отклика? Возникала ли конкуренция блокировок? Событие ожидания блокировки? Длинные дисковые оче­реди? Избыточная подкачка страниц? Просто посмотрев на строку FETCH, на эти вопросы ответить невозможно. В статистике слишком ма­ло информации для определения того, на что были потрачены неуч­тенные 711 секунд продолжительности вызова. Конечно, большое зна­чение p указывает на то, что некоторая часть неучтенного времени могла быть потрачена на системные вызовы чтения, но дело в том, что существует приблизительно 200 различных событий ожидания, кото­рые Oracle мог бы выполнять в течение этих 711 секунд. Имея перед собой только приведенные сведения для выборки, мы не можем уз­нать, каким образом были потрачены 711 секунд.
В 1992 г., выпустив версию ядра 7.0.12, корпорация Oracle элегантно решила эту проблему. Новый механизм, предложенный Oracle, заклю­чался в снабжении измерительными средствами различных выпол­няемых ядром событий из числа тех, которые вносят вклад в фактиче­скую продолжительность, но не потребляют процессорного времени. Так называемые «данные ожидания» имели исключительную цен­ность. Они помогли заполнить временной провал между значениями e и c. Аньо Колк (Anjo Kolk) и Шари Ямагучи (Shari Yamaguchi) были первыми, кто описал использование «данных ожидания» в документе, ставшем поворотной вехой в истории, - «YAPP Method» (Метод YAPP) [Kolk and Yamaguchi (1999)].
Вернемся к предыдущему примеру, в котором было 711 секунд неуч­тенного времени. После того как ядро Oracle стало формировать стати­стику WAIT, в файл трассировки добавилось еще 9748 строк данных пе­ред информацией о вызове выборки. Выполнив программу Perl, при­веденную в примере 5.7, для 9749 строк данных трассировки, мы по­лучим следующий профиль ресурсов:
$ prof-cid waits.l.trc

Duration
Pct
Oracle kernel event
807.41s
53.2%
total CPU
426.26s
28.1%
direct path write
197.29s
13.0%
db file sequential read
76.23s
5.0%
unaccounted-for
8.28s
0.5%
latch free
2.87s
0.2%
db file scattered read
0.05s
0.0%
file open
0.02s
0.0%
buffer busy waits
0.00s
0.0%
SQL*Net message to client
1518.41s
100.0°%
Total response time
Теперь все понятно. Более 53% времени отклика для выборки было потрачено на работу процессора в пользовательском режиме. Более 28% было потрачено на запись на диск (что удивительно!). Еще 13% ушло на чтение с диска и приблизительно 6% времени отклика было потрачено на другие события ожидания.
Пример 5.7. Программа на Perl, формирующая профиль ресурсов по данным трассировки SQL для отдельного простого вызова базы данных Oracle (при отсутствии рекурсивных вызовов базы данных)
Обратите внимание на строку «unaccounted-for» (неучтенное) в профи­ле ресурсов. Посмотрим, как она была получена. Общая продолжи­тельность (по существу, время отклика) вызова выборки - это просто значение e для выборки. В исходных трассировочных данных это вре­мя учитывается двумя способами:
Составляющая полного времени занятости процессора во времени отклика вызова выборки записывается в статистику c в самой стро­ке FETCH.
Составляющие времени системных вызовов во времени отклика вы­зова выборки записываются в статистики ela во все строки WAIT, от­носящиеся к выборке.
Так что «неучтенное» время оказывается равным значению А (дельта), вычисляемому по формуле:
Интересна эволюция учета времени отклика со времен версии Oracle 6. В версии 6 в файле трассировки отображалось время отклика для вы­зовов базы данных (e) и время занятости процессора (c), но это были единственные данные о времени отклика, которые выводило ядро Oracle. Первая модель времени отклика Oracle была чрезвычайно про­стой и формулировалась так: «время отклика равно времени использо­вания процессора плюс еще что-то несущественное» или же так:
Эта модель эффективна, когда величина А мала, но не заслуживает до­верия при диагностике многих проблем со временем отклика, возни­кающих при больших значениях А. Во времена версии 6 большинство аналитиков были обучены считать, что большие значения А соответст­вуют времени, потраченному на вызовы чтения операционной систе­мы. Это предположение часто оказывается неверным (как, например, в случае с только что рассмотренным профилем ресурсов), но все же оно помогло аналитикам решить многие проблемы производительно­сти приложений. Причина успеха модели (несмотря на ее упрощен­ность) в том, что огромное количество проблем приложений Oracle связано с вызовами выборки, которые избыточно обращаются к кэшу буферов базы данных. Этим случаям соответствуют маленькие значе­ния А, и модель + А работает отлично.
Разработчики ядра Oracle одними из первых столкнулись с неадекват­ностью модели. Диапазон потенциально возможных причин для больших значений А так велик, что некоторые важные и сложные пробле­мы времени отклика просто невозможно решить без дополнительных оперативных данных. Представленные корпорацией Oracle в 1992 г. с выходом версии 7.0.12 данные расширенной трассировки SQL ста­ли превосходным решением задачи. Расширенные трассировочные данные включают в себя строки WAIT, рассказывающие о том, сколько времени ядро Oracle провело за «ожиданием» исполнения ключевых событий. Новая, значительно усовершенствованная модель времени отклика, ставшая возможной благодаря новой функциональности рас­ширенной трассировки SQL из версии Oracle 7.0.12, - это та модель, с которой мы работаем и по сей день:
С этого момента расширенная трассировка SQL смогла предоставить такие мощные диагностические возможности, о которых большинство аналитиков и не мечтало. Из тех немногих аналитиков, которые хотя бы осознают наличие интервала А, некоторые считают, что его существование объясняется недостатками расширенной трассировки, делаю­щими данные недостоверными. На самом же деле, как вы увидите да­лее, в значении А скрывается весьма полезная информация. Существу­ет несколько причин, вносящих свой вклад в ненулевое значение А,-об этом мы поговорим в главе 7. Понимание этих причин поможет вам в полной мере использовать всю диагностическую мощь предоставляе­мых Oracle данных расширенной трассировки SQL.

 



jAntivirus