Database Time

Прежде чем говорить об оптимизации производительности баз данных, нужно пояснить, каким показателем эта производительность измеряется, — тем более что в памяти многих людей, связанных с базами данных, еще жив показатель «время отклика», который многие привыкли считать универсальным мерилом производительности СУБД.

Проблема с так называемым временем отклика состоит в том, что оно, увы, относительно. Для конечного пользователя, системного администратора, сетевого администратора и администратора баз данных, оно разное и зависит не только от чистого времени отклика СУБД, но и от производительности кода бизнес-логики на сервере приложений, производительности веб-интерфейса, взаимодействия компонентов сетевой инфраструктуры, работы брандмауэра, балансировщика нагрузки и т. д. Поэтому для того, чтобы адекватно выражать производительность базы данных, надо пользоваться показателем Database Time, который выражает время, потраченное СУБД на выполнение конкретного вызова (запроса), с момента его поступления в базу данных и до момента выдачи последнего фрагмента выборки результатов. Более строгое определение Database Time — общее время, проведенное пользовательскими процессами в активном выполнении или активном ожидании выполнения вызовов СУБД.

Концепцию Database Time прекрасно иллюстрирует страница Top Activity в Enterprise Manager (Рисунок 1), где мы видим количество активных сессий и, в виде разноцветного графика,- распределение потраченного времени СУБД т.е. собственно Database Time.

Инструменты настройки: вчера и сегодня

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

Современная методология настройки производительности, которая называется Find-Fix-Validate (Рисунок 2), позволяет точно диагностировать проблемы производительности с помощью инструментальных средств анализа производительности СУБД, решать их с использованием средств автоматической настройки, входящих в набор Tuning Pack, и проверять корректность принятых мер средствами тестирования, входящими в пакет Real Application Testing.

Ищем проблему

Новейшие версии СУБД Oracle, в том числе, конечно, Oracle Database 12c, буквально “облеплены датчиками” производительности и помимо своей основной работы (выполнения запросов, оптимизации, выдачи результатов, координации действий пользователей) постоянно сообщают о том, чем они занимаются, — публикуют события ожидания и временные характеристики вызовов. Поэтому всегда точно известно, сколько времени у СУБД ушло на ту или иную активность.

Надо сказать, что компания Oracle к реализации этой возможности подошла довольно элегантно и не стала изобретать собственный язык для доступа к диагностической информации, а оформила ее в виде специальных таблиц Базы Данных, доступ к которым можно получить с помощью языка SQL и графического интерфейса Enterprise Manager 12c. Таким образом, мониторинг, диагностика и поиск первопричин различных проблем для пользователей СУБД Oracle максимально упрощен.

Таблиц, которые содержат необходимую информацию, немало, уже несколько сотен, статистика в них довольно разрозненная и к тому же накопительная. Но, разумеется, нет необходимости сравнивать показатели вручную, поскольку для сравнительного анализа полученных данных разработан специальный диагностический репозиторий Automatic Workload Repository (AWR), который периодически (по умолчанию – ежечасно) снимает с таблиц диагностическую информацию — различные классы ожидания, метрики, основную статистику, статистику по SQL-запросам и так далее. Данные AWR сохраняются в БД и используются для диагностических отчетов. Технология AWR Baselines позволяет создавать эталонные интервалы времени, сопоставляя бизнес-операции, например закрытие операционного дня, отчетного периода, расчета зарплаты и т. п. с интервалами снимков AWR и периодически проводить сравнительный анализ производительности для выбранного интервала. Эта технология позволяет быстрее делать анализ вариаций нагрузки и облегчает диагностику производительности базы данных.

AWR-отчет по умолчанию сохраняется в формате HTML (Рисунок 3, слева). Есть и новый тип отчета – он называется Performance Hub, – который отображает статистику работы БД в удобной и наглядной графической форме (Рисунок 3, справа).

В Oracle Database 12.1.0.2 появилась еще одна новая, очень удобная форма AWR-отчета — Active-HTML-отчет. Он сочетает в себе возможности навигации и детализации Enterprise Manager для оффлайн-анализа, его можно сохранять и отправлять по почте, как другие активные отчеты, для его просмотра не требуется Enterprise Manager.

AWR Warehouse — центральный репозиторий для долговременного хранения AWR-данных. Он хранится в отдельной, выделенной Базе Данных — таким образом, можно увеличить период хранения снимков AWR хоть до бесконечности, чтобы анализировать хронологию, посмотреть, что было год назад, 2 года назад и т. д. AWR Warehouse интегрирован во все экраны производительности БД Enterprise Manager и позволяет получить сравнительный отчет за любой период времени.

Функциональность Active Session History (ASH) — средство мониторинга, которое появилось в Oracle Database 10g. ASH ежесекундно делает снимки состояния активных сессий и записывает их в специальную структуру памяти (см. Таблица 1). Практически это мониторинг в режиме реального времени. В Enterprise Manager 12c появился очень удобный графический интерфейс к Active Session History, который называется ASH Analytics.

