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





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

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


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



 

DeepEdit!

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

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

Как выявить конкурирующую нагрузку


Идентификация программ, конкурирующих с пользовательской опе­рацией, чем-то похожа на обычную настройку производительности, во всяком случае, для этого применяются те же инструменты.

Существует множество инструментов для детального анализа различных ресурсов. Для начала отлично подойдут фиксиро­ванные представления Oracle, описанные в главе 8.
Детальное изучение подробностей функционирования вызывающего задержки устройства может напомнить старый способ настройки мето­дом проб и ошибок (метод C из главы 1), однако здесь есть важное отли­чие. Оно связано с уникальной характеристикой метода R - детермини­рованным выбором цели. Не необходимости просеивать бесчисленное множество метрик, гадая, какая из них может оказать заметное влия­ние на производительность, а какая - нет. Точно известно, какой имен­но ресурс требует улучшения. И известно это из профиля ресурсов.
Самая сложная часть задачи поиска конкурентов пользовательской опе­рации связана с проблемой сбора диагностических данных в правильной области. Это как раз тот случай, когда очень кстати подробная история всех событий в системе за время существования исследуемой проблемы производительности, аналогичная имеющейся в X$TRACE. Без такой по­дробной истории диагностических данных могут возникнуть трудно­сти с определением программ, конкурирующих с пользовательской операцией, даже если с момента ее завершения прошло всего несколь­ко минут. Есть несколько путей для достижения успеха, в частности:
Журналы выполнения пакетных заданий
Практически всегда наибольшую конкурирующую нагрузку в сис­теме создают пакетные задания. В большинстве хороших программ управления пакетными заданиями предусмотрена возможность за­писи в журнал времени работы каждого из них. Отталкиваясь от этой информации, часто удается быстро определить, какие из про­грамм конкурируют за определенный ресурс. Собрав при следующем плановом запуске этих программ необходимые диагностиче­ские данные, можно превратить предположения в точное знание.
Аудит уровня соединения
Экземпляр Oracle может быть легко сконфигурирован так, чтобы записывать в журнал статистику использования ресурсов сеансом. Эта статистика поможет определить, какие сеансы больше всего за­гружают систему в определенные периоды времени. Обладая такой информацией, можно, поговорив с пользователями, сделать доста­точно достоверные предположения о том, какие программы созда­ют конкуренцию за данное устройство. Как и в предыдущем случае, переход от предположений к точному знанию требует сбора диагно­стики в правильно определенной области для подозреваемых про­грамм при следующем их запуске. Для начала изучите сведения о представлении DBA_AUDIT_SESSION в документации Oracle.
Учет использования ресурсов в операционной системе
Некоторые операционные системы предоставляют возможность сбора и хранения статистики производительности для отдельных программ. Это может оказаться очень важным, т. к. конкуренция за некоторый ресурс не обязательно может быть вызвана другим процессом Oracle.
Собственные измерительные средства
Для аналитика по производительности нет ничего лучше, чем код приложения, способный сам рассказать, чем он занят в каждый мо­мент времени. Если можно встроить измерительные средства в мед­ленно работающую программу (допустим, вы сами ее написали), сделайте это. Как это сделать, подробно описано в главе 7.
Отыскав программу, конкурирующую с пользовательской операцией за дефицитный ресурс, обратитесь к рекомендациям из предыдущего раздела «Исключение лишних вызовов». Теперь работа сводится к уже рассмотренным действиям, позволяющим выяснить, насколько в действительности оправданны требования к высокой загрузке ресурса.
Модернизация оборудования
Модернизация оборудования - последняя из возможностей, которую следует рассматривать при повышении производительности. Послед­нее место она занимает по вполне очевидным причинам:
• Дорогостоящая модернизация оборудования редко способна дать тот же эффект, что и недорогие мероприятия по исключению беспо­лезной нагрузки.
• Плохо спланированная модернизация оборудования может в дейст­вительности ухудшить производительность пользовательской опе­рации, которую вы пытаетесь ускорить.
Любая модернизация оборудования связана с риском. С первого взгля­да понятно, что отдача от инвестиций в более производительное обору­дование может оказаться значительно ниже ожидаемой. Многие руко­водители считают модернизацию беспроигрышным вложением, счи­тая, что «Разве может быть слишком много процессоров (памяти, дис­ков и т. д.)?». Расхожее мнение гласит, что даже если модернизация напрямую не решит имеющуюся проблему производительности, то как она сможет навредить? Ведь дополнительные мощности так или иначе будут использованы, разве нет? Увы, не всегда. Далеко не все осознают риск, связанный с принятием такого решения. Одну из возможных си­туаций я уже приводил в разделе «Почему правильный выбор так ва­жен». Случай, описанный в разделе «Пример 1: Недостатки общесистемных данных» главы 12 - еще одна иллюстрация этой проблемы:
Модернизация оборудования направлена на повышение производительно­сти некоторой части системы, но вопрос в том, поможет ли эта модерниза­ция привести систему в соответствие с бизнес-целями ее владельца.
Первое формальное объяснение этого тезиса, противоречащего интуи­ции, я встретил в книге Нейла Гюнтера (Neil Gunther) «The Practical Performance Analyst» (Аналитик-практик производительности) [Gun­ther (1998) 117-122]. Когда я продемонстрировал пример Гюнтера участникам международной конференции Oracle, многие стали подходить к трибуне и рассказывать, что этот пример, наконец, помог им понять причину странных результатов, погубивших некоторые проекты. Я был польщен, но вместе с тем немного удивлен тем, что так много людей столкнулось с ухудшением производительности в результате модерни­зации оборудования. Более близкое знакомство с законом Амдала по­могло мне понять, что любая модернизация может привести к сниже­нию производительности какой-либо пользовательской операции вслед­ствие возникновения конкуренции за ресурс, который не был модерни­зирован. Вопрос только в том, заметит ли кто-нибудь эти ухудшения.
Если модернизация оборудования не привела к росту производитель­ности, то худший сценарий для проекта трудно себе вообразить. Вот как это происходит. Компания достаточно долго терпит недостаточ­ную производительность, и, в конце концов, коллективные мучения достигают некоторого порога, за которым следует выделение денег на модернизацию. Размер ожиданий прямо пропорционален выделяе­мой сумме. В пятницу, перед Большой Модернизацией, вся компания нервничает в ожидании понедельника, ведь «Мы потратили на реше­ние этой проблемы такие деньги, что все должно просто летать». И вот, в понедельник, все не только не летает, но и становится сильно хуже. Во вторник руководство обсуждает, стоит ли сотруднику, пред­ложившему эту модернизацию, приходить на работу в среду.
Сотрудники, ответственные за принятие решений о модернизации, сталкиваются с интересными противоречиями:
Модернизация часто рассматривается как недорогая альтернатива дорогим аналитикам, хотя потенциальный выигрыш от нее не срав­ним с возможным выигрышем от уменьшения нагрузки.
Модернизация часто считается совершенно безопасной, хотя она связана со значительными рисками. Эти риски требуют проведения серьезного, тщательного и, возможно, дорогого предварительного анализа.
Успешная модернизация обычно не оправдывает возлагавшихся на нее надежд. Если модернизация не удалась, опасности подвергается карь­ера модернизатора. Провалы часто бывают столь оглушительными, что восстановить доверие спонсоров уже не удается.
Нужно ли вообще модернизировать оборудование? Разумеется, во мно­гих случая это необходимо. Но я заклинаю вас не рассматривать модер­низацию как первое средство от проблем производительности. Вам дей­ствительно не хватает мощности системы? Вполне возможно, что она загружена бесполезной работой. Так что, пожалуйста, исключите лиш­ние обращения к ресурсам, прежде чем модернизировать их. А прежде чем приступать к модернизации, обязательно обдумайте следующие вопросы:
Не начинайте модернизацию до тех пор, пока не убедитесь, что модернизи­руемый ресурс (а) улучшит выполнение важных пользовательских опера­ций и (б) повредит только второстепенным операциям.
И, разумеется, не упускайте из виду тот факт, что второстепенная пользовательская операция завтра может стать очень важной, если ее выполнение замедлится.

 



jAntivirus