SQL Server Монитор активности: Полное руководство для администраторов баз данных [2026]

1. Введение

1.1 Что такое SQL Server Монитор активности?

SQL Server Activity Monitor — это встроенная диагностическая программа.ostic инструмент внутри SQL Server Студия управления, которая отображает информацию о SQL Server Процессы и их влияние на производительность сервера. Позволяет отслеживать SQL Server процессы, отслеживайте ожидание ресурсов, анализируйте дорогостоящие запросы и наблюдайте за шаблонами ввода-вывода — все это с помощью одного интерфейса.

1.2 Зачем использовать SQL Server Монитор активности?

Мониторинг активности — это ваша первая линия обороны при устранении проблем с производительностью. Он мгновенно показывает, что происходит на вашем компьютере. SQL Server экземпляр без необходимости сложных запросов T-SQL или сторонних инструментов.

Этот инструмент отлично помогает быстро выявлять распространённые проблемы, такие как блокировка сеансов, запросы, загружающие процессор, чрезмерное выполнение запросов и узкие места ввода-вывода. Когда пользователи сообщают о медленной работе приложения или его отсутствии, Activity Monitor помогает определить, является ли причиной проблемы сервер базы данных.

Для администраторов баз данных, которые не работают с SQL Server Ежедневно Activity Monitor предоставляет доступную точку входа для понимания активности сервера. Даже опытные администраторы баз данных используют его в качестве своего инструмента.tarточка отсчета для проведения исследований эффективности.

1.3 Монитор активности и другие инструменты мониторинга

Хотя Activity Monitor и полезен, важно понимать, чем он отличается от других вариантов мониторинга:

Монитор активности против sp_WhoIsActive: Activity Monitor предоставляет графический интерфейс с несколькими панелями, а sp_WhoIsActive — это комплексная хранимая процедура, которая предоставляет более подробную информацию в едином наборе результатов. sp_WhoIsActive показывает конкретные типы ожидания, которые Activity Monitor группирует вместе, и предоставляет более подробную информацию о блокировках.

Монитор активности против sp_who2: Традиционная команда sp_who2 показывает базовую информацию о сеансе, но Activity Monitor идет дальше, отображая статистику ожидания, дорогостоящие запросы и метрики ввода-вывода в организованном, визуальном формате.

Мониторинг активности и сторонние инструменты: Коммерческие решения для мониторинга, такие как SolarWinds Database Performance Analyzer, предлагают отслеживание истории, оповещения и расширенную аналитику, которых нет в Activity Monitor. Однако Activity Monitor не требует дополнительных ресурсов.ost или установка.

1.4 Основные преимущества для администраторов баз данных

Activity Monitor обладает рядом преимуществ, которые делают его незаменимым инструментом администратора баз данных:

• Ноль Сost: Как встроенный SQL Server Функция Management Studio не требует лицензионных сборов или усилий по развертыванию.
• Мониторинг в реальном времени: Отслеживайте текущую активность сервера по мере ее возникновения с настраиваемыми интервалами обновления от 1 секунды до 1 часа.
• Комплексные действия: Щелкните правой кнопкой мыши по процессам, чтобы завершить сеансы, просмотреть сведения о запросе или запустить SQL Server Трассировки профилировщика — все из самого инструмента.
• Множественные перспективы: Просматривайте состояние сервера с разных сторон с помощью пяти специализированных панелей, каждая из которых посвящена определенным аспектам производительности.
• Быстрое устранение неполадок: Определите most типичные проблемы с производительностью устраняются в течение нескольких минут, что сокращает среднее время их решения.
• Низкий барьер для входа: Для эффективного использования инструмента не требуется никаких дополнительных знаний, хотя он более глубокий SQL Server экспертиза помогает с интерпретацией.

2. Получение Starс монитором активности

Прежде чем вы сможете эффективно использовать Activity Monitor, вам необходимо понять предварительные условия, требуемые разрешения и различные методы запуска этого инструмента.

2.1 Предварительные условия и системные требования

Использовать SQL Server Монитор активности, вам нужен SQL Server Management Studio (SSMS), установленная на локальном компьютере или на сервере Jump. Инструмент Activity Monitor был значительно переработан. SQL Server 2008, поэтому информация в этом руководстве применима к SQL Server 2008 и более поздние версии.

У вас должно быть сетевое подключение к SQL Server Экземпляр, который вы хотите отслеживать. Для Cloud-HostДля доступа к экземпляру баз данных ed обычно требуется VPN-подключение или правильно настроенные правила брандмауэра.

Activity Monitor работает со всеми версиями SQL Server, включая Express, Standard и Enterprise. Сам инструмент работает на клиентском компьютере в среде SSMS, поэтому ресурсы сервера потребляются только выполняемыми им запросами мониторинга.

2.2 Требуемые разрешения

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

2.2.1 Разрешение на просмотр состояния сервера

ПРОСМОТР СОСТОЯНИЯ СЕРВЕРА Разрешение — основное требование для использования Activity Monitor. Это разрешение на уровне сервера позволяет просматривать все активные процессы и связанные с ними метрики.

Чтобы предоставить это разрешение, администратор сервера может выполнить:

GRANT VIEW SERVER STATE TO [YourLoginName];

Без VIEW SERVER STATE Activity Monitor может открыться, но не отображать никаких данных ни в одной из своих панелей.

2.2.2 Разрешения на уровне базы данных

Для просмотра информации на панели ввода-вывода файлов данных необходимы дополнительные разрешения. В частности, необходимо иметь одну из следующих комбинаций:

• СОЗДАТЬ БАЗУ ДАННЫХ разрешение, или
• ИЗМЕНИТЬ ЛЮБУЮ БАЗУ ДАННЫХ разрешение, или
• Просмотреть любое определение разрешение

Эти разрешения должны быть объединены с ПРОСМОТР СОСТОЯНИЯ СЕРВЕРА для полной функциональности Мониторинга активности.

2.2.3 Устранение неполадок с разрешениями

Если Монитор активности открывается, но не показывает никаких данных, то проблема в разрешениях.ost Распространенная причина. Убедитесь, что вашему логину предоставлено право VIEW SERVER STATE на уровне сервера. Вы можете проверить свои права, выполнив команду:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

Найдите разрешение «VIEW SERVER STATE» в столбце permission_name. Если оно отсутствует, обратитесь к администратору базы данных, чтобы получить его.

2.3 Как открыть Activity Monitor в SSMS

SQL Server Management Studio предоставляет четыре различных способа запуска Activity Monitor, что обеспечивает вам гибкость в зависимости от предпочтений вашего рабочего процесса.

2.3.1 Способ 1: с панели инструментов

Самый быстрый способ открыть Activity Monitor — использовать значок на панели инструментов:

1. Подключитесь к вашему SQL Server экземпляр в SQL Server Студия управления.
2. Найдите значок «Монитор активности» на стандартной панели инструментов (он напоминает столбчатую диаграмму с зеленой кнопкой воспроизведения).
3. Щелкните значок, чтобы запустить Activity Monitor.

Этот метод является наиболее быстрым, если вы уже работаете в SSMS и вам нужно быстро проверить активность сервера.

2.3.2 Метод 2: из обозревателя объектов

Вы также можете запустить Activity Monitor непосредственно из Object Explorer:

1. В обозревателе объектов найдите SQL Server экземпляр, который вы хотите отслеживать.
2. Щелкните правой кнопкой мыши по имени экземпляра.
3. Выберите Мониторинг системы из контекстного меню.

Этот метод полезен при подключении к нескольким серверам, поскольку он гарантирует мониторинг нужного экземпляра.

2.3.3 Метод 3: Использование сочетания клавиш

Для пользователей, предпочитающих клавиатуру, SQL Server Management Studio предоставляет специальный ярлык:

1. Убедитесь, что окно SSMS активно и вы подключены к экземпляру.
2. Press Ctrl + другой + A.
3. Монитор активности откроется для текущего выбранного экземпляра в обозревателе объектов.

Обратите внимание, что Activity Monitor подключится к любому экземпляру сервера, выбранному вами в Object Explorer, поэтому перед использованием этого сочетания клавиш убедитесь, что вы выбрали правильный экземпляр.

2.3.4 Метод 4: Из меню параметров (StarКонфигурация tup)

Если вы часто используете Activity Monitor, вы можете настроить SSMS на его автоматический запуск при каждом запуске.tarт приложение:

1. In SQL Server Студия управления, перейдите к Инструменты -> Настройки.
2. В диалоговом окне «Параметры» разверните Окружающая среда, А затем выберите Стартап.
3. Из издания При запуске выпадающий список, выберите Откройте Обозреватель объектов и Монитор активности.
4. Выберите OK.

При следующем запуске SSMS и подключении к серверу Монитор активности откроется автоматически вместе с Обозревателем объектов.

3. Понимание панелей монитора активности

Монитор активности организует информацию на пяти расширяемых панелях, каждая из которых отображает разные аспекты активности сервера. Понимание того, что отображается на каждой панели, крайне важно для эффективного устранения неполадок.

3.1 Панель обзора

Панель обзора отображает четыре графика в реальном времени, которые дают вам быструю картину состояния вашего здоровья. SQL Server Например. Эти графики обновляются с настраиваемым интервалом и помогают вам быстро выявлять отклонения от нормы.

3.1.1 % процессорного времени

Этот график показывает процент времени, которое процессор тратит на выполнение не простаивающих потоков для SQL Server экземпляр на всех процессорах. Значение представляет SQL Serverзагрузка процессора, а не загрузка всего процессора сервера.

Если вы постоянно видите, что загрузка процессора составляет или близка к 100%, ваш сервер ограничен в ресурсах процессора. Это может указывать на неэффективные запросы, отсутствие индексов или недостаточную производительность оборудования. Используйте панель «Недавние дорогостоящие запросы», чтобы определить, какие запросы потребляют больше всего ресурсов.ost ЦПУ.

3.1.2 Ожидающие задачи

Эта метрика отображает количество задач, ожидающих освобождения ресурсов перед продолжением выполнения. Задачи могут ожидать ресурсов ЦП, ввода-вывода, памяти или блокировок.

Постоянно большое количество ожидающих задач указывает на конфликт ресурсов. Панель «Ожидания ресурсов» содержит более подробную информацию о типах ресурсов, вызывающих ожидание.

3.1.3 Ввод-вывод базы данных (МБ/с)

Этот график показывает скорость передачи данных между памятью и диском. Он учитывает как чтение, так и запись, измеряемую в мегабайтах в секунду.

Резкие скачки активности ввода-вывода в базе данных могут указывать на запросы, выполняющие сканирование больших таблиц, чрезмерную активность журналирования или операции с контрольными точками. Панель «Ввод-вывод файлов данных» отображает данные об активности ввода-вывода по базам данных и файлам.

3.1.4 Пакетных запросов/сек

Эта метрика представляет собой количество SQL Server Пакетов, полученных экземпляром в секунду. Пакет может представлять собой один или несколько операторов, отправленных вместе.

Это значение даёт представление об общей активности сервера. Резкое падение количества пакетных запросов в рабочее время может указывать на проблемы с подключением к приложению или проблемы, с которыми сталкивается пользователь.

3.1.5 Настройка интервалов обновления

Вы можете настроить частоту обновления данных Activity Monitor:

1. Щелкните правой кнопкой мыши в любом месте панели обзора.
2. Выберите Интервал обновления.
3. Выберите интервал из предопределенных значений: 1 секунда, 5 секунд, 10 секунд (по умолчанию), 30 секунд, 1 минута или 1 час.

Установка интервалов обновления менее 10 секунд увеличивает нагрузку на сервер при мониторинге. Для производственных систем с высокой нагрузкой рекомендуется использовать интервалы 30 секунд или более, чтобы минимизировать влияние.

3.2 Панель процессов

Панель «Процессы» отображает информацию о текущих сеансах на вашем компьютере. SQL Server Эта панель крайне важна для определения того, кто что делает, и выявления блокировок.

3.2.1 Понимание информации о процессе

