Авторы большинства публикаций тщательно различают события простоя и события « непростоя». При этом такие авторы обычно описывают события «непростоя» как важные, а события простоя - как не важные. Но я лично призываю вас применять лишь одну классификацию для событий ожидания Oracle: различать их по признаку внутри/между, о котором мы говорили в главе 5. Осознание данного отличия необходимо для использования фундаментального отношения между статистиками файла трассировки: e 6 c + Eela, не допуская как двойного учета времени, так и его пропуска. Я призываю отказаться от других классификаций событий ожидания Oracle, потому что любое событие может внести важный вклад в общее время отклика.
Существует единственный законный критерий определения важности составляющей времени отклика:
Если составляющая вносит значительный вклад во время отклика корректно выбранной пользовательской операции, то она важна; в противном случае t. можно пренебречь.
Поэтому я не согласен с заявлениями о том, что какие-то события важны, а какие-то другие - нет. Любое событие может быть важным. Не имеет значения, что это за событие, и сколько авторов высказались в пользу того, что оно не важно. Если событие вносит значительный вклад во время отклика корректно выбранной пользовательской операции, то оно является важным для нас.
В каком случае события простоя могут оказаться важными? Если время, потраченное на их исполнение, вносит значительный вклад в формирование времени отклика. Практически в любом профиле ресурсов встречаются два события ожидания: SQL*Net message to client и SQL*Net message from client. Событие from client бесспорно относится к так называемым событиям простоя. Ядро Oracle использует события to client и from client для измерения производительности межпроцессного взаимодействия, которое реализуется через SQL*Net. В примере 11.1 показано, как эти события работают внутри ядра Oracle.
О простое
О событиях простоя упоминается в любой хорошей книге об интерфейсе ожидания Oracle. Авторы специально выделяют события простоя в связи с тем, что они представляют собой фрагмент кода ядра Oracle, в котором процесс ядра ожидает инструкции на выполнение некоторого действия. Средства системного мониторинга преднамеренно игнорируют статистики для событий простоя. Например, утилита Oracle Statspack включает в себя таблицу STATS$IDLE_EVENT, содержащую названия событий, которые администраторы баз данных обычно опускают в отчетах Statspack относительно V$SYSTEM_EVENT. К таким событиям относятся:
В разделе «Проблема „событий простоя"» главы 8 сказано, что ряд авторов выделяет различные события ожидания в разряд «простоя» для решения проблемы, вызванной некорректным сбором диагностических данных. Некорректный выбор диагностических данных приводит к тому, что аналитики не учитывают события простоя, тогда как они содержат жизненно важную информацию. Если же диагностические данные собраны корректно, то лучше уже не отвлекаться на размышления о том, является ли какое-то событие «событием простоя». Вместо того, чтобы заниматься классификацией событий по признаку «простой»/ «не простой», я разделяю события ожидания на происходящие внутри вызовов базы данных и между такими вызовами.
Неверной будет и попытка уравнять то, что другие авторы называют событиями простоя, моим событиям между вызовами. События между вызовами и события простоя - это не одно и то же. Например, событие
PX Deq Credit: need buffer выполняется внутри вызова базы данных. Другие события, также часто относимые к событиям простоя: SQL*Net
more data from client и SQL*Net more data from dblink, также исполняются в контексте вызовов базы данных, а не между ними.
События SQL*Net message to client обычно занимают всего несколько микросекунд. Но события SQL*Net message from client могут выполняться гораздо дольше, например:
Время раздумий пользователя
Если вы подключаетесь к серверу Oracle в 08:00 и до 10:00 не выполняете ни одного вызова базы данных, то Oracle запишет 7200 секунд
для SQL*Net message from client в V$SYSTEM_EVENT. TIME_WAITED в 10:00.
Время выполнения клиентской программы
Отчет Financial Statement Generator в Oracle Applications (пакетная программа, работающая как клиентский процесс Oracle) обычно выполняет несколько вызовов базы данных, а затем достаточно долгое время занимается обработкой полученных данных в клиентской программе на C. С точки зрения серверного процесса Oracle это время, потраченное клиентом, воспринимается просто как время, связанное с вызовом чтения, показанным в примере 11.1, поэтому оно записывается на счет SQL*Net message from client.
Ожидание между вызовами
Даже если приложение быстро выполняет два последовательных вызова базы данных, между ними часто имеет место событие SQL*Net message from client, вызывающее задержку в сотни микросекунд.
Необходимо обратить внимание на пару моментов. Во-первых, просто посмотрев на диагностические данные, мы не можем сказать, какое «время простоя базы данных» в действительности является временем отклика какой бы то ни было программы, а какое «время простоя базы данных» просто соответствует тому времени, которое пользователь провел, не глядя на монитор. Чтобы узнать это, необходимо наблюдать за пользователем. Во-вторых, несмотря на то, что ожидание между последовательными быстро следующими друг за другом вызовами БД составляет всего несколько микросекунд, в итоге все это время суммируется. Например, даже если средняя продолжительность события SQL*Net message from client составляет мизерные 500 микросекунд, 1 000 000 вызовов базы данных приведут к формированию 500-секундного (а это 8,3 минуты) времени отклика.
| < Предыдущая | Следующая > |
|---|
