Администрируем
Oracle, SQL Server, PostgreSQL

Базовый анализ проблем на сервере СУБД. Часть 3. Комплексные проблемы

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

Сценарии комплексных проблем на сервере СУБД

Опираясь на опыт наших инженеров, рассмотрим пять кейсов, которые хорошо иллюстрируют, что такое комплексные проблемы и к чему они могут приводить.
  1. На слабый с точки зрения ввода / вывода данных сервер поступает большое количество запросов, под которые не создан нужный индекс. Результатом становится повышенная нагрузка на CPU и жесткий диск, что влечет за собой возникновение гигантской очереди из запросов, зависших в статусе выполнения. Из планов выполнения запросов можно будет понять, что нужного индекса действительно не хватает, однако повторение таких ситуаций — повод задуматься о переезде на более мощное железо.
  2. Из-за сбоя в задании, приведшее к долгому отсутствию обслуживания, основная рабочая таблица в БД становится очень сильно фрагментированной (более 90%). Результатом становится прогрессирующая нагрузка на CPU и аномальный рост БД.
  3. Если речь идет о системе с большим числом пользователей, то возможны ситуации, когда два человека запускают одновременно конфликтующие между собой процессы, что может повлечь за собой блокировки в корне и появление «хвоста» из сотен SQL блокировок, способного практически остановить работу БД. То же самое возможно и, если один пользователь запускает процесс, накладывающий долгосрочную монопольную блокировку на одну или несколько таблиц базы.
  4. Еще один пример неполадок, влекущих возникновение комплексных проблем — утрата оптимальности планом запроса. Если для выполнения запроса в новых обстоятельствах ему требуется два часа вместо привычных двух секунд, буквально за полчаса таких запросов может накопиться несколько сотен. Это выливается в перегрузку CPU И жестких дисков, огромные очереди, медленную работу всей системы, а, значит — жалобы со стороны клиентов.
  5. Время выполнения запросов в рамках пула сессий может расти не только из-за слетевшего плана запросов, но и из-за большого количества фантомных строк. Это приводит к сложности локализации проблемы: нет никакой подозрительной нагрузки, конфликтов блокировок SQL, обновление статистики не помогает, индексы не фрагментированы.

Выводы

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

Эксперт ДБ-сервис