Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Oracle University Official Study Notes (RUS) > База данных Oracle 10g Администрирование > База данных Oracle 10g Администрирование II

Ответ
 
Опции темы Опции просмотра
  #1  
Старый 10.10.2009, 11:51
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию 09 Автоматическое управление производительностью

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #2  
Старый 10.10.2009, 11:52
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Рассматриваемые вопросы

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #3  
Старый 10.10.2009, 12:09
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Проведение настройки



Проведение настройки

Работы по настройке затрагивают три аспекта: планирование производительности, настройку экземпляра и настройку кода SQL.

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


Примечание: дополнительные сведения о настройке производительности см. в документе Oracle Database Performance Timing Guide.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #4  
Старый 10.10.2009, 12:10
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Планирование производительности



Планирование производительности

При планировании производительности учитывается много аспектов. Так аппаратно-программная инфраструктура должна соответствовать вашим требованиям. Поэтому рассматриваются различные варианты инвестирования в системную архитектуру.

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

Также важна масштабируемость приложения. Она означает возможность обслуживания все большего числа пользователей, клиентов, сеансов или транзакций без существенного влияния на общую производительность системы. Очевидным препятствием для масштабирования является последовательное выполнение операций пользователей. Если все пользователи должны одновременно пройти по одной и той же ветви алгоритма обработки, тогда добавление новых пользователей, без сомнения, окажет неблагоприятное влияние на производительность. Плохо написанный код SQL также влияет на масштабируемость. Он приводит к тому, что многие пользователи вынуждены ждать завершения выполнения неэффективного кода; при этом каждый пользователь конкурирует с другим за большое количество ресурсов, которое им на самом деле не требуется.

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

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

Анализ производительности должен проводиться при развертывании новых приложений (или их версий). Иногда для массового продвижения продукта принимаются проектные решения, обеспечивающие совместимость с предыдущими версиями системы. Новую базу данных следует конфигурировать специально для использующих ее приложений на основе параметров производственной среды.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #5  
Старый 10.10.2009, 12:12
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Настройка экземпляра



Настройка экземпляра

Приступая к настройке, необходимо иметь определенные цели. Например, цель может быть поставлена следующим образом: обработка 500 транзакций о продажах в минуту. А может быть поставлена и так: сделай это так быстро, как это возможно, и в результате мы узнаем, что будет достаточно хорошо. Конечно, первая цель ясно и определенно формулирует поставленную задачу.

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

Дисковый ввод-вывод часто является узким местом базы данных. Поэтому он требует большого внимания в самом начале реализации любой базы данных.

Конфигурация операционной системы может также повлиять на производительность базы данных Oracle. Дополнительные сведения см. в документе Oracle Database Installation Guide для конкретной платформы.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #6  
Старый 10.10.2009, 12:12
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Методология настройки производительности



Методология настройки производительности

Oracle разработал методологию настройки, основываясь на многолетнем опыте. Основные шаги следующие:

Проверьте статистики ОС и общее состояние машины перед настройкой экземпляра, чтобы быть уверенным в том, что проблема в базе данных.
Проводите настройку сверху вниз. Начните с проекта, затем настраивайте приложение и потом экземпляр. Например, попытайтесь устранить полные просмотры таблиц, вызывающие конкуренцию ввода-вывода перед настройкой размещения табличных пространств на диске.
Настраивайте область с наибольшей потенциальной отдачей. Методология настройки, представленная в этом курсе, проста. Выявите наиболее узкое место и настраивайте его. Повторите этот шаг. Все различные инструменты настройки имеют возможности обнаружения команд SQL, ресурсной конкуренции, служб, выполняемых наибольшее время. База данных Oracle предоставляет временную модель и метрики для автоматизации процесса обнаружения узких мест.
Останавливайте настройку, когда цель достигнута. Этот шаг подразумевает, что цели настройки были вами определены.

Это общий подход к настройке экземпляра. При его использовании может потребовать несколько раз повторить указанные действия.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #7  
Старый 10.10.2009, 12:16
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Сбор статистик



Сбор статистик

Статистики оптимизатора используются сервером для выбора наиболее эффективного плана выполнения каждой команды SQL. В этих статистиках отражаются детальные сведения о базе данных и хранимых в ней объектах.

