Настройка производительности экземпляра Oracle

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

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

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

Помимо всего вышесказанного, в новых статьях также рассматриваются ключевые динамические таблицы производительности, о которых необходимо знать для того, чтобы разбираться с проблемами, связанными с производительностью экземпляра. Хотя средства Automatic Database Diagnostic Monitor (ADDM) и Automatic Workload Repository (AWR) уже рассматривались в предыдущих главах, в этой главе описана роль, которую они играют в процессе настройки экземпляра. Помимо них можно применять и средство Active Session History (ASH), позволяющее изучать хронологию недавних сеансов. Анализ собираемой ASH информации помогает решать множество проблем с производительностью в работающем экземпляре.

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

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

 

Введение в настройку экземпляра

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

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

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

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

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

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

настройка производительности экземпляра базы данных Oracle - введение

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

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

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

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


Заплаты и новые версии программного обеспечения


Компания Oracle, как и другие производители программного обеспечения, периодически выпускает заплаты (patches) или пакеты заплат (patch sets), которые представляют собой наборы исправлений для обнаруженных либо самой Oracle, либо ее клиентами дефектов. При обращении в службу технической поддержки Oracle один из первых вопросов — был ли установлен в Oracle самый последний пакет обновлений. У операционных систем UNIX тоже могут быть свои собственные пакеты заплат, которые может требоваться установить для исправления определенных дефектов.

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

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

Из-за того, что никто не любит подвергать производительность производственной системы рискам, идеальным решением является поддержание тестового сервера, на котором все новое программное обеспечение можно было бы тщательно тестировать перед тем, как переносить его в производственную среду. Однако ждать слишком долго перед переходом на новую версию не стоит — к тому моменту, когда некоторые компании переходят на новую версию, уже даже та
более новая версия Oracle становится устаревшей!

Некоторые из хорошо работавших SQL-операторов могут перестать работать столь же хорошо после перехода на новую версию из-за, например, не такого поведения подсказки (hint) в новой версии. Поэтому чрезвычайно важно тестировать всю систему с новой версией, прежде чем внедрять эту версию в производственную среду. Разумной стратегией является сбор статистических данных по производительности, которые могли бы служить опорными показателями, перед внесением в систему любых серьезных изменений. Такими серьезными изменения могут быть:

  • миграция или обновление базы данных до более новой версии;
  • применение к базе данных или операционной системе нового пакета заплат;
  • добавление в базу данных нового приложения;
  • значительное увеличение количества пользователей.

 

Автоматическая настройка производительности и использование динамических представлений производительности

Раньше администраторам баз данных Oracle для сбора статистических данных и диагностирования проблем с производительностью экземпляра приходилось интенсивно использовать динамические представления производительности (V$). В Oracle 11g по прежнему остался доступ ко всем этим традиционным представлениям, однако теперь также предлагаются и функциональные средства автоматической настройки производительности, позволяющие производить настройку экземпляра более быстрым и легким образом. Действие большинства из этих средств основано на использовании тех же самых динамических представлений производительности VS$, которые применяются во время настройки производительности вручную. Несколько примеров выполнения настройки производительности вручную, конечно, будет приводиться в моих дальнейших статьях, но основной акцент все-таки будет делаться на важности понимания и применения мощного набора средств автоматической настройки производительности, которые уже являются частью базы данных. Ниже приведено краткое описание этих средств.

  • AWR собирает все данные о производительности, которые необходимы для выполнения настройки, а также диагностирования проблем с производительностью.
  • ADDM автоматически производит диагностику производительности базы данных путем анализа данных AWR.
  • Automatic SQL Tuning Advisor (Советник по автоматической настройке SQL) предоставляет рекомендации по настройке SQL-операторов.
  • База данных автоматически запускает задание по сбору статистики и тем самым поддерживает все статистические данные в актуальном состоянии.
  • Segment Advisor (Советник по сегментам) запускается автоматически во время выделенного под обслуживание периода и генерирует рекомендации касательно того, какие сегменты следует сжать, а какие — реорганизовать (например, из-за чрезмерного расщепления строк на несколько блоков).
  • SQL Access Advisor (Советник по оптимизации доступа SQL) предоставляет рекомендации по созданию идеальных индексов и материализованных представлений.
  • Memory Advisor (Советник по настройке размера структур памяти), MTTR Advisor (Советник по среднему времени восстановления) и Undo Advisor (Советник по отмене) помогают настраивать, соответственно, память, журналы повторного выполнения и сегменты отмены.

В следующей моей статье рассматриваться главные динамические представления, которые можно использовать для диагностики проблем с производительностью экземпляра. Раньше администраторы баз данных часто полагались на использующие данные этих представлений сценарии для осуществления мониторинга и настройки производительности экземпляра. Однако теперь лучше всего производить диагностику и настройку производительности Oracle через интерфейс OEM Database Control (или Grid Control). Поэтому здесь также будет описан и простой подход к настройке с помощью OEM Database Control.


На заметку! Средства AWR и ADDM представляют собой такие продукты Oracle, которые нуждаются в приобретении специальной лицензии вместе с пакетом Diagnostic Pack. В случае не приобретения такой лицензии, пользоваться этими средствами не законно.


 

Вас заинтересует / Intresting for you:

Создание БД Oracle 12c с макси...
Создание БД Oracle 12c с макси... 2935 просмотров Андрей Васенин Mon, 20 Aug 2018, 13:43:20
Настройка памяти базы данных O...
Настройка памяти базы данных O... 10094 просмотров Stas Belkov Sat, 07 Jul 2018, 15:44:14
Нужно ли менять настройки базы...
Нужно ли менять настройки базы... 4639 просмотров Tue, 21 Nov 2017, 13:31:33
Мониторинг Oracle через метрик...
Мониторинг Oracle через метрик... 3307 просмотров sepia Tue, 21 Nov 2017, 13:18:05
Войдите чтобы комментировать

1dz аватар
1dz ответил в теме #8919 12 фев 2018 12:23
Подробнейший разбор полетов по настройке экземпляра. Благодарю за статью! Скажите, а насколько это применимо к версии Oracle 12c? Там же все еще больше автоматизированно?