Каждая строка на панели «Процессы» представляет собой активный сеанс на сервере. На панели отображаются сеансы всех баз данных и всех пользователей, что даёт полное представление об активности сервера.

Отображаемая информация включает имя пользователя, имя приложения, часostИмя, имя базы данных, к которой осуществляется доступ, и текущая команда. Это помогает сопоставлять активность базы данных с конкретными пользователями или приложениями.

3.2.2 Объяснение ключевых столбцов

Понимание ключевых столбцов поможет вам эффективно интерпретировать информацию о процессе:

• Идентификатор сессии: Уникальный идентификатор для каждого соединения. Системные процессы используют отрицательные идентификаторы сеансов.
• Пользовательский процесс: Указывает, является ли это сеансом пользователя (Да) или системным процессом (Нет).
• Вход: SQL Server логин или учетная запись Windows, связанная с сеансом.
• База данных: Текущий контекст базы данных для сеанса.
• Состояние задачи: Показывает, в каком состоянии в данный момент находится сеанс (РАБОТАЕТ, ПРИОСТАНОВЛЕН, СПИТ и т. д.).
• Команда: Тип выполняемой команды (SELECT, INSERT, UPDATE и т. д.).
• Применение: Имя приложения, создавшего соединение.
• Время ожидания: Как долго (в миллисекундах) сеанс ожидает ресурсы.
• Тип ожидания: Конкретный тип ресурса, которого ожидает сеанс.
• Время ЦП: Общее время ЦП, использованное этим сеансом с момента его подключения.
• Использование памяти: Объем памяти (в КБ), выделенный в данный момент сеансу.

3.2.3 Процессы фильтрации и сортировки

Панель «Процессы» включает в себя мощные возможности фильтрации, которые помогут вам сосредоточиться на соответствующих сеансах:

1. Щелкните стрелку раскрывающегося списка в заголовке любого столбца.
2. Фильтр показывает доступные значения для этого столбца, включая Все, Пробелы и NonBlanks.
3. Выберите конкретные значения, чтобы отфильтровать отображение только этих сеансов.

Например, вы можете фильтровать Состояние задачи чтобы показать только ТЕКУЩИЕ сеансы или фильтровать База данных для просмотра активности в отношении определенной базы данных.

Вы также можете сортировать по любому столбцу, щёлкнув по его заголовку. Щёлкните один раз для сортировки по возрастанию, два раза — по убыванию.

3.2.4 Определение блокирующих и заблокированных сеансов

Панель «Процессы» помогает определить сценарии блокировки, когда один сеанс препятствует продолжению работы других сеансов:

• Заблокировано: Показывает идентификатор сеанса, блокирующего данный сеанс. Если этот столбец содержит значение, сеанс ожидает блокировки, установленной другим сеансом.
• Блокиратор головы: Отображает «1», если этот сеанс блокирует другие сеансы, но сам не заблокирован. Это основная причина цепочки блокировок.

Чтобы исследовать проблему блокировки, сначала определите блокировщик (сеанс, отмеченный цифрой «1» в столбце «Блокировщик»), затем изучите, что он делает, и решите, следует ли позволить ему завершиться или прекратить его.

3.2.5 Действия процесса (Уничтожение, Подробности, Трассировка)

Монитор активности позволяет вам выполнять действия в отдельных сеансах:

1. Щелкните правой кнопкой мыши любой сеанс на панели «Процессы».
2. Вы увидите несколько вариантов:
   • Детали: Показывает последнюю команду, выполненную в этом сеансе.
   • Процесс уничтожения: Завершает сеанс (использовать с осторожностью).
   • Отследить процесс в SQL Server Профайлер: Запуски SQL Server Profiler и автоматически фильтрует, чтобы показать только активность этого сеанса.

Параметр «Подробности» показывает текст команды, но учтите, что это последний Команда выполнена — возможно, она ещё не запущена. Функция трассировки особенно полезна, когда нужно просмотреть полную последовательность команд, выполняемых в сеансе.

3.3 Панель ожидания ресурсов

Панель «Ожидания ресурсов» суммирует статистику ожидания, показывая, какие типы ресурсов ожидают сеансы.ost Часто. Эта информация критически важна для диагностики узких мест в производительности.

3.3.1 Понимание статистики ожидания

После появления SQL Server Невозможно немедленно удовлетворить запрос на ресурс (например, блокировку, процессорное время или память), запрашивающая задача переходит в состояние ожидания. Статистика ожидания отслеживает эти периоды ожидания и помогает понять, на чём сервер тратит время, ожидая вместо того, чтобы работать.

Панель «Ожидания ресурсов» собирает данные из системных динамических представлений управления, таких как sys.dm_os_wait_stats и sys.dm_exec_requests. На каждом интервале обновления она вычисляет разницу между текущим и предыдущим снимками, показывая скорость накопления для каждого типа ожидания.

3.3.2 Категории ожидания

Activity Monitor группирует сотни отдельных типов ожидания в более широкие категории для упрощения интерпретации:

• CPU : Задачи, ожидающие освобождения процессорного времени.
• Буферная защелка: Ожидание кратковременных объектов синхронизации, защищающих доступ к страницам данных в памяти. Эта категория включает в себя ожидание блокировки страниц (PAGELATCH_*).
• Блокировка: Ожидания, вызванные сеансами, удерживающими блокировки, необходимые другим сеансам.
• Память: Ожидает выделения памяти, необходимой для таких операций, как сортировка и хеширование.
• Сетевой ввод/вывод: Ожидает отправки данных клиентам или получения данных от клиентов.
• SQL CLR: Ожидания, связанные с выполнением Common Language Runtime.

Хотя такая группировка упрощает представление, она также скрывает важные детали. Например, «Буферная защелка» может объединять ожидания PAGELATCH_SH, PAGELATCH_UP и PAGELATCH_EX, которые по-разному влияют на производительность.

3.3.3 Интерпретация времени ожидания и задач ожидания

На панели «Ожидания ресурсов» отображаются две ключевые метрики для каждой категории ожидания:

• Общее время ожидания (мс): Общее количество миллисекунд, накопленных за текущий интервал обновления для этой категории ожидания.
• Ожидающие задачи: Количество задач, которые в данный момент ждут ресурсов в этой категории.

Значение времени ожидания особенно интересно. Если интервал обновления составляет 10 секунд, а время ожидания для категории составляет 20 000 мс, это указывает на несколько одновременных ожиданий (20 000 мс / 10 000 мс = среднее значение двух одновременных ожиданий в течение интервала).

3.3.4 Выявление узких мест производительности

Используйте панель «Ожидание ресурсов», чтобы определить, где ваш сервер тратит ресурсы.ost время ожидания:

1. Разверните панель «Ожидания ресурсов».
2. Обратите внимание на категории ожидания, в которых наблюдается наибольшее время ожидания.
3. Сортировать по: Общее время ожидания чтобы увидеть, какие ресурсы most сдерживается.

Высокие значения ожидания защелки буфера часто указывают на конфликт за доступ к страницам данных в памяти, что может указывать на узкие места ввода-вывода или конфликт в базе данных tempdb. Высокие значения ожидания блокировки указывают на проблемы с блокировкой. Высокие значения ожидания памяти указывают на нехватку выделенной памяти для выполнения запросов.

3.4 Панель ввода-вывода файла данных

Панель ввода-вывода файлов данных отображает активность диска для каждого файла базы данных на сервере, помогая выявить узкие места ввода-вывода и понять закономерности использования диска.

3.4.1 Понимание метрик ввода-вывода

Панель ввода-вывода файлов данных отображает несколько показателей для каждого файла базы данных:

• База данных: Имя базы данных.
• Тип файла: Либо Данные (включая таблицы и индексы), либо Журнал (журнал транзакций).
• Логическое имя: Логическое имя файла, как определено в SQL Server.
• МБ/сек Чтение: Скорость чтения данных из этого файла.
• МБ/сек Написано: Скорость записи данных в этот файл.
• Время отклика (мс): Среднее время отклика для операций ввода-вывода для этого файла.

Эти показатели обновляются с тем же интервалом, что и панель обзора, что позволяет вам в режиме реального времени отслеживать активность диска.

3.4.2 Выявление узких мест ввода-вывода

Обратите внимание на эти закономерности, указывающие на проблемы с производительностью ввода-вывода:

• Высокое время отклика: Время отклика, постоянно превышающее 15–20 мс, указывает на медленную работу дисковых подсистем. Время отклика более 50 мс указывает на серьёзные узкие места ввода-вывода.
• Несбалансированная нагрузка: Если один файл данных показывает значительно более высокую скорость ввода-вывода, чем другие в той же базе данных, вы можете выиграть от добавления дополнительных файлов для распределения нагрузки.
• Чрезмерная активность Tempdb: Высокие показатели ввода-вывода для файлов tempdb часто указывают на то, что запросы создают большие промежуточные наборы результатов или используют неэффективные планы выполнения.

3.4.3 Анализ файла базы данных

Используйте панель ввода-вывода файлов данных, чтобы понять, как ваши базы данных используют дисковые ресурсы:

1. Разверните панель «Ввод/вывод файла данных».
2. Сортировать по: МБ/сек Чтение or МБ/сек Написано чтобы идентифицировать мost активные файлы.
3. Обратите внимание на все файлы с постоянно высокой активностью или длительным временем отклика.
4. Сопоставьте эту информацию с панелью «Недавние дорогостоящие запросы», чтобы определить, какие запросы создают нагрузку ввода-вывода.

3.5 Панель недавних дорогостоящих запросов

Панель «Недавние дорогостоящие запросы» часто являетсяost Полезная панель для устранения неполадок производительности приложений. Она показывает запросы, потребляющие значительные ресурсы сервера, помогая выявить возможности оптимизации.

3.5.1 Понимание метрик запроса

Activity Monitor отображает несколько показателей для каждого дорогостоящего запроса:

• Выполнений/мин: Сколько раз запрос был выполнен за последнюю минуту.
• Процессор (мс/сек): Время ЦП, потребляемое этим запросом в секунду.
• Физических чтений/сек: Количество операций чтения физического диска в секунду для этого запроса.
• Логических записей/сек: Количество логических записей (в буферный кеш) в секунду.
• Логических чтений/сек: Количество логических чтений (из буферного кеша) в секунду.
• Средняя продолжительность (мс): Среднее время выполнения этого запроса.
• Количество планов: Количество планов выполнения в кэше для этого запроса.

Эти показатели помогают вам понять не только, какие запросы являются дорогостоящими, но и почему они дорогие и как часто они работают.

3.5.2 Параметры сортировки

Вы можете сортировать панель «Недавние дорогостоящие запросы» по различным показателям, чтобы обнаружить разные типы проблем:

1. Щелкните заголовок любого столбца, чтобы выполнить сортировку по этому показателю.
2. Распространенные стратегии сортировки включают в себя:
   • Сортировать по ЦП: Найти запросы, потребляющие most процессорное время.
   • Сортировать по количеству казней/мин: Определите запросы, которые выполняются слишком часто.
   • Сортировать по количеству прочтений: Найти запросы, вызывающие мost дисковый ввод-вывод.
   • Сортировать по средней продолжительности: Найдите длительно выполняемые запросы.

При устранении проблем с производительностью попробуйте сортировать данные по нескольким столбцам, чтобы получить разные результаты. Запрос с умеренной загрузкой ЦП, но чрезвычайно высоким числом выполнений в минуту, может быть причиной вашей проблемы.

3.5.3 Просмотр текста запроса

Чтобы увидеть фактический оператор SQL, лежащий в основе дорогостоящего запроса:

1. Щелкните правой кнопкой мыши строку запроса на панели «Недавние дорогостоящие запросы».
2. Выберите Редактировать текст запроса.
   
3. Откроется новое окно запроса, отображающее полный оператор SQL.
   

Это позволяет изучить логику запроса и выявить потенциальные возможности оптимизации. Затем вы можете скопировать текст запроса для тестирования изменённых версий.

