В прошлой статье об инструменте для мониторинга Foglight for Databases мы рассказывали о возможностях контроля из единого интерфейса SQL Server, Oracle, PostgreSQL, MySQL, SAP ASE, DB2, Cassandra и MongoDB. Сегодня разберём подходы к быстрому выявлению причин нештатной работы Microsoft SQL Server:
- Поиск источника блокировки;
- Сравнение настроек БД «было-стало» с привязкой к метрикам производительности;
- Поиск изменений в структуре БД, из-за которых снизилась производительность.
Подробности под катом.
Foglight for Databases — инструмент мониторинга за производительностью и изменениями в популярных базах данных. Если вы не знакомы с этим продуктом — рекомендуем прочитать предыдущую статью. А ниже мы привели скриншоты из интерфейса для демонстрации возможностей Foglight и простоты поиска проблем в БД.
Поиск источника блокировки
Поиск причины блокировок можно вести в Management Studio. Но рабочей станции с этой утилитой может не оказаться под рукой, да и открывать консоль не всегда удобно. В Quest Foglight найти причину блокировку можно за считанные клики. На скриншоте ниже вы видите основную консоль мониторинга баз данных.
Дежурный администратор, который уже получил уведомление, переходит в представление SQL PI (Performance Investigator). В столбце Workload заметно красное поле, которое означает ненулевое значение параметра Lock Wait.
После клика по графику Workload открывается детальное представление источников нагрузки на БД, а в столбце слева меню для проведения многомерного анализа производительности. Здесь, как и на скриншоте выше видно, что блокировка вызывает большую утилизацию ресурсов. В меню слева есть специальное представление Locked Objects, в котором и обнаружится заблокированный объект.
В Locked Objects хранятся заблокированные объекты. В правой части экрана причины блокировок: длительность, с какого сервера (или рабочей станции), какой программой, от какого пользователя и исполняемый объект, который привёл к блокировке.
При переходе на исполняемый объект, откроется новое представление с возможностью просмотра содержимого этого объекта. И после нажатия на View Batch Text откроется исполненный код.
Ускорение времени диагностики — залог успешной работы команды ИТ.
Сравнение настроек БД «было-стало»
К драматическому снижению производительности могут также приводить изменения, произведенные разработчиками или администраторами БД. Но в момент проблемы неважно кто это сделал — важно что произошло. С этим и попробуем разобраться. Открываем контекстное меню проблемного экземпляра БД.
В открывшемся меню нужно перейти на SQL PI (Performance Investigator), чтобы открыть представление с многомерным анализом.
Перейдём на представление Baseline для оценки поведения метрики в сравнении с её обычными значениями.
На графике видно, что после 13:40 начался аномальный рост потребления ресурсов.
В это представлении настроим что с чем сравнивать. Сейчас рассмотрим сравнение метрики самой с собой (по базовой линии), т.к. выше выявили аномальное отклонение. Вообще, можно также сравнить производительность и с другим экземпляром БД.
После выбора объектов для сравнения появится заветная кнопка Compare.
На среднем представлении видно, что аномальные значения наблюдались по метрикам: Active Time, Executions и Logins Rate. Начнём новое сравнение для выявления изменений.
Сравним значения метрик с самими собой, но день назад.
После выбора настроек, появится кнопка Compare, на которую нужно нажать.
Появится представление, на котором есть измерения для сравнения. Для демонстрации мы выберем пункт меню Programs. В разделе Statistics уже виден двукратный рост значения метрики Executions.
Слева и справа от шкалы в разделе меню Programs отображаются значения метрик. Здесь видим, что Active Time и Executions выросли почти в два раза, а это повод для проведения детального разбора ситуации.
Таким же образом можно проводить сравнительный анализ и по другим метрикам, а любое представление выгрузить в PDF-отчёт.
Поиск изменений в структуре БД
Изменения индексов, execution plans и других объектов может носить недокументированный характер. Разработчик или администратор БД вносит, казалось бы, незначительные изменения, о которых через некоторое время может забыть. В интерфейсе Foglight for Databases изменения конфигурации привязываются к изменениям производительности. Для выявления изменений переходим с главного экрана мониторинга БД на представление Workload.
Допустим, нам известно, что с какой-то клиентской машины генерируется большая нагрузка на БД. Раскрываем в представлении слева Client Machines.
Batches отсортированы в соответствии с создаваемой нагрузкой на БД. Перейдём на первый объект в списке и далее посмотрим изменения по нему (Change Tracking).
На графике, согласно легенде справа, отмечены соответствующие изменения за выбранный период. Первое изменение здесь — удаление индекса, второе — добавление нового execution plan. Как видно, после удаления индекса резко возросла нагрузка Other Wait — фиолетовая зона (к ней также относится выполнения batch job). Четвертое изменение — увеличение значения уровня параллелизма, что потенциально привело к повышение количества запросов (IO Wait — голубая зона). Рассмотрим последствия добавления нового execution Plan.
После перехода открылись детали нового execution plan. Теперь сравним произошедшие изменения.
После перехода открылись детали нового execution plan.
Этот же execution plan можно открыть в Management Studio прямо из интерфейса Quest Foglight.
Так он выглядит в консоли Management Studio.
При переходе на представление History можно увидеть изменения метрик во времени.
Представление History можно использовать для оценки влияния изменений на ту или иную метрику. Далее переходим на представление Other.
На этом представлении видно какие batches повлияли на нагрузку БД. Они уже отсортированы в порядке убывания.
Кроме автоматического отслеживания изменений, пользователь Foglight может добавить изменения вручную В случае снижения производительности, дежурный администратор уже не будет искать причину деградации сервиса.
Если вам понравился Foglight for Databases и вы хотели бы его попробовать на своих БД — оставьте заявку на получение дистрибутивов и триального ключа в форме обратной связи на нашем сайте. Стабильной работы баз данных и быстрой локализации нештатной работы!
Автор: Галс Софтвэр