Встроенный в базу данных советчик Automatic Database Diagnostic Monitor (ADDM) помогает интерпретировать диагностику и находить первопричину плохой производительности. Сам по себе AWR-отчет — это достаточно объемный документ, в котором легко запутаться. ADDM помогает интерпретировать статистику, сохраненную в Workload Repository и находить первопричину проблем. ADDM анализирует потребление Database Time, соотносит его с активностью сессий и создает отчет с конкретными рекомендациями. Важно, что ADDM не просто ставит вас в известность о проблемах производительности БД, а выявляет причины проблем и ранжирует их по степени влияния.

Наконец, в Oracle Database 12 появилась улучшенная версия Real-Time ADDM, которая автоматически запускается при превышениях пороговых значений ряда параметров, например: количества сессий, чрезмерном потреблении процессорного времени, конфликтах и прочих событиях, понижающих производительность базы данных. Новый Real-Time ADDM отличается возможностями автоматического обнаружения и анализа проблем в реальном времени, автоматической диагностикой серьезных проблем производительности.

ADDM-отчеты сохраняются в AWR-репозитории для исторического анализа. Real-Time ADDM – это, также, средство аварийного мониторинга, которое при невозможности обычного соединения с базой данных — если она «намертво зависла» — может выполнить специальное диагностическое соединение и снять диагностику прямо из памяти СУБД. Встроенный в базу данных советник поможет в диагностике проблем и определит их причину. Всегда лучше начинать анализ именно с ADDM-отчета, потому что он содержит информацию из AWR и из ASH в удобном для первичного анализа производительности виде.

Для детального анализа выполнения SQL-запросов в Enterprise Manager имеется окно Real-Time SQL Monitoring, которое позволяет следить за тем, как выполняется конкретный SQL-запрос, по какому он выполняется плану и на каком шаге плана выполнения тратится больше всего ресурсов. В Real-Time SQL Monitoring есть очень интересные показатели, такие как Actual Rows и Estimated Rows. С помощью Real-Time SQL Monitoring можно также контролировать выполн��ние PL/SQL-процедур.

Устраняем проблему

Практика показывает, что большинство проблем производительности Баз Данных возникают из-за SQL-запросов — либо некорректно написанных, либо, по разным причинам, неэффективно выполняющихся. Неполная статистика, новая версия оптимизатора, неправильные параметры, конфликты — есть тысяча причин, по которым SQL-запросы могут выполняться некорректно. Инструмент Oracle SQL Tuning Advisor дает рекомендации по повышению производительности проблемных SQL-запросов, используя все тот же оптимизатор SQL-запросов Cost Based Optimizer (CBO), но в специальном настроечном режиме, давая CBO больше времени на всесторонний анализ и проверку. В процессе анализа используются реальные и исторические AWR-данные и выявляются альтернативные планы выполнения запросов. Если при использовании параллельного SQL-профиля выполнение SQL-запроса ускорится в два или более раз, SQL Tuning Advisor порекомендует и его. Также, SQL Tuning Advisor проверит различные варианты рекомендаций и вы получите в Enterprise Manager отчет о том, какой SQL-запрос проанализирован и какие рекомендации по его настройке предложены.

Новая версия инструмента SQL Access Advisor, которая появилась в Oracle Database 12c, позволяет значительно сократить время анализа для больших SQL-нагрузок. SQL Access Advisor анализирует не единичные SQL-предложения, а SQL-нагрузку за определенный период времени. Теперь он работает гораздо производительнее и в десятки раз быстрее анализирует объекты БД.

И SQL Access Advisor, и SQL Tuning Advisor имеют графический интерфейс в Enterprise Manager.

Проверяем результат

Инструмент SQL Performance Analyzer (SPA), входящий в Real Application Testing обеспечивает тестирование в Oracle Database 10.2, 11g и 12c, позволяет предсказать влияние системных изменений Базы Данных на время отклика SQL, определяет результаты производительности SQL для каждого тестового выполнения SQL-нагрузки, анализирует различия в производительности и сравнивает результаты производительности конкретных SQL-запросов. При этом он оказывает минимальное влияние на производительность рабочей системы при захвате SQL-нагрузки в SQL Tuning Set (STS).

Новая возможность SQL Performance Analyzer — SPA Quick Check в Enterprise Manager позволяет быстро проверить изменения, скажем, параметров оптимизатора, влияющих на планы запросов. Например, если у вас в наборе тысяча запросов, а планы, в результате, изменятся только у десяти из них, то SPA Quick Check сначала выявит эти десять запросов и проведет сравнительное тестирование именно для них.

Отдельно стоило бы поговорить о проактивном подходе т.е. о том, как не допускать возникновения проблем с СУБД — об управлении планами запросов, но это отдельная тема, выходящая за рамки данной статьи.

Источники информации

Чтобы больше узнать о настройке производительности, в первую очередь стоит изучить документацию к Oracle Database, для начала, документ «2 Day + Performance Tuning Guide», который дает обзор всего, что мы обсудили в рамках этой статьи. Руководство «Performance Tuning Guide» посвящено настройке производительности на уровне экземпляра базы данных. Настройка SQL-запросов детально описана в документе «SQL Tuning Guide». Еще один документ, «Testing Guide», представляет собой руководство по пакету Real Application Testing и различным возможностям использования SQL Performance Analyzer. Рекомендуем, также, пройти пятидневный учебный курс Oracle University, который называется «Oracle Database 12с: Performance Management and Tuning».

Oracle Database 12c: настройка производительности