3.5.4 Анализ планов выполнения

Планы выполнения покажут вам, как SQL Server выполняет запрос, выявляя неэффективность, такую ​​как отсутствующие индексы или неподходящие типы соединений:

1. Щелкните правой кнопкой мыши строку запроса на панели «Недавние дорогостоящие запросы».
2. Выберите Показать план выполнения.
   
3. SQL Server Management Studio отображает графическое представление выполнения запроса.
   

Найдите операции, которые занимают большой процент времени запроса.ost, предупреждения об отсутствующей статистике или индексах, а также неожиданные операции сканирования таблиц. Они часто указывают на то, на чём следует сосредоточить усилия по оптимизации.

3.5.5 Выявление проблемных запросов

Обратите внимание на следующие закономерности на панели «Недавние дорогостоящие запросы»:

• Чрезмерные казни: Запрос, выполняемый тысячи раз в минуту, может указывать на проблему запроса N+1, когда код приложения обращается к базе данных внутри цикла.
• Высокие физические показатели: Запросы с высокой скоростью физического чтения часто обращаются к диску, что свидетельствует об отсутствии индексов или плохо написанных запросах.
• Высокая загрузка ЦП при низкой продолжительности: Множество быстрых запросов, потребляющих в совокупности много ресурсов ЦП, могут повлиять на производительность сервера так же, как и несколько медленных запросов.
• Количество планов: Запросы со множеством планов выполнения могут страдать от проблем с перехватом параметров или непараметризованных запросов, приводящих к раздуванию кэша планов.

4. Использование Activity Monitor для устранения неполадок производительности

Мониторинг активности действительно работает, когда вы используете его систематически для диагностики и устранения проблем с производительностью. В этом разделе рассматриваются распространённые сценарии устранения неполадок и способы их решения.

4.1 Диагностика чрезмерного выполнения запросов

Один из нихost Распространенной проблемой производительности является то, что запросы выполняются гораздо чаще, чем необходимо, что часто вызвано проблемами проектирования приложения.

4.1.1 Выявление повторяющихся запросов

Чтобы обнаружить запросы, которые выполняются слишком часто:

1. Откройте «Монитор активности» и разверните Недавние дорогие запросы панель.
2. Сортировать по: Казни/мин (число выполнений в минуту).
3. Обратите внимание на запросы вверху, количество выполнений которых кажется неоправданно высоким.
4. Щелкните правой кнопкой мыши по подозрительному запросу и выберите Редактировать текст запроса для проверки оператора SQL.

Например, если вы видите, что простой оператор SELECT выполняется 37 000 раз в минуту, задайте себе вопрос, действительно ли приложению нужно так часто вызывать этот запрос.ost запросы, выполняемые более нескольких тысяч раз в минуту, требуют расследования.

4.1.2 Анализ первопричин

Избыточное выполнение запросов обычно возникает из-за следующих проблем:

• Задача запроса N+1: Код приложения извлекает список элементов, а затем выполняет отдельный запрос для каждого элемента, чтобы получить связанные данные. Это создаёт N дополнительных запросов, где N — количество элементов.
• Отсутствует кэширование: Приложение запрашивает в базе данных данные, которые rarely изменяет вместо того, чтобы кэшировать его в памяти приложения.
• Циклы опроса: Код многократно запрашивает базу данных, проверяя изменения состояния, вместо того чтобы использовать уведомления об изменениях или очереди сообщений.
• Неэффективность ОРМ: Entity Framework и аналогичные инструменты иногда генерируют неэффективные шаблоны запросов, когда разработчики не понимают, как их код транслируется в SQL.

Чтобы определить первопричину, проследите запрос до кода приложения. Обратите внимание на Область применения и Логин Столбцы на панели «Процессы» при выполнении запроса. Вы также можете щелкнуть правой кнопкой мыши процесс и выбрать Отследить процесс в SQL Server Profiler чтобы увидеть схему вызова.

4.1.3 Решения и передовой опыт

После того как вы выявили чрезмерное выполнение запросов, рассмотрите следующие решения:

• Пакетная обработка: Измените код приложения для извлечения нескольких элементов в одном запросе с использованием объединений или предложений IN вместо выполнения отдельных запросов в цикле.
• Кэширование результатов: Кэшируйте часто используемые, но редко изменяемые данные в памяти приложения с соответствующими сроками действия.
• Жажда загрузки: Настройте ORM для использования стратегий активной загрузки, которые извлекают связанные данные за меньшее количество более эффективных запросов.
• Параметризация запроса: Убедитесь, что запросы используют параметры, а не конкатенацию значений, что улучшает повторное использование кэша планов и снижает накладные расходы на компиляцию.

4.2 Исследование проблем блокировки

Блокировка происходит, когда один сеанс блокирует другие сеансы, препятствуя их продолжению. Это проявляется в медленном отклике приложения и недовольстве пользователей.

4.2.1 Определение цепочек блоков

Для обнаружения и анализа блокировки:

1. Откройте «Монитор активности» и разверните Процессы панель.
2. Найдите сеансы со значениями в Заблокировано столбец — они ожидают блокировок, удерживаемых другими сеансами.
3. Найти сеансы с «1» в Блокировщик головы столбец — это основная причина блокировок цепочек.
4. Обратите внимание ID сессии головного блокировщика.
5. Щелкните правой кнопкой мыши по сеансу блокировки головы и выберите Описание чтобы увидеть, какую команду он выполняет.

Понимание цепочки блоков критически важно. Блокировщиком является именно тот сеанс, который нужно исследовать, а не заблокированные сеансы ниже по цепочке.

4.2.2 Понимание типов блокировок

Тип ожидания Столбец на панели «Процессы» указывает, какой тип блокировки ожидают заблокированные сеансы:

• LCK_M_X: Ожидание исключительной блокировки, обычно вызываемое операциями UPDATE, DELETE или INSERT.
• ЛКК_М_С: Ожидание общей блокировки, обычно операторы SELECT ждут снятия исключительной блокировки.
• LCK_M_U: Ожидание блокировки обновления — промежуточный тип блокировки, используемый во время обновлений.
• LCK_M_IX: Ожидание исключительной блокировки, указывающее на конфликт блокировки на уровне страницы или строки.

Ожидание ресурса столбец показывает, какой объект базы данных заблокирован, помогая понять, какая таблица или индекс вовлечены в конфликт.

4.2.3 Решение проблем блокировки

После того как вы определили блокирующий сеанс и его природу, у вас есть несколько вариантов действий:

1. Дождитесь завершения: Если блокировщик головной части выполняет законный запрос, который скоро завершится, лучше всего дать ему завершиться естественным образом.
2. Убить сессию: Если блокировщик головок завис или выполняет запрос, который следует отменить:
   • Щелкните правой кнопкой мыши сеанс на панели «Процессы».
   • Выберите Завершить процесс.
   • Подтвердите действие в диалоговом окне.
3. Оптимизация запросов: Если блокировка повторяется при тех же запросах, оптимизируйте их, чтобы сократить продолжительность блокировки.
4. Отрегулируйте уровни изоляции: Рассмотрите возможность использования READ COMMITTED SNAPSHOT ISOLATION для уменьшения блокировки при рабочих нагрузках с интенсивным чтением.
5. Настройка индекса: Добавьте индексы для ускорения запросов и сокращения времени удержания блокировок.

4.3 Анализ высокой загрузки ЦП

Если на панели «Обзор» время процессора постоянно отображается на уровне или близком к 100%, необходимо определить, какие запросы вызывают эту проблему, и решить, можно ли их оптимизировать.

4.3.1 Выявление запросов, интенсивно использующих процессор

Чтобы найти запросы, потребляющие слишком много ресурсов процессора:

1. Откройте приложение Недавние дорогие запросы панель.
2. Сортировать по: ЦП (мс/сек) для отображения запросов с использованием most Процессорное время.
3. Изучите самые популярные запросы в списке.
4. Щелкните правой кнопкой мыши по запросам с высокой загрузкой ЦП и выберите Редактировать текст запроса для просмотра оператора SQL.
5. Выберите Показать план выполнения чтобы понять, как выполняется запрос.

Обращайте внимание не только на использование процессора отдельными запросами, но и на Казни/мин колонка. Запрос, использующий умеренное количество ресурсов процессора на одно выполнение, но выполняемый тысячи раз в минуту, может быть самым большим потребителем ресурсов процессора.

4.3.2 Методы оптимизации запросов

Распространенные подходы к снижению загрузки ЦП включают:

• Добавить отсутствующие индексы: Поиск индексов потребляет гораздо меньше ресурсов процессора, чем сканирование таблиц. Обратите внимание на отсутствующие рекомендации по индексам в планах выполнения.
• Перепишите неэффективные запросы: Замените курсоры операциями на основе множеств, исключите ненужные функции в предложениях WHERE и удалите избыточные соединения.
• Обновление статистики: Устаревшие статистические данные вызывают SQL Server для выбора неэффективных планов выполнения. Выполните команду UPDATE STATISTICS для затронутых таблиц.
• Уменьшить объем данных: Добавьте предложения WHERE для предварительной фильтрации данных, используйте TOP или OFFSET/FETCH для разбиения на страницы и избегайте SELECT *.
• Исправление перехвата параметров: Используйте OPTION (RECOMPILE), подсказки запросов или руководства по плану, если при анализе параметров возникают проблемы.

4.4 Исследование проблем с памятью

Нехватка памяти может привести к переносу запросов на диск, что значительно снизит производительность. Монитор активности поможет вам обнаружить операции, интенсивно использующие память.

4.4.1 Понимание показателей памяти

Использование памяти Столбец на панели «Процессы» показывает объём памяти, выделенной каждому сеансу, в килобайтах. Высокий уровень использования памяти одним сеансом часто указывает на:

• Большие операции сортировки или хеширования, которые не помещаются в изначально выделенную память
• Запросы, возвращающие огромные наборы результатов
• Избыточный параллелизм, создающий множество копий операторов плана выполнения
• Утечки памяти в хранимых процедурах или функциях CLR

На панели «Ожидания ресурсов» может отображаться ожидание памяти, когда запросы не могут получить достаточно выделенной памяти и должны ждать, пока память станет доступной.

4.4.2 Выявление запросов, требующих большого объема памяти

Чтобы найти запросы, вызывающие нехватку памяти:

1. В Процессы панель, сортировать по Использование памяти чтобы увидеть сеансы, потребляющие мost Память.
2. Щелкните правой кнопкой мыши сеансы с высоким использованием памяти и выберите Описание для просмотра их запросов.
3. В Недавние дорогие запросы панель, найдите запросы с высоким Логические чтения or Логические записи, поскольку они часто коррелируют с использованием памяти.
4. Изучите планы выполнения операторов сортировки и хэширования, которые используют выделение памяти.

Запросы, в которых в планах выполнения отображаются предупреждения «Предоставление памяти» или предупреждения о переполнении, указывают на проблемы с нехваткой памяти.

4.5 Обнаружение проблем с производительностью приложений

Когда пользователи сообщают о медленном времени отклика приложений, Activity Monitor помогает определить, является ли база данных узким местом.

4.5.1 Сопоставление монитора активности с проблемами приложений

Чтобы исследовать медлительность приложения:

1. Обратите внимание на точное время, когда пользователи сообщают о проблемах, и на затронутые ими приложения.
2. Откройте Мониторинг активности и проверьте Обзор панель для отображения скачков ресурсов в то время.
3. В Процессы панель, фильтр по Область применения чтобы отображались только соединения из затронутого приложения.
4. Ищите высокие Время ожидания значения, указывающие на задержки в работе базы данных.
5. Проверить Недавние дорогие запросы панель для запросов из этого приложения, потребляющего значительные ресурсы.

Если база данных не проявляет необычной активности, а пользователи сталкиваются с замедлением, проблема, скорее всего, кроется в коде приложения, задержке сети или производительности на стороне клиента.

4.5.2 Выявление неэффективных шаблонов приложений

