С чего все начинается
В одной из прошлых статей мы рассматривали вопросы мониторинга SQL Server в контексте работы с платформой 1С. И это правильно, ведь мониторинг СУБД является залогом стабильной работы информационной системы и всей компании.
Но что, если Вы как консультант / эксперт только пришли к новому клиенту / на новое место работы. Мониторинга там нет, но нужно понять, разобраться что там вообще происходит. Разобраться что за сервер вообще установлен, делаются ли бэкапы, какие базы развернуты, все ли в порядке с обслуживанием и так далее.
Сегодня мы рассмотрим подобные вопросы. Начнем знакомство с сервером с помощью простых запросов, а остановимся на примерах поинтереснее.
Скриптов достаточно?
Думаете, что все возникающие вопросы с СУБД можно решить скриптами? Многие вопросы, но точно не все!
Например, полноценный мониторинг сервера и сбор счетчиков производительности средствами СУБД точно не реализовать, ведь данные нужно не просто собирать, но и обрабатывать, компоновать, визуализировать и, в конечном, счете как-то интерпретировать.
Конечно, SQL Server может решить все перечисленные задачи, ведь даже счетчики производительности операционной системы с его помощью можно собирать! Но это не всегда возможно, ведь тогда надо держать его установленным на всех серверах, даже которые к СУБД не относятся. А про сопровождение такого решения я вообще молчу.
Поэтому сделаю важное уточнение — с помощью предлагаемого набора скриптов решить все задачи с настройкой и мониторингом СУБД невозможно! А вот получить первое представление о ее состоянии, и поверхностную информацию о проблемах — самое то!
Ближе к делу
Меньше слов — больше T-SQL скриптов!
Знакомимся с сервером
На первом этапе всегда было бы полезно узнать следующую информацию.
Базовая информация о сервере
Время работы с момента запуска
Количество активных соединений
После этого мы можем двигаться дальше.
Псс, бэкапы есть?
Второй вопрос — что там у Вас с резервным копированием.
Информация о бэкапах
Резервное бэкапирование не настроено? Тогда пора заняться этим как можно скорее.
Груз баз данных
Базы бывают разные: маленькие, средние, большие, а также неизвестного размера 🙂 Последняя категория — самая страшная, ведь неизвестность не принесет ничего хорошего. Давайте же узнаем с чем мы имеем дело.
Список баз
Сам по себе список баз даст мало полезного. Давайте посмотрим что там с их размером.
Размер баз
Еще может возникнуть вопрос где же эти базы хранятся.
Расположение файлов баз данных
Но что скрывается за этими общими цифрами?
Размеры таблиц
Отлично, теперь мы уже имеем представление о сервере, резервном копировании и базах данных, которые здесь находятся. Можно перейти к вопросам эффективности работы СУБД.
Что там с индексами
Состояние индексов и их правильное построение в базе — залог эффективной работы запросов и приемлемого быстродействия. Проведем исследование индексов в базах данных.
Список индексов
Теперь можно посмотреть какие индексы полезные.
Статистика использования индексов
Что ж, информация об использовании индексов у нас есть. Мы можем понять какие индексы избыточны и что-то с ними сделать. Но чаще всего проблема вовсе не в избыточности индексов, а в их недостаточности.
Отсутствующие индексы
Еще одним важным показателем состояния индексов является процент фрагментации.
Проверка фрагментации индексов
Вы знаете, что делать с индексами дальше!
Статистику бы проверить
С индексами разобрались, но для их корректной работы очень важно состояние статистики базы данных.
Состояние статистики
Нашли проблему в обслуживании? Обслужите статистику!
Производительность — наше все!
На финал оставим скрипты для диагностики производительности. На самом деле очень много различных подходов для анализа проблем производительности. Как было сказано в начале статьи, только скриптами не всегда удается найти причину проблем и нужен полноценный мониторинг. Но общее направление для расследования понять точно можно.
Ожидания
Далее можно посмотреть на статистику использования процессорных ресурсов и дисковой подсистемы по базам.
Использование CPU и дисков по базам
Дальнейшее расследование и действия сильно зависит от полученной информации на данном этапе. Далее можно:
- Настроить мониторинг SQL Server’а (как внутренних показателей СУБД, так и счетчиков производительности).
- С помощью отчета "Просмотр и анализ структуры базы данных (отчет на СКД)" на платформе 1С анализировать информацию о базе данных в привычном виде.
И думать, работать дальше 🙂
Пока что все
В статье нет готового рецепта для решения всех проблем. Лишь скрипты. Скрипты для начала знакомства с сервером СУБД, получения узкой информации и получения сведений о потенциальных проблемах.
Дальше все зависит только от Вас!
"А как же PostgreSQL?!", — спросите Вы. Сейчас это "хайповая" СУБД, и возможно она станет на первое место по использованию в будущем. Думаю, мы обратимся к ней в следующих публикациях. Жаль, что ее инструменты диагностики не такие развитые как у SQL Server, но все ведь может поменяться.
До скорых встреч и хорошего настроения!
Юрий, спасибо за статью!
Слушал тут письма Паисия святогорца, глубокую мысль толкнул святой человек: «Лень в молодости — бедность в старости!»
Каково!
Про меня написал! 🙂
(5) Не думаю, что бедность в старости может быть исправлена отсутствием лени. 🙂
Особенно в текущей ситуации ))))
(6)Тут какая глубина — «учись, дурак, в молодости, пока не поздно, в старости будешь пожинать плоды своей ленности»!
Вы, вот, не ленились, результат на лицо! 🙂
Все это можно посмотреть без ваших скриптов, запросов, все это есть в интерфейсе сервера, очень похоже на то как люди «привыкшие «к dos очевидные простейшие задачи в виндовс 95 и старше делали в cmd.. Бесполезная статья с многобещающим названием к сожалению
(8) спасибо, рад стараться. Интерфейсные настройки всегда лучше.
(На самом деле нет)
«И думать, работать дальше » — эх, вот по этой теме бы тоже статейку 🙂
(10) а об этом Вы узнаете после рекламы :)))
(8) Не суди и судим не будешь. В интерфейсе сервера заложены дефолт отчеты и прочее, а скрипты позволяют в разы быстрее и детальнее получить нужную информацию — ничто тебе не мешает просто взять любой скрипт и видоизменить под свои какие-то конкретные задачи. Лично пользовался стандартными инструментами msqlms, и они предназначены в целом для новичков, кто понятия не имеет о внутреннем устройстве СУБД, и видит только верхушку айсберга.
В итоге получается что для подтверждения твоих слов у тебя только 2 варианта — написать свою статью «не»бесполезную»», либо принять суровые риали дилетанта.
P.S. Умение пользоваться cmd даст тебе персональный буст навыков, и тут дело не в возрасте, а в навыке
P.S.S. Пользование интерфейсными настройками — повестись на «красивые» кнопочки и картиночки, а не работать с реальными данными.
(12) (8) Особенно скрипты позволяют автоматически собирать и отправлять нужную информацию, например если место на диске заполнилось.
А не сидеть и мониторить, а не съела ли база все место на диске.
(13) плюс ко всему добавлю, что только скриптами можно получать информацию из десятка серверов, отправляя скрипт через PowerShell например.
А использовать GUI SSMS для такого — это ад просто.
теперь давайте версию статьи для postgres
(15) будет время — будет статья 🙂
(15) А вот и PostgreSQL пришел 🙂
(6)
Подскажите как интерпретировать результат CPU и диски по базе?
Какие значения — ок, а какие — нет.