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





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

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


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



 

DeepEdit!

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

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

Не бывает «неважных» событий


Авторы большинства публикаций тщательно различают события про­стоя и события « непростоя». При этом такие авторы обычно описыва­ют события «непростоя» как важные, а события простоя - как не важ­ные. Но я лично призываю вас применять лишь одну классификацию для событий ожидания 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 минуты) времени отклика.
 



jAntivirus