Activity Monitor выявляет несколько антипаттернов в дизайне приложений:

• Приложения Chatty: Множество небольших запросов вместо меньшего количества более эффективных. Это определяется большим количеством подключений и большим количеством простых запросов в списке «Недавние дорогостоящие запросы».
• N+1 запросов: Один запрос, за которым следует N дополнительных запросов связанных данных. Отображается как простой запрос с чрезвычайно высокой частотой выполнения в минуту.
• Большие наборы результатов: Приложения, извлекающие гораздо больше данных, чем необходимо. Обратите внимание на высокие Логические чтения в сочетании с простыми запросами SELECT *.
• Отсутствующие тайм-ауты: Приложения, не устанавливающие тайм-ауты команд, могут оставлять соединения открытыми на неопределенное время, что отображается как длительные сеансы на панели «Процессы».

5. Альтернативные методы: получение данных Activity Monitor через T-SQL

Хотя Activity Monitor предоставляет удобный графический интерфейс, иногда вам необходимо получить эквивалентную информацию программным способом или создать индивидуальные решения для мониторинга.

5.1 Использование динамических управленческих представлений (DMV)

SQL Server предоставляет информацию об активности через динамические представления управления, которые Activity Monitor опрашивает в фоновом режиме.

5.1.1 Ключевые DMV для мониторинга активности

Мost Важные DMV для репликации функциональности Activity Monitor включают:

• sys.dm_exec_requests: Показывает текущие выполняемые запросы с информацией о ЦП, вводе-выводе и ожидании.
• sys.dm_exec_sessions: Содержит информацию на уровне сеанса, такую ​​как имя пользователя, host имя и имя программы.
• sys.dm_os_wait_stats: Предоставляет кумулятивную статистику ожидания для всего экземпляра.
• sys.dm_exec_query_stats: Содержит обобщенную статистику производительности кэшированных запросов.
• sys.dm_io_virtual_file_stats: Возвращает статистику ввода-вывода для файлов данных и журналов.
• sys.dm_exec_sql_text: Извлекает текст SQL для заданного sql_handle или plan_handle.
• sys.dm_exec_query_plan: Возвращает план выполнения кэшированного запроса.

5.1.2 Примеры запросов на получение информации о процессе

Чтобы воспроизвести функциональность панели «Процессы», вы можете выполнить запрос:

SELECT 
    s.session_id AS [Session ID],
    CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
    s.login_name AS [Login],
    ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), '') AS [Database],
    ISNULL(t.task_state, '') AS [Task State],
    ISNULL(r.command, '') AS [Command],
    r.cpu_time AS [CPU Time],
    r.total_elapsed_time AS [Elapsed Time],
    r.wait_time AS [Wait Time],
    r.wait_type AS [Wait Type],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

5.1.3 Примеры запросов для статистики ожидания

Чтобы просмотреть статистику ожидания, аналогичную панели «Ожидания ресурсов»:

SELECT TOP 10
    wait_type AS [Wait Type],
    wait_time_ms / 1000.0 AS [Wait Time (sec)],
    waiting_tasks_count AS [Waiting Tasks],
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
    AND wait_type NOT LIKE '%IDLE%'
    AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;

5.2 Использование sp_WhoIsActive

sp_WhoIsActive — мощная хранимая процедура, созданная сообществом, которая предоставляет более подробную информацию, чем Activity Monitor, в одном наборе результатов.

5.2.1 Установка sp_WhoIsActive

Чтобы установить sp_WhoIsActive:

1. Загрузите последнюю версию с http://whoisactive.com.
2. Загружаемый файл представляет собой скрипт SQL, содержащий определение процедуры.
3. Откройте скрипт в SQL Server Студия управления.
4. Подключитесь к вашему SQL Server пример.
5. Выполните скрипт для создания процедуры в основной базе данных.
6. Предоставьте разрешения на выполнение соответствующим пользователям.

Поскольку sp_WhoIsActive установлена ​​в master, она доступна из любого контекста базы данных.

5.2.2 Основные примеры использования

Самый простой способ использования sp_WhoIsActive:

EXEC sp_WhoIsActive;

Это возвращает набор результатов, в котором отображаются все активные сеансы с их запросами, типами ожидания, информацией о блокировках и использованием ресурсов.

Для 10-секундной выборки, показывающей активность за этот период:

EXEC sp_WhoIsActive @delta_interval = 10;

Это вычисляет дельты для таких показателей, как ЦП и чтение, показывая, что произошло за эти 10 секунд.

5.2.3 Расширенные параметры

sp_WhoIsActive поддерживает множество параметров для настройки:

• @фильтр: Фильтрация результатов по определенным сеансам, базам данных или логинам.
• @filter_type: Укажите, к чему применяется фильтр (сеанс, база данных, логин и т. д.).
• @get_plans: Включить планы выполнения в результаты (установите значение 1).
• @get_locks: Показать подробную информацию о блокировке (установите значение 1).
• @get_transaction_info: Отображение сведений о транзакции (установлено значение 1).
• @sort_order: Сортировать результаты по различным показателям (ЦП, чтения, длительность и т. д.).
• @destination_table: Вставьте результаты в таблицу для отслеживания истории.

Пример, показывающий планы, отсортированные по ЦП:

EXEC sp_WhoIsActive 
    @get_plans = 1,
    @sort_order = '[CPU] DESC';

5.3 Использование системных хранимых процедур

SQL Server включает в себя традиционные хранимые процедуры для мониторинга активности, хотя они предоставляют меньше информации, чем DMV или Activity Monitor.

5.3.1 sp_who и sp_who2

Процедура sp_who показывает основную информацию о сеансе:

EXEC sp_who;

Процедура sp_who2 предоставляет немного больше подробностей:

EXEC sp_who2;

Обе процедуры отображают идентификаторы сеансов, имена пользователей, время ЦП и информацию о блокировках. Однако им не хватает детализации, доступной через DMV или Activity Monitor. Они…ost полезно для быстрой проверки, когда вам быстро нужна минимальная информация.

5.3.2 Другие полезные системные процедуры

Дополнительные системные процедуры мониторинга включают:

• sp_lock: Показывает информацию о блокировках (устарело; вместо этого используйте sys.dm_tran_locks).
• sp_monitor: Отображает статистику о SQL Server деятельность.
• sp_help: Показывает определения объектов и метаданные.
• DBCC SQLPERF: Отображает статистику использования пространства журнала транзакций и ожидания.

5.4 Создание пользовательских сценариев мониторинга

Для сред, требующих особого мониторинга, выходящего за рамки возможностей Activity Monitor, вы можете создавать индивидуальные решения с использованием DMV.

5.4.1 Полный эквивалентный сценарий Activity Monitor

Вот полный сценарий, который повторяет мost Функциональность Монитора активности:

-- Processes Information
SELECT 
    s.session_id AS [Session ID],
    CONVERT(CHAR(1), s.is_user_process) AS [User Process],
    s.login_name AS [Login],
    ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), N'') AS [Database],
    ISNULL(t.task_state, N'') AS [Task State],
    ISNULL(r.command, N'') AS [Command],
    SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
        ((CASE r.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE r.statement_end_offset 
        END - r.statement_start_offset) / 2) + 1) AS [Statement],
    st.text AS [Command Text],
    r.cpu_time AS [CPU Time (ms)],
    r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
    r.wait_time AS [Wait Time (ms)],
    r.wait_type AS [Wait Type],
    r.wait_resource AS [Wait Resource],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    c.client_net_address AS [Net Address],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id 
    AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

-- Recent Expensive Queries
SELECT TOP 20
    qs.execution_count / 
        DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
    qs.total_worker_time / 1000 AS [CPU Time (ms)],
    qs.total_physical_reads AS [Physical Reads],
    qs.total_logical_writes AS [Logical Writes],
    qs.total_logical_reads AS [Logical Reads],
    qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
    SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset 
        END - qs.statement_start_offset) / 2) + 1) AS [Query Text]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;

5.4.2 Автоматизация мониторинга с помощью заданий SQL Agent

Вы можете запланировать пользовательские сценарии мониторинга, используя SQL Server Агент:

1. Создайте таблицу для хранения результатов мониторинга.
2. Измените свой скрипт мониторинга, чтобы вставить результаты в эту таблицу.
3. In SQL Server Студия управления, развернуть SQL Server Агент в обозревателе объектов.
4. Щелкните правой кнопкой мыши Вакансии и Новая работа.
5. Настройте задание для запуска скрипта мониторинга через регулярные промежутки времени.
6. Настройте оповещения или отчеты на основе собранных данных.

Такой подход позволяет отслеживать историю и анализировать тенденции, чего не может сделать Activity Monitor.

6. Ограничения и рекомендации по использованию монитора активности

Хотя Activity Monitor и полезен, понимание его ограничений поможет вам использовать его правильно и при необходимости дополнять другими инструментами.

6.1 Понимание накладных расходов Activity Monitor

Activity Monitor не бесплатен — он потребляет ресурсы сервера для сбора и отображения информации. Понимание этих дополнительных затрат поможет вам использовать его ответственно.

6.1.1 Влияние на ресурсы сервера

Монитор активности выполняет запросы к системным динамическим административным представлениям при каждом обновлении. Эти запросы потребляют ресурсы процессора, генерируют логические чтения и могут кратковременно блокировать системные таблицы. На загруженных серверах эти накладные расходы могут снизить производительность.

Панели «Процессы» и «Недавние дорогостоящие запросы» особенно ресурсоёмки, поскольку они должны сканировать потенциально большие динамические управленческие представления (DMV) и таблицы кэша. На серверах с тысячами кэшированных планов запросов обновление раздела «Недавние дорогостоящие запросы» может занять несколько секунд.

В документации Microsoft предупреждается, что интервалы обновления менее 10 секунд могут заметно повлиять на производительность сервера, особенно на уже загруженных системах.

6.1.2 Рекомендации по интервалу обновления

Выберите интервалы обновления, соответствующие вашей ситуации:

• 1-5 секунды: Только для немедленного устранения критических проблем на серверах с низкой нагрузкой. Не оставляйте Activity Monitor запущенным с такими интервалами.
• 10 секунд (по умолчанию): Разумно для мost сценарии устранения неполадок и общий мониторинг.
• 30-60 секунды: Лучший выбор для производственных серверов, работающих под большой нагрузкой или при мониторинге в течение длительных периодов времени.
• Только ручное обновление: Для ситуаций, когда вы хотите периодически проверять текущее состояние без непрерывного опроса.

Всегда закрывайте «Мониторинг системы» после завершения исследования. Не оставляйте его работать постоянно, особенно если запущено несколько экземпляров от разных пользователей.

6.2 Проблемы группировки типов ожидания

Подход Activity Monitor к категоризации ожиданий, хотя и упрощает представление, может скрывать важную диагностику.ostic информация.

6.2.1 Как группы мониторинга активности ожидают

SQL Server Монитор активности отслеживает сотни различных типов ожидания, каждый из которых указывает на определённый ресурс или состояние. Он группирует их в общие категории, такие как «Буферная защёлка», «Блокировка» и «Память».

Например, категория «Буферная защелка» включает PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX и несколько других типов ожидания. Хотя все они связаны с доступом к страницам, у них разные причины и решения.

Microsoft не документирует точно, какие типы ожидания соответствуют тем или иным категориям, что затрудняет понимание того, что вы на самом деле видите.

6.2.2 Отсутствующие типы ожидания

Монитор активности не отображает все типы ожидания. Most В частности, он часто пропускает ожидания CXPACKET, которые указывают на параллельное выполнение запросов. Ожидания CXPACKET встречаются часто и обычно не создают проблем, но их наличие помогает понять характеристики рабочей нагрузки.

Когда Activity Monitor показывает «Buffer Latch» как наиболее вероятное ожидание, а другие инструменты показывают, что доминирует CXPACKET, расхождение возникает из-за логики фильтрации и группировки Activity Monitor.

6.2.3 Почему важны определенные типы ожидания

Знание конкретного типа ожидания важно для устранения неполадок:

