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

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

Настройка производительности главным образом подразумевает написание эффективных SQL-запросов, выделение подходящего количества вычислительных ресурсов и анализ событий ожидания и состязания за ресурсы в системе. Я планирую написать целый ряд статей, в которых основное внимание будет уделяться оптимизации выполнения SQL-запросов в Oracle. Вы узнаете об оптимизаторе Oracle и том, как для него собирать статистические данные, как с помощью новой опции Automatic Optimizer Statistics Collection (Автоматический сбор статистических данных для оптимизатора), так и вручную с помощью пакета DBMS_STATS, а также о важных принципах, которые лежат в основе эффективного кода, и различных инструментах, наподобие утилит EXPLAIN PLAN и SQL Trace, которые позволяют анализировать SQL-запросы и находить пути для улучшения их производительности.

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

 

Подход к настройке производительности в Oracle

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

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

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

Как настроить оптимальную производительность базы данных Oracle - подходы и методы

 

Систематизированный подход к настройке производительности

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

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

  1. Правильно проектировать приложение.
  2. Настраивать используемый в приложении SQL-код.
  3. Настраивать память.
  4. Настраивать ввод-вывод.
  5. Настраивать состязания за ресурсы и прочие детали.

 

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

Хотя приведенные выше шаги по настройке производительности создают впечатление о том, что можно следовать конкретной последовательности по порядку, в реальности все выглядит совершенно иначе. Настройка производительности представляет собой итеративный процесс, а не последовательный, при котором все начинается сверху и заканчивается полностью настроенной базой данных. Администратор баз данных может быть задействован в новом проекте с самого начала и отвечать за функциональные требования. В таком случае у него есть возможность принимать участие в настройке приложения на самых ранних этапах построения базы данных, которую некоторые несколько не совсем корректно называют проактивной настройкой (proactive tuning). Или же администратор баз данных может получать доступ к приложению лишь тогда, когда оно уже спроектировано, реализовано и находится в производственной среде. В таком случае ему остается выполнять только так называемую реактивную настройку производительности (reactive performance tuning). То, что администратор баз данных может делать для улучшения производительности базы данных, зависит от этапа, на котором он у него появляется возможность вступить в игру, и от природы самого приложения.

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

Во многих случаях иметь дело с проблемами производительности приходится в производственном экземпляре, который был спроектирован и закодирован давным-давно. Сначала можно попробовать исправить SQL-операторы, если такое вообще возможно. Многие специалисты утверждают, что если приложение имеет серьезные недостатки, для увеличения общей производительности базы данных практически ничего сделать нельзя, и, пожалуй, они правы. Однако даже если не совсем оптимальный код невозможно изменить по той или иной причине, все равно можно добиться серьезной разницы в производительности. Есть несколько приемов, которые можно использовать для улучшения производительности даже тогда, когда код плохо написан и нет возможности изменить его в ближайшем будущем. Приблизительно то же самое можно сказать и об упакованных средствами настройки производительности системах наподобие PeopleSoft и SAP, в которых тоже нельзя проникать в лежащий в основе код. В инструменте SQL Advisor доступна опция SQL Profiles (Профили SQL), с помощью которой можно улучшать производительность, даже несмотря на отсутствие возможности затрагивать лежащий в основе SQL-код. Настройка SQL, которой посвящена эта глава, и является тем способом, которым можно улучшать ситуацию в обеих упомянутых ситуациях. О том, как настраивать производительность ресурсов базы данных вроде памяти, дисков и ЦП, речь пойдет в следующей главе.

 

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

Создание БД Oracle 12c с макси...
Создание БД Oracle 12c с макси... 4268 просмотров Андрей Васенин Mon, 20 Aug 2018, 13:43:20
Нужно ли менять настройки базы...
Нужно ли менять настройки базы... 5216 просмотров Tue, 21 Nov 2017, 13:31:33
Настройка памяти базы данных O...
Настройка памяти базы данных O... 19197 просмотров Stas Belkov Sat, 07 Jul 2018, 15:44:14
Настройка производительности э...
Настройка производительности э... 4249 просмотров Antoniy Mon, 29 Jan 2018, 17:37:48
Войдите чтобы комментировать

apv аватар
apv ответил в теме #8872 6 года 2 мес. назад
Согласен с автором статьи, - подход к настройке производительности должен быть цельным и взвешенным. Нельзя использовать только узконаправленные инструменты и метаться из стороны в сторону. Статья очень хорошая. Дает правильное представление о целях, задачах и способах их решения.