Время базы данных Прежде чем говорить об оптимизации производительности базы данных, необходимо уточнить, как измеряется эта производительность, тем более, что в памяти многих людей до сих пор жив показатель «время отклика», который многие привыкли рассматривать как универсальную меру производительности СУБД.
связанные с базами данных.
Проблема с так называемым временем отклика заключается в том, что оно, к сожалению, относительно.
Для конечного пользователя, системного администратора, сетевого администратора и администратора базы данных оно различно и зависит не только от чистого времени отклика СУБД, но и от производительности кода бизнес-логики на сервере приложений, производительности веб-службы.
интерфейса, взаимодействие компонентов сетевой инфраструктуры, а также работу межсетевого экрана, балансировщика нагрузки и т. д. Поэтому, чтобы адекватно выразить производительность базы данных, необходимо использовать показатель Database Time, который выражает время, затраченное СУБД при выполнении конкретного вызова (запроса) с момента его поступления в базу данных до момента выдачи последнего фрагмента выборки результатов.
Более строгое определение времени базы данных — это общее время, затрачиваемое пользовательскими процессами на активное выполнение или активное ожидание выполнения вызовов СУБД.
Понятие «Время базы данных» прекрасно иллюстрируется страницей «Топ активности» в Enterprise Manager (рис.
1), где мы видим количество активных сессий и в виде разноцветного графика распределение затраченного времени СУБД, т.е.
Само время.
Инструменты настройки: вчера и сегодня Раньше процесс настройки СУБД был сродни блужданию в темноте — администраторы пытались применить те или иные настройки, которые, по их мнению, могли повлиять на поведение оптимизатора, варьировали их значения, ориентируясь на отзывы конечных пользователей, которые это делали.
не всегда замечаю перемены в лучшую или худшую сторону.
Современная методология настройки производительности под названием 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 интегрирован во все экраны производительности Менеджера базы данных предприятия и позволяют получить сравнительный отчет за любой период времени.
Функциональность Active Session History (ASH) — это функция мониторинга, представленная в Oracle Database 10g. ASH каждую секунду делает снимки состояния активных сессий и записывает их в специальную структуру памяти (см.
Таблицу 1).
На практике это мониторинг в реальном времени.
В Enterprise Manager 12c появился очень удобный графический интерфейс для истории активных сеансов, названный ASH Analytics. 
Советник автоматического монитора диагностики базы данных (ADDM), встроенный в базу данных, помогает интерпретировать диагностику и находить основную причину низкой производительности.
Отчет AWR сам по себе представляет собой довольно объемный документ, который легко может запутать.
ADDM помогает интерпретировать статистику, хранящуюся в репозитории рабочих нагрузок, и находить основную причину проблем.
ADDM анализирует потребление времени базы данных, соотносит его с активностью сеанса и формирует отчет с конкретными рекомендациями.
Важно, что ADDM не просто предупреждает вас о проблемах с производительностью базы данных, он выявляет причины проблем и ранжирует их по степени воздействия.
Наконец, в Oracle Database 12 представлена улучшенная версия Real-Time ADDM, которая автоматически запускается при превышении пороговых значений ряда параметров, например: количества сессий, чрезмерного потребления процессорного времени, конфликтов и других событий, которые снизить производительность базы данных.
Новый ADDM в реальном времени обеспечивает автоматическое обнаружение и анализ проблем в режиме реального времени, автоматически диагностируя критические проблемы с производительностью.
Отчеты ADDM хранятся в репозитории AWR для исторического анализа.
Real-Time ADDM также является средством аварийного мониторинга, которое в случае невозможности нормального подключения к базе данных - если она полностью зависла - может осуществить специальное диагностическое соединение и удалить диагностику непосредственно из памяти СУБД.
Встроенный в базу данных советник поможет диагностировать проблемы и определить их причину.
Анализ всегда лучше начинать с отчета ADDM, поскольку он содержит информацию из AWR и ASH в удобном для первоначального анализа производительности виде.
Для детального анализа выполнения SQL-запросов в Enterprise Manager имеется окно Мониторинг SQL в реальном времени, которое позволяет отслеживать, как выполняется конкретный SQL-запрос, по какому плану он выполняется и на каком этапе плана выполнения.
тратится больше всего ресурсов.
Мониторинг SQL в реальном времени имеет очень интересные метрики, такие как фактические строки и предполагаемые строки.
Используя мониторинг SQL в реальном времени, вы также можете отслеживать выполнение процедур PL/SQL. Решение проблемы Практика показывает, что большинство проблем с производительностью баз данных возникает из-за SQL-запросов — либо неправильно написанных, либо по разным причинам выполненных неэффективно.
Неполная статистика, новая версия оптимизатора, неправильные параметры, конфликты — есть тысяча причин, по которым SQL-запросы могут выполняться некорректно.
Инструмент Oracle SQL Tuning Advisor дает рекомендации по повышению производительности проблемных SQL-запросов с использованием того же оптимизатора SQL-запросов Cost Based Optimizer (CBO), но в специальном режиме настройки, что дает CBO больше времени для всестороннего анализа и проверки.
В процессе анализа используются реальные и исторические данные AWR и определяются альтернативные планы выполнения запросов.
Если использование параллельного профиля SQL ускоряет ваш запрос SQL в два или более раза, советник по настройке SQL порекомендует его.
Также 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 Analyser (SPA), включенный в Real Application Testing, обеспечивает тестирование в Oracle Database 10.2, 11g и 12c, позволяет прогнозировать влияние системных изменений в базе данных на время ответа SQL, определяет результаты производительности SQL для каждого выполнения теста.
Рабочая нагрузка SQL анализирует различия в производительности и сравнивает результаты производительности конкретных запросов SQL. Однако это оказывает минимальное влияние на производительность производственной системы при захвате рабочих нагрузок SQL в наборе настройки SQL (STS).
Новая функция в анализаторе производительности SQL — быстрая проверка SPA в Enterprise Manager позволяет быстро проверять изменения, скажем, параметров оптимизатора, влияющих на планы запросов.
Например, если у вас в наборе тысяча запросов, и в результате только десять из них меняют планы, то SPA Quick Check сначала выявит эти десять запросов и специально для них проведет сравнительное тестирование.
Отдельно стоило бы поговорить о проактивном подходе, т.е.
о том, как предотвратить проблемы с СУБД — об управлении планами запросов, но это отдельная тема, выходящая за рамки данной статьи.
Источники информации Чтобы узнать больше о настройке производительности, в первую очередь следует просмотреть документацию по базе данных Oracle, начиная с 2-дневного руководства по настройке производительности, в котором представлен обзор всего, что мы обсуждали в этой статье.
Руководство по настройке производительности посвящено настройке производительности на уровне экземпляра базы данных.
Настройка SQL-запросов подробно описана в документе «Руководство по настройке SQL».
Другой документ, «Руководство по тестированию», представляет собой руководство по пакету реального тестирования приложений и различным вариантам использования анализатора производительности SQL. Мы также рекомендуем пройти пятидневный учебный курс Университета Oracle под названием «База данных Oracle 12c: управление производительностью и настройка».
Теги: #база данных #12c #время базы данных #тестирование #Enterprise Manager #oracle
-
Apple Mobileme Для Windows!
19 Oct, 24 -
Блогеры Высмеяли Фейковый Сайт Сергея Брина
19 Oct, 24
