Чтобы получить обзор и сопоставимые данные, моей текущей задачей является создание базовых показателей производительности, чтобы получить некоторые данные о различных продуктивных экземплярах SQL Server.
Мои мысли:
- Я хочу использовать несколько DMV
- Я хочу включить трассировку профилировщика (в т.ч. Exec. Планы)
- Я хочу включить данные perfmon
Итак, я пытаюсь добиться общего запуска и остановки мониторинга производительности (также по расписанию), который возвращает:
Вся информация, необходимая для определения успеха текущих задач оптимизации производительности
Пара агрегированных простых фигур, которые помогают визуализировать долгосрочный прогресс .. особенно для управления ;-)
Повторно выполняемые планы выполнения в трассировке профилировщика для сравнения отдельных изменений и улучшений очереди с помощью задач оптимизации индекса
Я нашел пару информации, описывающей создание базовых показателей производительности. Большинство из них либо очень сложны, либо фокусируются только на одном из желаемых показателей эффективности (в основном на данных пермонов).
Наиболее подходящим примером / описанием было следующее: Создание базовых показателей производительности для SQL Server.
Вопрос в том:
У кого-нибудь есть опыт создания такого монитора производительности в быстро выполнимой манере?
источник
Ответы:
Более чем через год я хочу, чтобы все знали мой опыт и окончательный результат этого вопроса / темы.
Я начал создавать вещи самостоятельно. Вначале я следовал статье « Сбор и хранение исторических данных счетчиков производительности SQL Server с CMV » Тима Форда, чтобы что-то поднять и дополнить этими данными, которые я хотел собрать. Поэтому один раз в день я запускаю несколько хранимых процедур на каждом сервере Sql, которые собирают определенную информацию из DMV и сохраняют результаты на локальном сервере внутри базы данных. Это включает в себя использование индекса, отсутствующие индексы, определенные записи журнала, такие как автостраковка, настройки сервера, настройки базы данных приложения, фрагментация, выполнение задания, информация журнала транзакций, информация о файле, статистика ожидания и многое другое.
Кроме того, я добавил в этот репозиторий результаты регулярного выполнения sp_blitz Брента Озара, чтобы собрать дополнительные ценные указания для работы, улучшения и составления отчетов.
Все данные впоследствии собираются оттуда на выделенный сервер мониторинга Sql, и таким образом я создаю объединенное хранилище для информации о производительности всех моих серверов и использую ее в качестве базы для расследования и составления отчетов.
Затем я создал таблицы Excel, а также отчеты, используя службы отчетов для анализа и интерпретации. Некоторые образцы:
Также я настроил мониторинг некоторых счетчиков производительности с помощью TYPEPERF, вдохновленного статьей Федора Георгиева « Сбор данных о производительности в таблицу SQL Server ».
Из моего экземпляра SQL Monitoring я запускаю typeperf и собираю настраиваемое количество выборок с настраиваемым интервалом выборки и сохраняю результаты в моей базе данных центрального мониторинга.
Это позволяет мне наблюдать долгосрочные значения производительности, пример:
Через некоторое время использования этого для сбора исходной информации выяснилось, что на поиск неудачных заданий, процедур устранения ошибок (например, в случае отключения БД в автономном режиме) приходится потратить довольно много работ по обслуживанию. не удалось выполнить сценарии), поддерживая настройки после замены сервера ...
Кроме того, база данных, собирающая все записи, нуждается в техническом обслуживании и настройке производительности, поэтому для обеспечения полезности этих данных требуется дополнительная работа ...
Что в конечном итоге полностью отсутствует, так это способность смотреть на то, что происходит вживую. В лучшем случае я смогу рассказать, что, возможно, происходило на следующий день после запуска сборщиков данных. Также все детали отсутствуют. У меня нет доступа к графикам взаимоблокировок, я не могу посмотреть планы запросов, которые выполнялись в подозрительном периоде ....
Все это заставило меня поручить руководству тратить деньги на профессиональное решение, которое я не могу создать самостоятельно.
Окончательный выбор состоял в том, чтобы купить SentryOne, потому что по сравнению с другими он убедителен и предоставляет много информации, необходимой для определения наших болевых точек.
В качестве заключительного заключения я бы посоветовал всем, кто ищет ответы на подобные вопросы, не пытаться создавать вещи самостоятельно, если у вас нет небольшой и в основном здоровой среды. Если у вас есть пара систем и много проблем, лучше немедленно обратиться за профессиональным решением и использовать помощь поставщика в решении ваших проблем, а не тратить много времени и денег на создание чего-то менее полезного. Однако этот маршрут все еще был очень интересным и заставил меня многому научиться, я не хочу пропустить.
Я надеюсь, что вы найдете это полезным, как только вы столкнулись с этой веткой вопросов.
РЕДАКТИРОВАТЬ 20 апреля 2017 г .: Брент Озар недавно опубликовал на Facebook следующую статью, в которой рассказывается, что подобный подход используется командой SQL Tiger: https://blogs.msdn.microsoft.com/sql_server_team/sql-server-performance-baselining. -reports-развязали-для-предприятия-контроля /
источник
Вот несколько хороших статей с некоторыми практическими примерами, которые вы можете найти здесь:
Как обнаружить проблемы производительности SQL Server с использованием базовых показателей - Часть 1 - Введение
Как обнаружить проблемы производительности SQL Server с использованием базовых показателей. Часть 2. Сбор метрик и создание отчетов
Как обнаружить проблемы производительности SQL Server с использованием базовых показателей - Часть 3
В то время как часть 1 предоставит вам некоторые базовые знания о том, что такое базовый уровень, во второй части вы можете найти информацию, как это сделать самостоятельно, используя метод «бедняк» (это бесплатно и полезно для обучения)
В части 3 приведены некоторые примеры того, как вы можете установить базовые показатели и как использовать базовые показатели при устранении некоторых проблем с помощью ApexSQL Monitor.
источник
Как недавно созданный администратор баз данных, я управлял набором бесплатных инструментов и экспериментировал с платным пространством (DPA, SQL Sentry и Foglight), и это действительно зависит от того, для чего вам нужен инструмент.
По моему опыту, самым важным было не просто установить базовые показатели производительности (руководству было все равно, если некому было орать), но и создать что-то в удобном для использования формате, который бы четко определил приоритеты и смог бы отслеживать производительность. проблемы в производстве.
Вы можете усовершенствовать свои навыки, пройдя бесплатный маршрут, и инструменты для SQL Server великолепны.
С этими и некоторыми дополнительными базами данных / таблицами и заданиями и временем вы можете создать базовую систему мониторинга (но это не красиво), это инструменты для администраторов баз данных; если вы не разбираетесь в BI, вы будете изо всех сил пытаться найти из него полезные для бизнеса вещи, хотя приложение Ozar sp_blitz довольно круто.
Потратив около года на бесплатную работу и решив множество проблем (но не получая большого интереса), я смог четко заявить, после серьезной проблемы, что программное обеспечение для мониторинга перфорирования было приоритетом, и мы собирались его купить. что бы ни случилось.
После демонстрации ранее упомянутых клиентов я выбрал DPA, потому что руководство могло легко потреблять результаты, хотя у меня определенно есть клиентские лицензии для SQL Sentry Plan Explorer Pro (1000% стоит денег), и мне действительно нравилось использовать версию сервера, он просто не брал их так же.
Я также пытался заставить SQLNexus работать в один момент, но в итоге я работал больше, чем мне было интересно, это может удовлетворить ваши потребности.
источник
Чтобы быстро создать базовый показатель производительности и получить некоторые сведения о различных продуктивных экземплярах SQL, я бы использовал бесплатную пробную версию стороннего инструмента, такого как Solarwinds Database Performance Analyzer.
источник
Прочитайте эту книгу !!! SQL Server Tacklebox
В нем показано, как использовать запросы SSIS и TSQL для сбора информации мониторинга для всех экземпляров SQL Server в вашей среде.
источник
Я шел по тому же маршруту, что и некоторые из вышеперечисленных плакатов, но потом наткнулся на что-то, созданное Microsoft.
Это было кратко упомянуто выше, но никакой явной ссылки не было. Команда Microsoft Tiger разработала «Tiger Toolbix», который можно загрузить здесь: https://github.com/Microsoft/tigertoolbox
Видео на YouTube объясняет набор инструментов Tiger: https://www.youtube.com/watch?v=bx_NGNEz94k
Есть также https://github.com/sqlcollaborative/dbareports.
источник