• PAGELATCH_EX: Часто указывает на конфликт в базе данных tempdb на страницах выделения памяти. Решение заключается в добавлении дополнительных файлов данных tempdb.
• PAGELATCH_SH: Может указывать на наличие горячих страниц в пользовательских таблицах. Решение включает в себя секционирование или реорганизацию индекса.
• PAGELATCH_UP: Часто встречается во время обновлений. Может указывать на нормальную работу, а не на проблему.

Монитор активности объединяет все эти проблемы в категорию «Буферная блокировка», что затрудняет диагностику. Такие инструменты, как sp_WhoIsActive и запросы DMV, показывают конкретные типы ожидания.

6.3 Точность и актуальность данных

Activity Monitor предоставляет данные практически в режиме реального времени, но «практически» — ключевое слово. Понимание метода сбора данных поможет вам правильно интерпретировать результаты.

6.3.1 Моментальный снимок против непрерывного мониторинга

Монитор активности отображает моментальные снимки, сделанные при каждом обновлении. События, происходящие между снимками, не фиксируются. Если запрос выполняется в течение 2 секунд, а обновление происходит каждые 10 секунд, вы можете увидеть его один раз или не увидеть вообще, в зависимости от времени.

Это означает, что Activity Monitor отлично справляется с обнаружением постоянных проблем (блокировки в течение нескольких минут, постоянной высокой загрузки ЦП), но может пропускать временные проблемы (кратковременные взаимоблокировки, случайные всплески запросов).

6.3.2 Агрегация и выборка

В области «Недавние дорогостоящие запросы» отображаются данные, агрегированные с момента попадания планов запросов в кэш. Два одинаковых запроса с разными значениями параметров отображаются в одной строке, если у них общий план. Такое агрегирование может скрывать проблемы с определенными комбинациями параметров (проблемы отслеживания параметров).

Панель «Ожидания ресурсов» рассчитывает показатели, сравнивая снимки. Если статистика ожидания сбрасывается между снимками (rarе. но это возможно), рассчитанные ставки могут быть неверными.

6.4 Когда НЕ следует использовать Монитор активности

Activity Monitor подходит не для всех сценариев мониторинга. Узнайте, когда альтернативные инструменты могут быть более предпочтительным выбором.

6.4.1 Требования к историческому анализу

Монитор активности отображает только текущую или недавнюю активность. Он не хранит исторические данные. Если вам нужно анализировать тенденции за несколько дней или недель, сравнивать текущую производительность с базовыми показателями или создавать отчёты о закономерностях производительности, Монитор активности не подойдёт.

Для исторического анализа используйте SQL ServerВстроенная панель мониторинга производительности, расширенные события с файлом tarполучает или сторонние решения для мониторинга.

6.4.2. Необходима подробная статистика ожидания

Если вам нужна точная информация о типах ожидания для расширенной настройки, группировка и фильтрация Activity Monitor неэффективны. Используйте запросы DMV напрямую или sp_WhoIsActive.

Для комплексного анализа статистики ожидания выполните прямой запрос к sys.dm_os_wait_stats и вручную отфильтруйте неопасные ожидания.

6.4.3 Рекомендации по выбору производственного сервера

На производственных серверах с высокой нагрузкой использование Activity Monitor может привести к проблемам. Нескольким администраторам баз данных не следует одновременно запускать Activity Monitor на одном сервере.

Для мониторинга производства рассмотрите облегченные альтернативы, такие как запланированные снимки DMV, сохраняемые в базе данных мониторинга, или используйте маршрутизацию только для чтения для мониторинга вторичных реплик в конфигурациях Always On.

7. Рекомендации по использованию Activity Monitor

Соблюдение передовых практик позволит вам получить максимальную выгоду от Activity Monitor, минимизируя при этом негативное воздействие на ваши серверы.

7.1 Когда использовать Монитор активности

Монитор активности отлично подходит для определённых сценариев. Используйте его, когда его возможности соответствуют вашим потребностям.

7.1.1 Проблемы производительности в реальном времени

Функция «Мониторинг активности» идеально подходит, когда у пользователей возникают проблемы и вам необходимо немедленно их диагностировать. Просмотр в режиме реального времени помогает увидеть, что происходит прямо сейчас.

Когда вы получаете сообщение о том, что приложение работает медленно, одним из первых шагов должно быть открытие «Монитор активности». Это позволит быстро определить, занята ли база данных, заблокирована она или простаивает.

7.1.2 Исследование замедления работы приложения

Если определённое приложение перестаёт отвечать, функция «Мониторинг активности» поможет определить, связаны ли проблемы с базой данных. Отфильтруйте данные на панели «Процессы» по имени приложения, чтобы увидеть активность базы данных только этого приложения.

Если приложение не проявляет активности в базе данных, несмотря на сообщения пользователей о проблемах, проблема кроется в другом месте. Если вы видите обширные блокировки или дорогостоящие запросы, вы нашли причину.

7.1.3 Быстрые проверки состояния здоровья

Activity Monitor — это отличная панель инструментов для быстрой проверки работоспособности во время планового администрирования. Откройте её, взгляните на обзорные графики и убедитесь, что всё в порядке.

Эта поверхностная проверка занимает всего несколько секунд и позволяет выявить проблемы до того, как они станут критическими. Сделайте её частью своей повседневной рутины.

7.2 Оптимальные настройки конфигурации

Правильная настройка Activity Monitor повышает как его полезность, так и потребление ресурсов.

7.2.1 Рекомендуемые интервалы обновления

Выберите интервал обновления в соответствии со своими целями:

• Активное устранение неполадок: 10 секунд обеспечивают хорошую реакцию при разумных накладных расходах.
• Расширенный мониторинг: 30–60 секунд снижают нагрузку на сервер при более длительных периодах наблюдения.
• Диагностика критической проблемы: 5 секунд дают высокую детализацию, когда каждая секунда имеет значение, но используйте ее недолго.
• Регулярные проверки здоровья: Обновление вручную (с интервалом в 1 час), когда вы не смотрите активно.

Не забудьте закрыть Мониторинг активности после завершения. Установка длительного интервала и полное отсутствие мониторинга приводит к нерациональному использованию ресурсов сервера.

7.2.2 Стратегии фильтрации

Используйте фильтры, чтобы сосредоточиться на важной информации и снизить когнитивную нагрузку:

• Фильтровать процессы по База данных чтобы увидеть только активность в отношении определенных баз данных.
• Фильтры Логин для отслеживания активности конкретного пользователя.
• Фильтры Состояние задачи = RUNNING для скрытия неактивных сеансов.
• Фильтры Область применения для изоляции трафика от определенных программ.
• Показывать только NonBlanks в Заблокировано чтобы видеть только блокирующие ситуации.

7.2.3 Выбор и сортировка столбцов

Разработайте систематический подход к анализу данных Activity Monitor:

1. Starт с обзором: Проверьте графики на наличие очевидных пиков и аномалий.
2. Проверьте процессы на предмет блокировки: Выполните сортировку по идентификатору сеанса, затем найдите значения «Заблокировано».
3. Обзор ожиданий ресурсов: Сортируйте по совокупному времени ожидания, чтобы выявить узкие места ресурсов.
4. Анализ дорогостоящих запросов: Сортируйте по различным показателям (ЦП, выполнение, чтение), чтобы найти различные типы проблем.
5. Проверьте с помощью панели ввода-вывода: Подтвердите, коррелируют ли запросы с высокой интенсивностью ввода-вывода с высокой дисковой активностью.

7.3 Интеграция с другими инструментами

Activity Monitor лучше всего работает как часть более широкого набора инструментов, а не как отдельное решение.

7.3.1 Использование с SQL Server Profiler

Монитор активности и SQL Server Профилировщики хорошо дополняют друг друга. Если вы обнаружили проблемный сеанс в «Мониторе активности», щёлкните по нему правой кнопкой мыши и выберите Отследить процесс в SQL Server Profiler.

Запустится Profiler с уже настроенными фильтрами для отслеживания активности только этого сеанса. Вы увидите полную последовательность выполненных операторов, информацию о времени выполнения и сообщения об ошибках — детали, которые Activity Monitor не предоставляет.

Чтобы узнать больше о SQL Server Возможности профилировщика и передовые методы трассировки см. в нашем комплексный SQL Server Руководство по профилированию.

7.3.2 Дополнение расширенными событиями

Расширенные события обеспечивают подробный мониторинг с минимальными издержками, который фиксирует информацию, упущенную Activity Monitor. Создавайте сеансы расширенных событий для отслеживания определённых событий, таких как взаимоблокировки, длительные запросы или избыточные перекомпиляции.

Используйте Activity Monitor для немедленного расследования, а Extended Events — для постоянного мониторинга и анализа истории. Эти два инструмента предназначены для решения разных задач.

Чтобы узнать больше о SQL Server Расширенные возможности событий и передовые методы мониторинга см. в нашем комплексный SQL Server Расширенное руководство по мероприятиям.

7.3.3 Решения сторонних поставщиков для мониторинга

Коммерческие инструменты, такие как SolarWinds Database Performance Analyzer, Redgate SQL Monitor и Quest Spotlight, предоставляют функции, которых нет в Activity Monitor: оповещения, исторические тенденции, планирование емкости и автоматическая диагностика.ostикс.

Эти инструменты являются ценным дополнением к Activity Monitor, а не его заменой. Activity Monitor остаётся полезным для быстрых проверок и исследований даже при наличии сложных инструментов мониторинга.

7.4 Распространенные ошибки, которых следует избегать

Понимание типичных ошибок при использовании Activity Monitor поможет вам использовать его более эффективно.

7.4.1. Оставьте Activity Monitor работать непрерывно

Мost Распространённая ошибка — открыть «Мониторинг системы» и оставить его работать на неопределённый срок. Это расходует ресурсы сервера и не приносит никакой пользы, поскольку вы не наблюдаете за ним активно.

Закрывайте Activity Monitor, когда не используете его активно. Если вам нужен непрерывный мониторинг, используйте подходящее решение для мониторинга с запланированным сбором данных.

7.4.2 Чрезмерная зависимость от одного только монитора активности

Монитор активности предоставляет один из способов оценки состояния сервера. Не полагайтесь исключительно на него. Дополните его монитором производительности Windows для получения показателей на уровне ОС, расширенными событиями для детального отслеживания и анализом плана выполнения для оптимизации запросов.

Activity Monitor помогает выявлять проблемы, но для их решения часто требуются дополнительные инструменты и более глубокий анализ.

Узнать больше о SQL Server монитор производительности в нашем полное руководство.

7.4.3 Игнорирование исторических тенденций

Монитор активности показывает текущее состояние, но проблемы с производительностью часто имеют закономерности, которые проявляются только с течением времени. Реализуйте сбор исторических данных, чтобы можно было сравнивать текущие показатели с базовыми показателями и выявлять тенденции.

Без исторического контекста вы можете не заметить, что сегодняшняя «нормальная» загрузка ЦП на 30% выше базового уровня прошлого месяца, что указывает на постепенное ухудшение.

8. Устранение неполадок в работе монитора активности

Иногда возникают неполадки в самом мониторе активности. Знание того, как устранить эти неполадки, поможет избежать разочарований.

8.1 Монитор активности не открывается или не отображает данные

Если приложение «Мониторинг активности» открывается, но отображает пустые панели или не открывается вообще, на это может быть несколько причин.

8.1.1 Проблемы с разрешениями

Мost Частой причиной проблем с монитором активности является нехватка прав. Чтобы проверить и устранить проблему:

1. Проверьте разрешения на уровне сервера:

   SELECT * FROM fn_my_permissions(NULL, 'SERVER')
   WHERE permission_name = 'VIEW SERVER STATE';
   

2. Если не возвращено ни одной строки, у вас нет разрешения VIEW SERVER STATE.
3. Попросите администратора сервера предоставить вам такое разрешение:

   USE master;
   GRANT VIEW SERVER STATE TO [YourLogin];
   