Системные статистики отражают необходимые оптимизатору показатели работы аппаратуры, например, производительность ввода-вывода и использование ЦП. При выборе плана выполнения оптимизатор оценивает ресурсы ввода-вывода и ЦП, требуемые каждому запросу. Системные статистики позволяют оптимизатору запросов более точно оценить стоимость операций ввода-вывода и использования ЦП и в результате выбрать лучший план выполнения. Системные статистики собираются с помощью процедуры DBMS_STATS . GATHER_SYSTEM_STATS. Когда сервер Oracle осуществляет сбор таких статистик, он анализирует системную активность в заданном периоде времени. Системные статистики не собираются автоматически. Корпорация Oracle настоятельно рекомендует использовать для этого пакет DBMS_STATS.

Рекомендуется разрешить серверу Oracle автоматически собирать статистики оптимизатора. Задание GATHER_STATS_JOB автоматически создается вместе с базой данных. Управляет этим заданием планировщик (Scheduler). Задание собирает данные обо всех объектах базы данных, статистики которых либо утеряны, либо устарели.

Если принято решение не использовать автоматический сбор статистик, тогда необходимо вручную собирать статистики для всех схем, включая системные схемы. Когда данные в

БД изменяются регулярно, также регулярно необходимо собирать статистики, чтобы быть уверенным в том, что они точно отражают характеристики объектов базы данных. Для ручного сбора статистик используется пакет DBMS STATS. Он также применяется для обновления, просмотра, экспорта, импорта и удаления статистик.

Кроме того, можно управлять сбором системных статистик и статистик оптимизатора с помощью параметров инициализации. Например:

Параметр OPTIMI ZER_DYNAMIC_SAMPLING контролирует уровень динамической выборки статистик, собираемой оптимизатором. Динамическая выборка может использоваться для оценки статистик таблиц и соответствующих индексов, если статистики недоступны или слишком устарели, чтобы им можно было доверять. Динамическая выборка также оценивает селективность предиката для единственной таблицы, когда собранные статистики не могут быть использованы или с большой вероятностью приводят к значительным ошибкам при оценке плана выполнения.

Параметр STATISTICS_LEVEL управляет сбором всех основных статистик и влияет на работу консультантов базы данных. В нем задается уровень сбора статистик, производимого в базе данных. Значения этого параметра - BASIC, TYPICAL или
ALL.

Параметр TIMED_STASTICS приводит к тому, что сервер Oracle не только подсчитывает события ожиданий (что он выполняет всегда), но и также собирает данные о времени ожиданий. Такие данные применяются для сравнения того, как меняется соотношение общего времени ожидания какого-либо события и общего времени обработки между моментами сбора статистик производительности.

Параметр TIMED_OS_STATISTICS задает интервал времени (в секундах), в течение которого Oracle собирает статистики операционной системы, когда запрос на выполнение команды поступает от клиента или когда завершается его выполнение.

Временные системные статистики автоматически собираются базой данных, когда параметр инициализации STATISTICS_LEVEL установлен в TYPICAL или ALL. Если значение параметра STATISTICS_LEVEL равно BASIC, тогда необходимо установить TIMED_STATISTICS в TRUE, чтобы включить сбор временных статистик. Отметим, что установка STATISTICS_LEVEL в BASIC отключает многие автоматические возможности и поэтому не рекомендуется.

При явном задании параметра TIMED_STATISTICS или TIMED_OS_STATISTICS в файле параметров инициализации или с помощью команд ALTER SYSTEM и ALTER SESSION, переопределяется значение, получаемое на основе параметра STATISTICS_LEVEL.

Можно выполнить запрос к представлению V$STATISTICS_LEVEL, чтобы выяснить, на какие параметры оказывает воздействие значение, установленное в параметре STATISTICAL_LEVEL.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 02.10.2015 в 01:52.
Ответить с цитированием
  #8  
Старый 10.10.2009, 12:18
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию События ожиданий в Oracle



События ожиданий в Oracle

С событиями ожиданий (wait events) связываются статистики, значения которых увеличиваются, когда какой-либо серверный процесс или поток (thread) вынужден ждать завершения события, чтобы продолжить обработку. Ожидания отражают различные симптомы проблем, которые могут влиять на производительность, например, они могут отражать конкуренцию за защелки, буферы, а также конкуренцию по вводу-выводу.

Следует помнить, что это только симптомы, но не реальные причины проблем. События ожиданий сгруппированы в классы: Administrative, Application, Cluster, Commit, Concurrency, Configuration, Idle, Network, Other, Scheduler, System I/O и User I/O.

В базе данных Oracle более 800 событий ожидания. В их число, например, входят следующие: free buffer wait, latch free, buffer busy waits, db file sequential read иdb file scattered read.

Чтобы просмотреть события ожиданий в ЕМ, перейдите на страницу Performance.

События ожиданий отражаются на графике в разделе Sessions: Waiting and Working, как это показано на слайде. Щелкнув на ссылке событий определенного класса, а затем, используя интерфейс Top Sessions, можно перейти к просмотру конкретных событий, связанных с сеансами. В приводимом примере наибольшие ожидания были связаны с операциями чтения файлов.

Перечень наиболее общих событий ожиданий Oracle см. в документе Oracle Database Reference 10g.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #9  
Старый 10.10.2009, 12:20
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Статистики системы



Статистики системы

Для эффективной диагностики проблем производительности необходимы статистики.

Oracle генерирует кумулятивные статистики многих типов, относящиеся к системе, сеансам и отдельным командам SQL. Oracle также собирает кумулятивные статистики по сегментам и сервисам. При анализе проблемы производительности обычно учитываются изменения соответствующих статистик (их дельта) в течение рассматриваемого периода времени.


Статистики событий ожиданий

Все возможные события ожиданий отражаются в представлении V$EVENT_NAME. Кумулятивные статистики для всех сеансов хранятся в представлении V$SYSTEM EVENT.
В нем отражаются итоговые данные об определенных ожиданиях, начиная с момента запуска экземпляра.
При поиске и устранении неисправности необходимо знать, ждал ли процесс какой-либо ресурс.


Основные системные статистики

Все основные системные статистики (systemwide statistics) отражаются в представлении V$STATNAME. В базе данных Oracle Database 10g их примерно 330.

Собранные сервером статистики можно просмотреть, используя представление V$SYSSTAT. Оно содержит кумулятивные итоговые данные, подсчитанные с момента запуска экземпляра.


Вывод основных системных статистик

Пример:



Основные системные статистики классифицируются на основе областей настройки и целей отладки. Статистики объединяются в следующие классы: общие данные о работе экземпляра, общие данные о работе журнального буфера, блокировки, работа кэша буферов базы данных и т.д.

Все события ожидания определенного класса можно также просмотреть, запросив представление V$SYSTEM WAIT CLASS. Пример (результат отформатирован):




Общие статистики SGA


Сервер отражает все подсчитанные статистики использования оперативной памяти в представлении V$SGASTAT. Его можно использовать для просмотра кумулятивных итогов использования компонентов SGA с начала запуска экземпляра. Пример:




В примере показана только часть выходных результатов.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #10  
Старый 10.10.2009, 12:23
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Вывод статистик, связанных с сеансом



Вывод статистик, связанных с сеансом

Информация о текущих сеансах пользователей может быть получена с помощью представления V$SESSION. Например V$SESSION позволяет выяснить, это сеанс пользователя или же сеанс, созданный серверным процессом БД (BACKGROUND).

Для того, чтобы выявить ресурсы или события, которые ждет активный сеанс, можно запросить либо представление V$SESSION, либо V$SESSION_WAIT.

Сервер Oracle показывает статистики пользовательских сеансов в представлении V$SESSTAT. Сведения о событиях ожидания сеанса отражаются в представлении
V$SESSION_EVENT.

Кумулятивные значения статистик в основном доступны через динамические представления производительности, например, V$SESSTAT и V$SYSSTAT. Следует отметить, что кумулятивные данные в динамических представлениях сбрасываются во время остановки экземпляра базы данных.

В представлении V$MYSTAT выводятся статистики текущего сеанса.
Дополнительно можно запросить через представление V$SESSMETRIC значения метрик производительности всех активных сеансов. В этом представлении отражается использование ЦП, количество физических чтений, число полных разборов (hard parses) и коэффициент логических чтений (logical read ratio).
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 16:51. Часовой пояс GMT +3.


Powered by vBulletin®