4. Закройте и снова откройте Activity Monitor после предоставления разрешений.

8.1.2 Проблемы совместимости версий

Используя старую версию SQL Server Management Studio для подключения к новой версии SQL Server Новая версия может вызывать сбои в работе Монитора активности. Инструмент может не распознавать новые типы ожидания или столбцы системного представления.

Всегда используйте версию SSMS, которая соответствует вашей или новее SQL Server Microsoft предоставляет последнюю версию SSMS для бесплатной загрузки отдельно от SQL Server себя.

8.1.3 Проблемы с брандмауэром и сетью

Монитор активности требует подключения к SQL Server Экземпляр на стандартных портах (по умолчанию 1433). Если подключение через обозревателя объектов удаётся, но через монитор активности возникает ошибка, правила брандмауэра могут блокировать определённые соединения.

Убедитесь, что ваш клиент может добраться до SQL Server Проверьте брандмауэр Windows и все сетевые брандмауэры между клиентом и сервером.

8.2 Монитор активности постоянно приостановлен

Распространенная проблема, особенно в SQL Server 2019, Activity Monitor открывается в состоянии паузы и отказывается возобновляться.

8.2.1 Понимание состояния паузы

Когда Мониторинг активности приостанавливается, на всех панелях отображается статус «Приостановлено» с кнопкой возобновления, которая может быть недоступна. Это не позволяет отслеживать активность сервера.

Состояние паузы обычно возникает из-за проблем с разрешениями, ограничений удаленного подключения или ошибок версии SSMS, а не из-за преднамеренной приостановки.

8.2.2 Распространенные причины

Монитор активности может перейти в состояние постоянной паузы из-за:

• Отсутствует разрешение VIEW SERVER STATE на новых панелях, добавленных в последнее время SQL Server версии
• Удаленные подключения отключены на SQL Server пример
• Ошибки аутентификации для определенных системных запросов
• Ошибки в определенных сборках SSMS, особенно в версиях 18.0–18.3
• Проблемы с подключением между клиентом и сервером

8.2.3 Шаги решения проблемы

Чтобы устранить проблемы с приостановленным состоянием Activity Monitor:

1. Обновление SSMS: Загрузите и установите последнюю версию SQL Server Версия Management Studio с сайта Microsoft. Многие ошибки, связанные с состоянием паузы, были исправлены в более поздних версиях.
2. Проверьте разрешения: Убедитесь, что у вас есть разрешения VIEW SERVER STATE и VIEW ANY DEFINITION.
3. Проверьте удаленные соединения: Убедитесь, что SQL Server экземпляр допускает удаленные подключения:

   EXEC sp_configure 'remote access';
   

   Если значение равно 0, попросите администратора включить его.

4. Restarт SSMS: Иногда просто закрывайте все окна и отдыхайте.tarTing SQL Server Management Studio решает эту проблему.
5. Подключитесь с аутентификацией Windows: Если вы используете аутентификацию SQL, попробуйте вместо нее аутентификацию Windows, так как она иногда позволяет обойти проблемы с остановкой, связанные с аутентификацией.

8.3 Проблемы производительности при использовании Activity Monitor

Если сам Activity Monitor становится медленным или приводит к снижению производительности сервера, необходима настройка.

8.3.1 Сокращение накладных расходов на мониторинг

Чтобы минимизировать влияние Activity Monitor:

1. Увеличьте интервал обновления до 30 секунд или 1 минуты.
2. Закройте панели, которые вы не используете активно, нажав кнопку «Свернуть».
3. Когда панели свернуты, Activity Monitor не запрашивает для них данные.
4. Избегайте одновременного запуска нескольких экземпляров Activity Monitor.
5. Полностью закрывайте Activity Monitor, если не занимаетесь активным изучением проблем.

8.3.2 Альтернативные облегченные методы мониторинга

Если Activity Monitor потребляет слишком много ресурсов для вашей среды, рассмотрите альтернативные варианты:

• Запросите DMV напрямую: Напишите специальные запросы T-SQL, которые получат только необходимую вам информацию.
• Используйте sp_WhoIsActive: Эта хранимая процедура в высшей степени оптимизирована и обычно имеет меньшие накладные расходы, чем Activity Monitor.
• Осуществить выборку: Запланируйте задания SQL Agent, которые будут делать снимки данных DMV через регулярные интервалы и сохранять результаты в таблицах для последующего анализа.
• Мониторинг вторичных реплик: In Группы доступности AlwaysOnЗапустите Монитор активности, используя доступный для чтения дополнительный сервер, а не основной.

8.4 Неточная или отсутствующая информация

Иногда Activity Monitor отображает информацию, которая кажется неверной или неполной.

8.4.1 Проверка данных с помощью DMV

Если результаты мониторинга активности кажутся подозрительными, проверьте их, напрямую запросив соответствующие динамические административные представления (DMV). Например, если на панели «Процессы» блокировок нет, но пользователи сообщают о них, выполните запрос:

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;

Если этот запрос показывает блокировку, которую пропустил Activity Monitor, вы подтвердили наличие проблемы с отображением.

8.4.2 Понимание времени обновления данных

Помните, что Activity Monitor показывает моментальные снимки. Запрос, выполненный между интервалами обновления, не будет отображаться в списке «Недавние дорогостоящие запросы», если его план выполнения не сохранился в кэше.

Аналогичным образом, статистика ожидания на панели «Ожидания ресурсов» отражает накопление данных с момента последнего снимка. Быстро меняющиеся рабочие нагрузки могут демонстрировать разные закономерности при каждом обновлении.

9. Расширенные методы мониторинга активности

Опытные администраторы баз данных используют Activity Monitor сложными способами для извлечения максимальной диагностической информации.ostзначение IC.

9.1 Объединение нескольких панелей для анализа первопричин

Настоящая мощь Activity Monitor проявляется, когда вы сопоставляете информацию на нескольких панелях для понимания сложных проблем производительности.

9.1.1 Сопоставление ожиданий с процессами

Если на панели «Ожидания ресурсов» отображается большое время ожидания в категории, используйте панель «Процессы», чтобы определить, в каких сеансах возникают такие ожидания:

1. Обратите внимание на категорию ожидания с большим совокупным временем ожидания (например, «Блокировка»).
2. Переключитесь на панель «Процессы».
3. Сортировать по: Тип ожидания группировать сеансы по текущему ожиданию.
4. Найдите сеансы, показывающие типы ожидания в проблемной категории.
5. Для этих сеансов изучите Ожидание ресурса столбец, чтобы увидеть, какие объекты базы данных задействованы.
6. Щелкните правой кнопкой мыши и выберите Описание чтобы увидеть текст запроса.

Эта корреляция помогает вам перейти от «у нас есть ожидания блокировки» к «этот конкретный запрос ожидает блокировки в этой таблице».

9.1.2 Связь дорогостоящих запросов с проблемами ввода-вывода

Если на панели ввода-вывода файлов данных отображается высокая дисковая активность в определенной базе данных:

1. Обратите внимание, какие файлы базы данных имеют высокую скорость чтения или записи в МБ/с.
2. Переключиться на недавние дорогостоящие запросы.
3. Сортировать по: Физических чтений/сек для выявления запросов, интенсивно читающих с диска.
4. Фильтруйте или визуально идентифицируйте запросы к базе данных с высоким объемом ввода-вывода.
5. Проверьте планы выполнения этих запросов на предмет сканирования таблиц или отсутствующих индексов, приводящих к чрезмерному объему ввода-вывода.

Этот многопанельный анализ связывает симптомы (высокий объем операций ввода-вывода на диске) с причинами (конкретные неэффективные запросы).

9.2 Использование Activity Monitor для планирования емкости

Хотя Activity Monitor не хранит исторические данные, вы можете использовать его стратегически для наблюдений за планированием емкости.

9.2.1 Определение пиковых моделей использования

Отслеживайте активность сервера в разное время суток, чтобы определить закономерности использования:

1. Открывайте Activity Monitor в известные часы пик.
2. Обратите внимание на пиковые значения графика % загруженности процессора.
3. Запишите максимальное количество ожидающих задач.
4. Наблюдайте за пакетными запросами/сек в часы пик.
5. Задокументируйте наиболее загруженные базы данных на панели «Процессы».
6. Повторите в непиковые часы для сравнения.

Если пиковая загрузка процессора постоянно превышает 80%, вы приближаетесь к пределу мощности процессора. Аналогично, увеличение количества ожиданий указывает на растущую конкуренцию за ресурсы.

9.2.2 Анализ тенденций ресурсов

Хотя Activity Monitor отображает текущее состояние, вы можете использовать его для выборочной проверки тенденций, записывая ключевые показатели с течением времени:

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

Такое ручное отслеживание тенденций дополняет более сложные решения по мониторингу и помогает обосновать расширение мощностей.

9.3 Документирование базовых показателей эффективности

Установление базовых показателей производительности поможет вам распознать момент снижения производительности.

9.3.1 Сбор базовых показателей

В периоды заведомо хорошей производительности документируйте показатели Activity Monitor:

1. Откройте Activity Monitor во время обычных рабочих процессов (не в часы пик или вне часов пик).
2. Значения панели обзора записи:
   • Типичный диапазон % времени процессора
   • Среднее количество ожидающих задач
   • Нормальная скорость ввода-вывода базы данных
   • Типичные пакетные запросы/сек
3. Обратите внимание на категории панели «Ожидание ресурсов», которые показывают most время ожидания.
4. Обычно количество активных процессов документируется на панели «Процессы».
5. Запишите репрезентативные показатели выполнения запросов из недавних дорогостоящих запросов.

Сохраните эту базовую документацию для дальнейшего использования при исследовании проблем производительности.

9.3.2 Сравнение текущих и базовых показателей

При возникновении проблем с производительностью сравните текущие показания Activity Monitor с задокументированным базовым уровнем:

• Значительно ли превышается время загрузки процессора по сравнению с базовым значением? Сосредоточьтесь на запросах, интенсивно использующих процессор.
• Ожидание задач превышает базовый уровень в 2-3 раза? Изучите ожидание ресурсов.
• Значительно ли увеличился объём ввода-вывода? Проверьте панель ввода-вывода файлов данных и ресурсоёмкие запросы.
• Количество пакетных запросов ниже базового значения в часы пик? Обратите внимание на блокировки или проблемы с подключением.

Это сравнение поможет вам определить, что изменилось, и соответствующим образом сосредоточить усилия по устранению неполадок.

9.4 Создание пользовательских рабочих процессов мониторинга

Разработайте систематические рабочие процессы для распространенных сценариев расследования, чтобы обеспечить тщательный и повторяемый анализ.

9.4.1 Пошаговый процесс расследования

Если пользователи сообщают о проблемах с производительностью, следуйте последовательному рабочему процессу:

1. Быстрая проверка здоровья: Откройте Монитор активности и просмотрите графики панели «Обзор» на предмет очевидных аномалий.
2. Проверка на блокировку: Разверните панель «Процессы», отфильтруйте по параметру NonBlanks в столбце «Заблокировано».
3. Определите конкуренцию за ресурсы: Просмотрите панель «Ожидания ресурсов», отсортированную по времени ожидания.
4. Найти дорогие запросы: Изучите последние дорогостоящие запросы, отсортированные по загрузке ЦП, затем по выполнению, затем по чтению.
5. Сопоставьте шаблоны ввода-вывода: Перекрестные ссылки на дорогостоящие запросы с активностью панели ввода-вывода файлов данных.
6. Выводы документа: Делайте снимки экрана и записывайте соответствующие идентификаторы сеансов, типы ожидания и сведения о запросах.
7. Глубокое погружение: Используйте трассировки Profiler, анализ плана выполнения и запросы DMV для детального расследования выявленных проблем.

9.4.2 Критерии эскалации

Установите критерии, когда следует переходить к эскалации проблем, а не продолжать расследование:

• Немедленно эскалируйте ситуацию: Блокирующие цепочки длятся >5 минут, процессорное время загружено на 100% в течение >2 минут, критические системные процессы находятся в состоянии ПРИОСТАНОВЛЕН.
• Эскалация с анализом: Повторяющиеся дорогостоящие запросы потребляют >50% ресурсов ЦП, постоянно высокие времена отклика ввода-вывода >50 мс, периодические сбои в предоставлении памяти.
• Расследуйте дальше: Времяrary ожидает разрешения в течение нескольких минут, запросы с неоптимальными планами, но приемлемой производительностью, незначительная блокировка длительностью <30 секунд.

10. Монитор активности в разных SQL Server Версии

Монитор активности развился по всему миру SQL Server версий, причем каждый выпуск приносит улучшения, а иногда и новые проблемы.

10.1 Монитор активности в SQL Server 2008 и позже

SQL Server В 2008 году был представлен современный дизайн Activity Monitor, который по сей день остается практически неизменным.

10.1.1 новые функции, представленные в SQL Server 2008

SQL Server Редизайн Activity Monitor 2008 принес значительные улучшения:

• Графическая панель управления с диаграммами в реальном времени на панели обзора
• Интерфейс с расширяемой/сворачиваемой панелью, заменяющий старый вид, отображающий только сетку
• Панель «Недавние дорогостоящие запросы», на которой отображаются агрегированные данные об эффективности запросов
• Панель ввода-вывода файлов данных для мониторинга активности диска по каждому файлу
• Расширенная панель «Ожидания ресурсов» с категоризацией ожидания
• Контекстное меню правой кнопки мыши для действий с процессами, таких как завершение сеансов и запуск Profiler.
• Настраиваемые интервалы обновления от 1 секунды до 1 часа

Эти изменения превратили Activity Monitor из простого списка процессов в комплексную панель мониторинга.

10.1.2 Изменения от SQL Server 2005

SQL Server Activity Monitor 2005 года был гораздо более ограниченным:

• Доступ осуществляется через папку «Управление» в обозревателе объектов, а не через панель инструментов.
• Одна сетка, отображающая список процессов с основной информацией
• Никаких графических диаграмм или множественных панелей
• Никаких дорогостоящих запросов или мониторинга ввода-вывода
• Ограниченная информация о статистике ожидания

Редизайн 2008 года представлял собой полную переработку, а не постепенное улучшение.

10.2 Монитор активности в SQL Server 2014/2016

SQL Server В 2014 и 2016 годах были внесены постепенные улучшения в базовый сбор данных Activity Monitor, но визуальных изменений было мало.

10.2.1 Улучшения и усовершенствования

Основные улучшения в этих версиях:

• Более высокая производительность при мониторинге серверов с тысячами кэшированных планов
• Расширенные возможности фильтрации на панели «Процессы»
• Повышена точность агрегации статистики ожидания
• Лучшая обработка сортировки и фильтрации столбцов с большими наборами результатов
• Более эффективные запросы DMV, сокращающие накладные расходы на мониторинг

Основной интерфейс остался прежним SQL Server 2008, сохраняя привычный интерфейс для администраторов.

10.3 Монитор активности в SQL Server 2019/2022

последние SQL Server версии продолжают эволюцию Activity Monitor с акцентом на производительность и стабильность.

10.3.1 Новейшие функции и возможности

SQL Server Монитор активности 2019 и 2022 годов включает в себя:

• Поддержка новых типов ожидания, представленных в этих версиях
• Улучшена производительность рендеринга в SSMS с использованием технологии WPF
• Лучшая обработка большого количества активных сеансов
• Улучшенная совместимость с облачными платформами SQL
• Более точные метрики ЦП и ввода-вывода

10.3.2 Известные проблемы в последних версиях

SQL Server В 2019 году было выявлено несколько ошибок Activity Monitor:

• Состояние постоянной паузы: Монитор активности часто переходит в состояние паузы и не возобновляет работу, особенно в SSMS 18.0–18.3. Исправлено в более поздних версиях SSMS.
• Ошибки удаленного подключения: Некоторые конфигурации препятствуют открытию Activity Monitor на удалённых экземплярах. Обходные пути включают включение определённых флагов трассировки или использование более новых сборок SSMS.
• Проблемы с разрешением: Новые системные представления требуют дополнительных разрешений, которые четко не документированы, что приводит к пустым экранам даже при использовании VIEW SERVER STATE.

Всегда используйте последнюю версию SSMS при работе с SQL Server 2019 и 2022 гг., чтобы избежать этих проблем.

11. Практические варианты использования и примеры

Реальные примеры демонстрируют, как эффективно применять Activity Monitor в типичных сценариях устранения неполадок.

11.1 Пример: Диагностика медленного веб-приложения

Группа разработчиков сообщает, что их веб-приложение стало неприемлемо медленным: загрузка страниц занимает 20–30 секунд вместо обычных 2–3 секунд.

11.1.1 Первоначальное расследование с панелью обзора

Откройте Мониторинг активности и изучите панель Обзор:

1. График % загруженности процессора показывает 85–95 % использования ЦП, что значительно выше обычного базового уровня в 30–40 %.
2. Ожидание задач колеблется от 10 до 20 задач по сравнению с нормальным базовым значением 0–3.
3. Ввод-вывод базы данных демонстрирует умеренную активность около 50 МБ/с.
4. Количество пакетных запросов в секунду ниже ожидаемого и составляет 100 в секунду по сравнению с типичными 300–400 в секунду в рабочее время.

Этот шаблон указывает на узкое место в ЦП, связанное с конкуренцией за ресурсы, что приводит к снижению пропускной способности. Сервер работает с высокой нагрузкой, но не обрабатывает много запросов.

11.1.2 Определение проблемного запроса

Разверните панель «Недавние дорогостоящие запросы» и отсортируйте по числу выполнений/мин.:

1. Самый верхний запрос показывает 15 000 выполнений в минуту.
2. Щелкните правой кнопкой мыши и выберите Редактировать текст запроса для проверки запроса.
3. Запрос представляет собой простой оператор SELECT, извлекающий одну запись пользователя: SELECT * FROM Users WHERE UserId = @UserId.
4. Этот запрос не должен выполняться 15 000 раз в минуту при обычном использовании приложения.

Щелкните правой кнопкой мыши запрос и выберите Показать план выполнения. План показывает сканирование таблицы Users с предупреждением об отсутствующем индексе в столбце UserId.

Отфильтруйте панель «Процессы» по приложению, чтобы отобразить только соединения веб-приложения. В нескольких сеансах один и тот же запрос выполняется повторно.

11.1.3 Разрешение и проверка

Проблема вызвана двумя причинами: избыточным выполнением запросов и отсутствием индекса. Шаги решения:

1. Создайте недостающий индекс:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Свяжитесь с командой разработчиков о чрезмерном количестве выполнений. Расследование выявило проблему с запросом N+1 в коде приложения, где цикл извлекает данные пользователя для каждого элемента списка.
3. Изменить приложение для объединения пользовательских поисковых запросов в один запрос с использованием предложения IN или табличного параметра.
4. Проверьте исправление путем мониторинга Activity Monitor после развертывания. Загрузка ЦП снижается до 35–40%, количество запусков в минуту уменьшается до 200–300, а время отклика приложений возвращается к норме.

11.2 Пример решения проблемы блокировки

Пользователи сообщают, что система ввода заказов периодически зависает на 30–60 секунд, прежде чем возобновить нормальную работу.

11.2.1 Обнаружение цепочки блоков

Откройте Activity Monitor во время одного из этих событий зависания и разверните панель «Процессы»:

1. Сортировать по: ID сессии чтобы увидеть все организованные сессии.
2. Несколько сеансов показывают значения в Заблокировано столбец, все указывает на идентификатор сеанса 73.
3. Сессия 73 показывает «1» в Блокировщик головы колонка, подтверждающая, что это первопричина.
4. Тип ожидания для заблокированных сеансов отображается LCK_M_X, что означает ожидание эксклюзивных блокировок.
5. Ожидание ресурса столбец показывает, что блокировка произошла в таблице «Заказы».

11.2.2 Анализ причины

Щелкните правой кнопкой мыши по сеансу 73 и выберите Описание для просмотра команды:

UPDATE Orders 
SET Status = 'Processing', 
    LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);

Это обновление является частью пакетной обработки, которая выполняется каждый час. Проверка Логин столбец подтверждает принадлежность сеанса учетной записи службы пакетной обработки.

Запрос блокирует таблицу «Заказы» при обработке тысяч заказов. Время ожидания для заблокированных сеансов неуклонно растёт, что подтверждает, что проблема заключается в этой длительной операции.

11.2.3 Реализация исправления

Краткосрочное разрешение:

1. Подробная информация о сеансе 73, включая текст запроса и продолжительность.
2. Позвольте обновлению завершиться естественным образом, поскольку это законная пакетная обработка.
3. После завершения убедитесь, что заблокированные сеансы удалены, и нормальная работа возобновлена.

Реализованы долгосрочные решения:

1. Изменить график пакетного задания работать в непиковые часы (с 2 до 4 часов утра, а не в рабочее время).
2. Изменить пакетную обработку обновлять заказы небольшими партиями по 100 записей за раз, снимая блокировки между партиями.
3. Добавить индекс в столбце OrderId, чтобы ускорить операцию обновления.
4. Рассмотрите изоляцию SNAPSHOT для операций чтения с целью снижения влияния блокировки.

11.3 Пример: Выявление избыточных выполнений запросов

Мониторинг базы данных показывает, что загрузка ЦП постепенно увеличивалась за последний месяц, однако в коде приложения явных изменений не произошло.

11.3.1 Выявление аномальных показателей выполнения

Откройте Activity Monitor и изучите панель «Недавние дорогостоящие запросы»:

1. Сортировать по: Казни/мин чтобы увидеть мost часто выполняемые запросы.
2. Самый верхний запрос показывает 37 000 выполнений в минуту — намного больше, чем любой другой запрос.
3. Щелкните правой кнопкой мыши и выберите Редактировать текст запроса.
4. Запрос извлекает информацию о категории продукта:

   SELECT CategoryId, CategoryName 
   FROM ProductCategories 
   WHERE CategoryId = @CategoryId;
   

5. Этот простой запрос должен быть быстрым и кэшируемым, однако он выполняется десятки тысяч раз в минуту.

11.3.2 Трассировка по коду приложения

На панели «Процессы» найдите сеансы, выполняющие этот запрос:

1. Обратите внимание Область применения столбец показывает «ProductCatalogService».
2. Щелкните правой кнопкой мыши один из этих сеансов и выберите Отследить процесс в SQL Server Profiler.
3. SQL Profiler показывает, что запрос выполняется многократно в быстрой последовательности с разными значениями CategoryId.
4. Обратитесь к команде разработчиков, управляющей ProductCatalogService, для проверки кода.

Анализ кода выявил проблему: недавнее изменение извлекает списки товаров с категориями. Для каждого товара в наборе результатов (часто более 1,000 товаров) код выполняет отдельный запрос к базе данных для получения информации о категории — классическая проблема запроса N+1.

11.3.3 Оптимизация приложения

Реализуйте правильное решение:

1. Изменить запрос приложения для использования JOIN для извлечения продуктов и их категорий в одной базе данных вызовите:

   SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName
   FROM Products p
   INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
   WHERE p.Active = 1;
   

2. Разверните обновленный код и следите за монитором активности.
3. Проверьте исправление: Количество выполнений в минуту для запроса категории сократилось с 37 000 до менее 100, а общая загрузка ЦП снизилась на 40%.
4. Задокументируйте извлеченный урок и поделитесь ею с командой разработчиков, чтобы предотвратить возникновение подобных проблем при будущих изменениях кода.

12. Обнаружение потенциального повреждения базы данных

Хотя Activity Monitor не предназначен специально для обнаружения повреждений базы данных, некоторые закономерности в его отображении могут указывать на скрытые проблемы с повреждениями, требующие дальнейшего изучения.

12.1 Признаки потенциального повреждения базы данных

Если база данных повреждена и к ней осуществляется доступ, вы можете иногда видеть:

1. На панели «Процессы»:

• Сеансы зависают в состоянии SUSPENDED с необычными типами ожидания
• Процессы, показывающие состояния ошибок
• Запросы неоднократно терпят неудачу

2. На панели «Ожидание ресурсов»:

• Необычные типы ожидания, связанные с вводом-выводом, которые могут указывать на проблемы с диском (хотя это, скорее всего, указывает на проблемы с оборудованием, а не на логические повреждения)

3. В недавних дорогих запросах:

• Запросы с аномально высоким уровнем физического чтения, если они неоднократно пытаются прочитать поврежденные страницы.

12.2 Дальнейшая проверка с помощью DBCC CHECKDB

Если Activity Monitor обнаруживает признаки потенциального повреждения, следует немедленно запустить DBCC CHECKDB для проверки целостности базы данных. Эта команда сканирует все страницы базы данных, проверяет контрольные суммы и выявляет ошибки логической целостности.

Чтобы узнать больше об использовании DBCC CHECKDB для проверки и исправления повреждений базы данных, см. наш подробное руководство по DBCC CHECKDB.

12.3 Ремонт с помощью профессиональных инструментов

Если DBCC CHECKDB подтверждает повреждение базы данных, у вас есть несколько вариантов исправления:

• Предпочтительный подход — восстановление из заведомо исправной резервной копии. См. наше полное руководство по резервному копированию и восстановлению SQL Server базы данных.
• В случае незначительных повреждений DBCC CHECKDB с REPAIR_REBUILD может решить проблемы.
• Для критически важных баз данных без недавних резервных копий профессиональный Программное обеспечение для восстановления SQL и службы часто могут восстановить данные, которые встроенные возможности восстановления не могут.

13. Заключение

SQL Server Activity Monitor является бесценным инструментом для администраторов баз данных, предоставляя мгновенную информацию о производительности сервера и помогая быстро и эффективно диагностировать проблемы.

13.1 Краткое изложение ключевых моментов

В этом руководстве мы рассмотрели, как Activity Monitor помогает вам понимать и устранять неполадки SQL Server спектакль:

• Activity Monitor обеспечивает наблюдение в режиме реального времени за процессами, ожиданиями, запросами и вводом-выводом с помощью организованного графического интерфейса.
• Каждая из пяти панелей — «Обзор», «Процессы», «Ожидание ресурсов», «Ввод-вывод файлов данных» и «Недавние дорогостоящие запросы» — предлагает уникальные перспективы активности сервера.
• Распространенные сценарии устранения неполадок, такие как чрезмерное выполнение запросов, цепочки блокировок и высокая загрузка ЦП, становятся управляемыми с помощью систематического исследования Activity Monitor.
• Несмотря на свою мощь, Activity Monitor имеет ограничения, включая отсутствие исторических данных, группировку по типу ожидания и накладные расходы на мониторинг, которые влияют на его применение.cabспособность.
• Дополнение Activity Monitor запросами DMV, sp_WhoIsActive, расширенными событиями и потенциально сторонними инструментами позволяет создать комплексную стратегию мониторинга.
• Соблюдение рекомендаций по интервалам обновления, закрытие Activity Monitor, когда он не используется, и объединение нескольких панелей для корреляции позволяют максимально повысить его ценность и при этом минимизировать воздействие.

13.2 Монитор активности как часть вашего набора инструментов

Activity Monitor должен служить вашим первым инструментом реагирования при анализе производительности, а не единственным. Его преимущество заключается в мгновенном отслеживании ситуации во время активного устранения неполадок, помогая быстро определить, является ли база данных узким местом, и определить, какие конкретно аспекты требуют более глубокого анализа.

Представьте себе Activity Monitor как приборную панель автомобиля: он мгновенно сообщает о неполадках и помогает определить общую причину. Так же, как приборная панель автомобиля не показывает точную причину загорания индикатора «Check Engine», Activity Monitor указывает на проблемы, не всегда раскрывая их истинную причину. Для более глубокого анализа требуются дополнительные инструменты и специальные знания.

Интегрируйте Activity Monitor в более широкий набор инструментов, включающий анализ плана выполнения, отслеживание статистики ожидания, решения для исторического мониторинга и рекомендации по производительности. Используйте его в сочетании с правильными стратегиями индексации, методами оптимизации запросов и планированием ресурсов.

13.3 Продолжение вашего обучения

Освоение Activity Monitor — это всего лишь один шаг к становлению эффективным администратором баз данных. Продолжайте развивать свои навыки:

• Обучение интерпретации планов выполнения и выявлению неэффективных операций
• Понимание SQL Server статистика ожидания и ее последствия
• Изучение методов проектирования и оптимизации индексов
• Исследование SQL ServerАрхитектура и как она обрабатывает запросы
• Применение систематических методик устранения неполадок
• Накопление опыта работы с расширенными событиями для детального отслеживания
• Понимание уровней изоляции транзакций и их влияния на производительность

Каждое исследование производительности с помощью Activity Monitor открывает вам что-то новое о том, как SQL Server Работает и как приложения взаимодействуют с базами данных. Документируйте свои выводы, делитесь знаниями с коллегами и создавайте библиотеку.rary решений распространенных проблем.

13.4 Дополнительные ресурсы

Расширьте свои знания с помощью этих ценных ресурсов:

• Откройте Монитор активности в SQL Server Студия управления (SSMS) : официальный SQL Server документация о том, как открыть Activity Monitor в SQL Server Студия управления (SSMS).
• Мониторинг системы : Официальный SQL Server документ о том, как использовать Activity Monitor.

14. Часто задаваемые вопросы (FAQ)

В: Что такое SQL Server Монитор активности?

A: SQL Server Монитор активности — это встроенный инструмент SQL Server Студия управления, которая отображает информацию в режиме реального времени о процессах, запущенных на SQL Server Экземпляр и его влияние на ресурсы сервера. Он предоставляет графическую панель управления с пятью панелями, отображающими различные аспекты активности сервера, включая использование процессора, ожидающие задачи, скорость ввода-вывода, активные сеансы и ресурсоёмкие запросы.

В: Как открыть Activity Monitor в SSMS?

A: Вы можете открыть Activity Monitor четырьмя способами: (1) Щелкните значок Activity Monitor на панели инструментов SSMS, (2) Щелкните правой кнопкой мыши свой SQL Server имя экземпляра в обозревателе объектов и выберите Мониторинг системы, (3) Нажмите Ctrl + другой + Aили (4) Настройте SSMS для автоматического запуска через Инструменты -> Настройки -> Окружающая среда -> Стартап.

В: Какие разрешения мне нужны для использования Activity Monitor?

А: Вам нужно ПРОСМОТР СОСТОЯНИЯ СЕРВЕРА разрешение увидеть мost Информация о мониторе активности. Для панели ввода-вывода файлов данных вам также потребуется: СОЗДАТЬ БАЗУ ДАННЫХ, ИЗМЕНИТЬ ЛЮБУЮ БАЗУ ДАННЫХ или Просмотреть любое определение разрешения. Без этих разрешений программа «Мониторинг активности» может открываться, но отображать пустые панели.

В: Почему мой Монитор активности приостановлен или не работает?

A: Мониторинг активности обычно приостанавливается из-за проблем с разрешениями, устаревших версий SSMS или отключенных удаленных подключений. Чтобы решить эту проблему: (1) Обновите SSMS до последней версии, (2) Убедитесь, что у вас есть разрешение VIEW SERVER STATE, (3) Убедитесь, что удаленные подключения разрешены на SQL Server например, (4) Резtart SSMS и (5) Попробуйте подключиться с аутентификацией Windows вместо аутентификации SQL, если применимоcabим.

В: В чем разница между Activity Monitor и sp_WhoIsActive?

A: Activity Monitor — это графический инструмент, встроенный в SSMS, предоставляющий организованные панели для различных аспектов мониторинга. sp_WhoIsActive — это бесплатная хранимая процедура, созданная сообществом, которая возвращает подробную информацию о сеансе в виде единого набора результатов с более конкретными типами ожидания, подробностями блокировок и возможностями настройки, чем Activity Monitor. Activity Monitor лучше подходит для визуального просмотра, а sp_WhoIsActive отлично подходит для мониторинга по скриптам и предоставляет более подробную информацию.

В: Влияет ли Activity Monitor на производительность сервера?

A: Да, у Activity Monitor есть измеримые накладные расходы, поскольку он запрашивает системные динамические административные представления (DMV) при каждом интервале обновления. Влияние увеличивается с уменьшением частоты обновления — Microsoft предупреждает, что интервалы менее 10 секунд могут повлиять на производительность сервера. Всегда закрывайте Activity Monitor, когда он не используется активно, и учитывайте интервалы обновления 30–60 секунд на производственных серверах с высокой нагрузкой.

В: Могу ли я получить данные Activity Monitor с помощью T-SQL?

A: Да, Activity Monitor запрашивает динамические представления управления системой, такие как sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats и sys.dm_exec_query_stats. Вы можете напрямую запрашивать эти динамические административные представления с помощью T-SQL для получения аналогичной информации программным способом, что позволяет создавать настраиваемые скрипты мониторинга и автоматически собирать данные.

В: Каков интервал обновления по умолчанию?

О: Интервал обновления по умолчанию составляет 10 секунд. Вы можете изменить его, щёлкнув правой кнопкой мыши в любом месте панели «Обзор» и выбрав Интервал обновленияи выберите один из предустановленных вариантов: 1 секунда, 5 секунд, 10 секунд, 30 секунд, 1 минута или 1 час. Более короткие интервалы обеспечивают более точное представление данных в реальном времени, но увеличивают затраты на мониторинг.

В: Как автоматически открыть Activity Monitor в SSMS?tarтуп?

A: Настройте автоматический запуск с помощью параметров SSMS: перейдите к Инструменты -> Настройки -> Окружающая среда -> Стартап, А затем выберите Откройте Обозреватель объектов и Монитор активности из При запуске Выпадающий список. Монитор активности будет автоматически открываться при каждом подключении к серверу в SSMS.

В: Каковы ограничения Activity Monitor?

A: Основные ограничения включают: (1) Отсутствие возможности хранения исторических данных или анализа тенденций, (2) Типы ожидания сгруппированы в категории, а не показаны отдельно, (3) Некоторые типы ожидания, такие как CXPACKET, могут не отображаться, (4) Моментальные снимки на определенный момент времени могут пропускать временные проблемы, (5) Накладные расходы на мониторинг могут повлиять на загруженность серверов, (6) Отсутствие механизма оповещения для упреждающего мониторинга и (7) Невозможность агрегировать данные по нескольким SQL Server В таких случаях дополните Activity Monitor расширенными событиями, наборами данных или сторонними инструментами мониторинга.

---

Об авторе

Юань Шэн старший администратор баз данных (DBA) с более чем 10-летним опытом работы в SQL Server сред и управления корпоративными базами данных. Он успешно реализовал сотни сценариев восстановления баз данных в финансовых, медицинских и производственных организациях.

Юань специализируется на SQL Server восстановление базы данных, решения с высокой доступностьюа также оптимизацию производительности. Его обширный практический опыт включает управление базами данных объемом в несколько терабайт, внедрение групп доступности Always On и разработку автоматизированных стратегий резервного копирования и восстановления для критически важных бизнес-систем.

Благодаря своим техническим знаниям и практическому подходу Юань фокусируется на создании всеобъемлющих руководств, которые помогают администраторам баз данных и ИТ-специалистам решать сложные задачи. SQL Server Он эффективно решает задачи. Он всегда в курсе последних новостей. SQL Server выпускает новые версии и развивает технологии баз данных Microsoft, регулярно тестируя сценарии восстановления, чтобы убедиться, что его рекомендации соответствуют реальным передовым практикам.

Есть вопросы о SQL Server Восстановление или требуется дополнительное руководство по устранению неполадок в базе данных? Юань приветствует отзывы и предложения для улучшения этих технических ресурсов.