SQL Server Монитор на активността: Пълно ръководство за администратори на бази данни [2026]

SQL Server Мониторът на активността е вграден диагностичен инструмент в SQL Server Студио за управление, което показва информация за SQL Server процеси и тяхното влияние върху производителността на сървъра. Това ви позволява да проследявате SQL Server процеси, наблюдение на чакащите ресурси, анализ на скъпи заявки и наблюдение на модели на входно/изходни операции – всичко това от един интерфейс.

1.2 Защо да използвате SQL Server ActivityMonitor?

Мониторът на активността служи като първа линия на защита при отстраняване на проблеми с производителността. Той осигурява незабавна видимост върху това, което се случва на вашия компютър. SQL Server екземпляр, без да се изискват сложни T-SQL заявки или инструменти на трети страни.

Инструментът е отличен в това да ви помогне бързо да идентифицирате често срещани проблеми, като блокиращи сесии, заявки, изискващи интензивно използване на процесора, прекомерно изпълнение на заявки и затруднения при входно/изходни операции. Когато потребителите съобщават, че дадено приложение е бавно или не реагира, Activity Monitor ви помага да определите дали виновникът е сървърът на базата данни.

За администратори на бази данни, които не работят с SQL Server Ежедневно, Activity Monitor предлага достъпна начална точка за разбиране на активността на сървъра. Дори опитни администратори на бази данни го използват като отправна точка за проучвания на производителността.

1.3 Монитор на активността спрямо други инструменти за наблюдение

Въпреки че Activity Monitor е ценен, важно е да се разбере как се сравнява с други опции за наблюдение:

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

Монитор на активността срещу sp_who2: Традиционната команда sp_who2 показва основна информация за сесията, но Activity Monitor отива по-далеч, като показва статистика за чакане, скъпи заявки и I/O показатели в организиран, визуален формат.

Монитор на активността срещу инструменти на трети страни: Търговските решения за мониторинг, като SolarWinds Database Performance Analyzer, предлагат историческо проследяване, предупреждения и разширен анализ, които липсват на Activity Monitor. Activity Monitor обаче не изисква допълнителни разходи или инсталация.

1.4 Ключови предимства за администраторите на бази данни

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

Нулев разход: Като вграден SQL Server Функцията Management Studio не изисква лицензионна такса или усилия за внедряване.
Наблюдение в реално време: Вижте текущата активност на сървъра в момента, в който се случва, с конфигурируеми интервали на обновяване от 1 секунда до 1 час.
Интегрирани действия: Щракнете с десния бутон върху процеси, за да прекратите сесии, да видите подробности за заявките или да ги стартирате SQL Server Следи от профилера – всичко това от инструмента.
Множество гледни точки: Вижте състоянието на сървъра от различни ъгли чрез пет специализирани панела, всеки от които се фокусира върху специфични аспекти на производителността.
Бързо отстраняване на неизправности: Идентифицирайте най-често срещаните проблеми с производителността в рамките на минути, като ускорите средното време за разрешаване.
Ниска бариера за навлизане: Не са необходими задълбочени познания, за да започнете да използвате инструмента ефективно, макар и по-задълбочени. SQL Server експертният опит помага при тълкуването.

2. Първи стъпки с Activity Monitor

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

2.1 Предварителни изисквания и системни изисквания

да използвам SQL Server Монитор на активността, от който се нуждаете SQL Server Management Studio (SSMS), инсталиран на вашата локална машина или jump сървър. Инструментът Activity Monitor беше значително преработен през SQL Server 2008 г., така че информацията в това ръководство се отнася за SQL Server 2008 и по-нови версии.

Трябва да имате мрежова връзка с SQL Server екземпляра, който искате да наблюдавате. За бази данни, хоствани в облак, обикновено ще ви е необходима VPN връзка или правилно конфигурирани правила на защитната стена, за да получите достъп до екземпляра.

Мониторът на активността работи с всички издания на SQL Server, включително Express, Standard и Enterprise. Самият инструмент работи на клиентската ви машина в SSMS, така че ресурсите на сървъра се влияят само от заявките за наблюдение, които изпълнява.

2.2 Необходими разрешения

Подходящите разрешения са от съществено значение за правилното функциониране на Activity Monitor. Без съответните права може да видите празен дисплей или да получите грешки „достъп отказан“.

2.2.1 Разрешение за ПРЕГЛЕД НА СЪСТОЯНИЕТО НА СЪРВЪРА

- ПРЕГЛЕД НА СЪСТОЯНИЕТО НА СЪРВЪРА Разрешението е основното изискване за използване на Activity Monitor. Това разрешение на ниво сървър ви позволява да виждате всички активни процеси и свързаните с тях показатели.

За да предостави това разрешение, администраторът на сървъра може да изпълни:

GRANT VIEW SERVER STATE TO [YourLoginName];

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

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

За да видите информация в панела „Входно/изходни операции с файлове с данни“, са ви необходими допълнителни разрешения. По-конкретно, трябва да имате една от следните комбинации:

СЪЗДАЙТЕ БАЗА ДАННИ разрешение, или
ПРОМЕНЯНЕ НА ВСЯКА БАЗА ДАННИ разрешение, или
ВИЖТЕ ВСЯКО ОПРЕДЕЛЕНИЕ разрешение

Тези разрешения трябва да бъдат комбинирани с ПРЕГЛЕД НА СЪСТОЯНИЕТО НА СЪРВЪРА за пълна функционалност на Activity Monitor.

2.2.3 Отстраняване на проблеми с разрешенията

Ако „Мониторът на активността“ се отвори, но не показва данни, най-честата причина са разрешенията. Проверете дали вашите данни за вход имат разрешение за VIEW SERVER STATE на ниво сървър. Можете да проверите разрешенията си, като изпълните:

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

Потърсете „VIEW SERVER STATE“ в колоната permission_name. Ако липсва, свържете се с администратора на базата данни, за да ви го предостави.

2.3 Как да отворите Монитор на активността в SSMS

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

2.3.1 Метод 1: От лентата с инструменти

Най-бързият начин да отворите Activity Monitor е чрез иконата в лентата с инструменти:

Свържете се с вашия SQL Server пример в SQL Server Студио за управление.
Намерете иконата на Activity Monitor в стандартната лента с инструменти (тя прилича на стълбовидна диаграма със зелен бутон за възпроизвеждане).
Щракнете върху иконата, за да стартирате Activity Monitor.

Този метод е най-бърз, когато вече работите в SSMS и трябва бързо да проверите активността на сървъра.

2.3.2 Метод 2: От Object Explorer

Можете също да стартирате Activity Monitor директно от Object Explorer:

В Object Explorer намерете SQL Server екземпляра, който искате да наблюдавате.
Щракнете с десния бутон върху името на екземпляра.
Изберете Дейност Monitor от контекстното меню.

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

2.3.3 Метод 3: Използване на клавишна комбинация

За потребители, фокусирани върху клавиатурата, SQL Server Management Studio предоставя специален пряк път:

Уверете се, че SSMS е активният прозорец и сте свързани с екземпляр.
Натискане Ctrl + Друг + A.
Мониторът на активността ще се отвори за текущо избрания екземпляр в Object Explorer.

Обърнете внимание, че Activity Monitor ще се свърже с избрания от вас сървърен екземпляр в Object Explorer, така че се уверете, че сте избрали правилния екземпляр, преди да използвате този пряк път.

2.3.4 Метод 4: От менюто с опции (Конфигурация при стартиране)

Ако често използвате Activity Monitor, можете да конфигурирате SSMS да го стартира автоматично всеки път, когато стартирате приложението:

In SQL Server Студио за управление, отидете до Инструменти -> Опции.
В диалоговия прозорец „Опции“ разгънете Заобикаляща средаИ след това изберете Startup.
От При стартиране падащ списък, изберете Отворете Object Explorer и Activity Monitor.
Изберете OK.

Следващия път, когато стартирате SSMS и се свържете със сървър, Activity Monitor ще се отвори автоматично заедно с Object Explorer.

3. Разбиране на панелите за наблюдение на активността

Мониторът на активността организира информацията в пет разгъваеми панела, всеки от които предоставя различна перспектива върху активността на сървъра. Разбирането на това, което всеки панел показва, е от решаващо значение за ефективното отстраняване на неизправности.

3.1 Панел за общ преглед

Панелът „Общ преглед“ представя четири графики в реално време, които ви дават бърза картина на вашето здравословно състояние. SQL Server например. Тези графики се актуализират през конфигурируем интервал и ви помагат да идентифицирате анормални модели с един поглед.

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

Тази графика показва процента от времето, което процесорът прекарва в изпълнение на неактивни нишки за SQL Server екземпляр във всички процесори. Стойността представлява SQL Serverизползването на процесора, а не използването на процесора на целия сървър.

Ако постоянно виждате натоварване на процесора на или близо 100%, вашият сървър е ограничен от процесора. Това може да показва неефективни заявки, липсващи индекси или недостатъчен хардуерен капацитет. Използвайте панела „Последни скъпи заявки“, за да определите кои заявки консумират най-много процесор.

3.1.2 Задачи за чакане

Този показател показва броя на задачите, които чакат освобождаване на ресурси, преди да могат да продължат. Задачите могат да чакат процесор, входно/изходни операции, памет или заключвания.

Постоянно високият брой чакащи задачи показва конфликт на ресурси. Панелът „Чакащи ресурси“ предоставя повече подробности за това кои типове ресурси причиняват чакания.

3.1.3 Входно/изходни операции към базата данни (MB/s)

Тази графика показва скоростта на пренос на данни между паметта и диска. Тя комбинира както четене, така и запис, измерени в мегабайти в секунда.

Пиковете в I/O на базата данни могат да показват заявки, извършващи сканиране на големи таблици, прекомерна активност в регистрирането или операции с контролни точки. Панелът „Файл с данни I/O“ разделя I/O активността по база данни и файл.

3.1.4 Заявки за пакети/сек

Този показател представлява броя на SQL Server партиди, получени от екземпляра в секунда. Пакетът може да бъде единичен оператор или множество оператори, подадени заедно.

Тази стойност ви дава представа за цялостната активност на сървъра. Внезапните спадове в пакетните заявки по време на нормалното работно време могат да показват проблеми със свързаността на приложенията или проблеми, с които се сблъскват потребителите.

3.1.5 Задаване на интервали за обновяване

Можете да персонализирате колко често Activity Monitor актуализира данните си:

Щракнете с десния бутон някъде в панела „Общ преглед“.
Изберете Интервал на обновяване.
Изберете интервал от предварително зададените стойности: 1 секунда, 5 секунди, 10 секунди (по подразбиране), 30 секунди, 1 минута или 1 час.

Задаването на интервали на обновяване под 10 секунди увеличава натоварването на сървъра от наблюдение. За производствени системи с голямо натоварване, помислете за използване на интервали от 30 секунди или по-дълги, за да се сведе до минимум въздействието.

3.2 Панел „Процеси“

Панелът „Процеси“ показва информация за текущо изпълняваните сесии на вашия SQL Server например. Този панел е от съществено значение за идентифициране кой какво прави и за забелязване на блокиращи проблеми.

3.2.1 Разбиране на информацията за процеса

Всеки ред в панела „Процеси“ представлява активна сесия на сървъра. Панелът показва сесии от всички бази данни и всички потребители, което ви дава цялостен поглед върху активността на сървъра.

Показваната информация включва потребителско име, име на приложение, име на хост, достъпната база данни и текуща команда. Това ви помага да съпоставите активността на базата данни с конкретни потребители или приложения.

3.2.2 Обяснение на ключовите колони

Разбирането на ключовите колони ви помага да интерпретирате ефективно информацията за процеса:

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

3.2.3 Процеси на филтриране и сортиране

Панелът „Процеси“ включва мощни възможности за филтриране, които ви помагат да се съсредоточите върху съответните сесии:

Щракнете върху стрелката за падащо меню в заглавката на произволна колона.
Филтърът показва наличните стойности за тази колона, включително Всички, Заготовки, и Непразни.
Изберете конкретни стойности, за да филтрирате показването само до тези сесии.

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

Можете също да сортирате по която и да е колона, като щракнете върху нейния заглавен ред. Щракнете веднъж за възходящ ред, два пъти за низходящ ред.

3.2.4 Идентифициране на блокиране и блокирани сесии

Панелът „Процеси“ ви помага да идентифицирате блокиращи сценарии, при които една сесия пречи на други да продължат:

Блокирано от: Показва идентификатора на сесията, която блокира тази сесия. Ако тази колона съдържа стойност, сесията чака заключване, задържано от друга сесия.
Блокатор на главата: Показва „1“, ако тази сесия блокира други, но самата тя не е блокирана. Това е основната причина за веригата на блокиране.

За да проучите проблем с блокирането, първо идентифицирайте блокера на главите (сесията, маркирана с „1“ в колоната „Блокатор на главите“), след това проверете какво прави и решете дали да го оставите да завърши или да го прекратите.

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

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

Щракнете с десния бутон върху която и да е сесия в панела „Процеси“.
Ще видите няколко опции:
- Детайли: Показва последната команда, изпълнена от тази сесия.
- Процес на убиване: Прекратява сесията (използвайте с повишено внимание).
- Проследяване на процеса в SQL Server Профайлър: Стартира SQL Server Profiler и автоматично филтрира, за да показва само активността от тази сесия.

Опцията „Детайли“ показва текста на командата, но имайте предвид, че това е последно командата е изпълнена – тя може все още да не се изпълнява. Опцията „Проследяване“ е особено полезна, когато трябва да видите пълната последователност от команди, изпълнявани от дадена сесия.

3.3 Панел за чакане на ресурси

Панелът „Изчакване на ресурси“ обобщава статистиката за изчакване, показвайки кои типове сесии с ресурси чакат най-често. Тази информация е от решаващо значение за диагностициране на проблеми с производителността.

3.3.1 Разбиране на статистиката за чакане

Кога SQL Server не може незабавно да изпълни заявка за ресурс (като например заключване, процесорно време или памет), заявената задача влиза в състояние на изчакване. Статистиката за изчакване проследява тези периоди на изчакване и ви помага да разберете къде сървърът прекарва време в чакане, вместо да работи.

Панелът „Чакане на ресурси“ събира данни от изгледи за динамично управление на системата, като sys.dm_os_wait_stats и sys.dm_exec_requests. На всеки интервал на обновяване той изчислява разликата между текущата и предишната снимка, показвайки ви скоростта на натрупване за всеки тип чакане.

3.3.2 Категории чакане

Мониторът на активността групира стотици отделни типове чакане в по-широки категории, за да опрости интерпретацията:

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

Въпреки че това групиране опростява изгледа, то също така замъглява важни детайли. Например, „Buffer Latch“ може да групира чаканията PAGELATCH_SH, PAGELATCH_UP и PAGELATCH_EX, които имат различни последици за производителността.

3.3.3 Интерпретиране на времето за изчакване и задачите за изчакване

Панелът „Чакане на ресурси“ показва две ключови показатели за всяка категория чакане:

Кумулативно време на изчакване (мс): Общият брой милисекунди, натрупани по време на текущия интервал на обновяване за тази категория чакане.
Задачи за чакане: Броят на задачите, които в момента чакат ресурси в тази категория.

Стойността на времето за изчакване е особено интересна. Ако имате интервал на опресняване от 10 секунди и видите време за изчакване от 20 000 ms за дадена категория, това показва множество едновременни изчаквания (20 000 ms / 10 000 ms = средно 2 едновременни изчаквания по време на интервала).

3.3.4 Идентифициране на пречки в производителността

Използвайте панела „Чакане на ресурси“, за да определите къде вашият сървър прекарва най-много време в чакане:

Разгънете панела „Чакане на ресурси“.
Наблюдавайте категориите чакане, които натрупват най-дълго време на чакане.
Сортиране по Кумулативно време на изчакване за да се види кои ресурси са най-ограничени.

Чаканията с високо ниво на буферно заключване често показват конфликт за страници с данни в паметта, което може да предполага затруднения в I/O или конфликт за tempdb. Чаканията с високо ниво на заключване показват проблеми с блокирането. Чаканията с високо ниво на памет предполагат недостатъчно предоставяне на памет за операции със заявки.

3.4 Панел за входно/изходно управление на файлове с данни

Панелът „Входно/изходни операции с файлове с данни“ показва активността на диска за всеки файл с база данни на вашия сървър, което ви помага да идентифицирате пречките при входно/изходни операции и да разберете моделите на използване на диска.

3.4.1 Разбиране на I/O показателите

Панелът „Входно/изходни данни за файлове“ показва няколко показателя за всеки файл на базата данни:

База данни: Името на базата данни.
Тип файл: Или Данни (включително таблици и индекси), или Лог (лог на транзакциите).
Логическо име: Логическото име на файла, както е дефинирано в SQL Server.
Четене в МБ/сек: Скоростта на четене на данни от този файл.
Записано в МБ/сек: Скоростта на записване на данни в този файл.
Време за реакция (ms): Средно време за отговор за входно/изходни операции върху този файл.

Тези показатели се обновяват със същия интервал като панела „Общ преглед“, което ви дава видимост в реално време върху активността на диска.

3.4.2 Идентифициране на пречки във входно/изходните операции

Внимавайте за тези модели, които показват проблеми с производителността на входно/изходните операции:

Високо време за реакция: Времената за реакция постоянно над 15-20 ms предполагат бавни дискови подсистеми. Времената за реакция над 50 ms показват сериозни I/O затруднения.
Небалансирано натоварване: Ако един файл с данни показва значително по-високи скорости на входно/изходни операции от други в същата база данни, може да се възползвате от добавянето на допълнителни файлове, за да разпределите натоварването.
Прекомерна активност в Tempdb: Високите скорости на входно/изходни операции за tempdb файлове често показват заявки, създаващи големи междинни набори от резултати или използващи неефективни планове за изпълнение.

3.4.3 Анализ на файловете на базата данни

Използвайте панела „Входно-изходни данни за файлове“, за да разберете как вашите бази данни използват дискови ресурси:

Разгънете панела за входно/изходни файлове с данни.
Сортиране по Четене в МБ/сек or Записано в МБ/сек за да се идентифицират най-активните файлове.
Обърнете внимание на всички файлове с постоянно висока активност или дълго време за реакция.
Сравнете тази информация с екрана „Последни скъпи заявки“, за да определите кои заявки водят до натоварване от входно/изходни операции.

3.5 Панел „Последни скъпи заявки“

Панелът „Последни скъпи заявки“ често е най-ценният панел за отстраняване на проблеми с производителността на приложенията. Той показва заявки, които консумират значителни сървърни ресурси, което ви помага да идентифицирате възможности за оптимизация.

3.5.1 Разбиране на показателите за заявки

Мониторът на активността показва няколко показателя за всяка скъпа заявка:

Изпълнения/мин: Колко пъти е изпълнена заявката през последната минута.
Процесор (мс/сек): Време на процесора, консумирано от тази заявка в секунда.
Физически четения/сек: Брой четения на физически диск в секунда за тази заявка.
Логически записи/сек: Брой логически записи (в буферния кеш) в секунда.
Логически четения/сек: Брой логически четения (от кеш буфера) в секунда.
Средна продължителност (мс): Средно време за изпълнение на тази заявка.
Брой планове: Брой планове за изпълнение в кеша за тази заявка.

Тези показатели ви помагат да разберете не само кои заявки са скъпи, но и защо скъпи са и колко често се движат.

3.5.2 Опции за сортиране

Можете да сортирате панела „Последни скъпи заявки“ по различни показатели, за да намерите различни видове проблеми:

Щракнете върху заглавката на която и да е колона, за да сортирате по този показател.
Често срещаните стратегии за сортиране включват:
- Сортиране по процесор: Намерете заявки, които консумират най-много процесорно време.
- Сортиране по Изпълнения/мин: Идентифицирайте заявки, които се изпълняват прекомерно често.
- Сортиране по физически четива: Намерете заявки, причиняващи най-много дискови входно-изходни операции.
- Сортиране по средна продължителност: Намерете дълго изпълняващи се заявки.

Когато отстранявате проблем с производителността, опитайте да сортирате по няколко колони, за да получите различни перспективи. Заявка с умерено използване на процесора, но изключително висок брой изпълнения в минута, може да е истинският ви проблем.

3.5.3 Преглед на текста на заявката

За да видите действителния SQL оператор зад скъпа заявка:

Щракнете с десния бутон върху реда на заявката в екрана „Последни скъпи заявки“.
Изберете Редактиране на текста на заявката.
Отваря се нов прозорец за заявка, показващ пълния SQL оператор.

Това ви позволява да разгледате логиката на заявката и да идентифицирате потенциални възможности за оптимизация. След това можете да копирате текста на заявката за тестване на модифицирани версии.

3.5.4 Анализиране на планове за изпълнение

Плановете за изпълнение ви показват как SQL Server изпълнява заявка, разкривайки неефективности като липсващи индекси или неподходящи типове съединения:

Щракнете с десния бутон върху реда на заявката в екрана „Последни скъпи заявки“.
Изберете Показване на план за изпълнение.
SQL Server Management Studio показва графично представяне на това как се изпълнява заявката.

Търсете операции, които консумират голям процент от разходите за заявки, предупреждения за липсващи статистически данни или индекси и неочаквани операции за сканиране на таблици. Те често показват къде трябва да се съсредоточат усилията за оптимизация.

3.5.5 Идентифициране на проблемни заявки

Следете за тези модели в панела „Последни скъпи заявки“:

Прекомерни екзекуции: Заявка, изпълнявана хиляди пъти в минута, може да показва проблем с N+1 заявка, при който кодът на приложението извиква базата данни в цикъл.
Високо физическо четене: Заявките с високи скорости на физическо четене често достигат до диска, което предполага липсващи индекси или лошо написани заявки.
Висок процесор с ниска продължителност: Много бързи заявки, които консумират много процесорна мощност като цяло, могат да повлияят на производителността на сървъра също толкова, колкото и няколко бавни заявки.
Множество броя на плановете: Заявките с много планове за изпълнение може да страдат от проблеми с параметричното „смъркане“ или непараметризирани заявки, причиняващи препълване на кеша на плана.

4. Използване на Activity Monitor за отстраняване на проблеми с производителността

Мониторът на активността наистина блести, когато го използвате систематично за диагностициране и разрешаване на проблеми с производителността. Този раздел разглежда често срещани сценарии за отстраняване на неизправности и как да се подходи към тях.

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

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

4.1.1 Идентифициране на повтарящи се заявки

За да откриете заявки, които се изпълняват твърде често:

Отворете „Монитор на активността“ и разгънете Последни скъпи запитвания панел.
Сортиране по Изпълнения/мин (изпълнения в минута).
Търсете заявки в горната част с брой изпълнения, който изглежда неразумно висок.
Щракнете с десния бутон върху подозрителната заявка и изберете Редактиране на текста на заявката за да се разгледа SQL изразът.

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

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

Прекомерните изпълнения на заявки обикновено произтичат от следните проблеми:

N+1 Задача със заявка: Кодът на приложението извлича списък с елементи, след което изпълнява отделна заявка за всеки елемент, за да извлече свързани данни. Това създава N допълнителни заявки, където N е броят на елементите.
Липсва кеширане: Приложението запитва базата данни за данни, които рядко се променят, вместо да ги кешира в паметта на приложението.
Цикли на анкетиране: Кодът многократно отправя заявки към базата данни, проверявайки за промени в състоянието, вместо да използва известия за промени или опашки от съобщения.
Неефективност на управлението на оперативните процеси (ORM): Entity Framework и подобни инструменти понякога генерират неефективни модели на заявки, когато разработчиците не разбират как техният код се превежда в SQL.

За да определите първопричината, проследете заявката обратно до кода на приложението. Обърнете внимание на Приложение и Вход колони в панела „Процеси“, когато заявката се изпълни. Можете също да щракнете с десния бутон върху процеса и да изберете Проследяване на процеса в SQL Server Profiler за да видите модела на обаждане.

4.1.3 Решения и най-добри практики

След като сте идентифицирали прекомерни изпълнения на заявки, помислете за следните решения:

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

4.2 Разследване на проблеми с блокирането

Блокиране възниква, когато една сесия задържа заключвания, които пречат на протичането на други сесии. Това се проявява като бавно време за реакция на приложенията и разочаровани потребители.

4.2.1 Идентифициране на блокиращи вериги

За откриване и анализ на блокиране:

Отворете „Монитор на активността“ и разгънете Процеси панел.
Търсете сесии със стойности в Блокирано от колона – те чакат заключвания, държани от други сесии.
Намерете сесии с „1“ в Блокер за глава колона – това са основната причина за блокиране на веригите.
Обърнете внимание на Сесиен идентификатор на блокера на главата.
Щракнете с десния бутон върху сесията за блокиране на глави и изберете Детайли за да видите каква команда изпълнява.

Разбирането на блокиращата верига е от решаващо значение. Блокиращият фактор е сесията, която трябва да проучите, а не блокираните сесии надолу по веригата.

4.2.2 Разбиране на типовете заключвания

- Тип чакане Колоната в панела „Процеси“ показва какъв тип заключване чакат блокираните сесии:

LCK_M_X: Изключително заключване, обикновено причинено от операции UPDATE, DELETE или INSERT.
LCK_M_S: Споделено заключване, обикновено SELECT оператори, чакащи освобождаването на ексклузивни заключвания.
LCK_M_U: Изчакване на заключване при актуализация, междинен тип заключване, използван по време на актуализации.
LCK_M_IX: Изчакване на ексклузивно заключване на намерение, което показва съревнование за заключване на ниво страница или ред.

- Изчакайте ресурс Колоната показва кой обект на базата данни е заключен, което ви помага да разберете коя таблица или индекс е включен в спора.

4.2.3 Разрешаване на проблеми с блокирането

След като идентифицирате блокиращата сесия и какво прави тя, имате няколко опции:

Изчакайте завършване: Ако блокиращият head-a сървър изпълнява легитимна заявка, която скоро ще завърши, може би е най-добре да я оставите да завърши по естествен път.
Убий сесията: Ако блокерът на заглавката е заседнал или изпълнява заявка, която трябва да бъде отменена:
- Щракнете с десния бутон върху сесията в панела „Процеси“.
- Изберете Процес на унищожаване.
- Потвърдете действието в диалоговия прозорец.
Заявки за оптимизиране: Ако блокирането се повтаря с едни и същи заявки, оптимизирайте ги, за да намалите продължителността на заключването им.
Регулиране на нивата на изолация: Обмислете използването на READ COMMITTED SNAPSHOT ISOLATION, за да намалите блокирането при натоварвания с голямо четене.
Настройка на индекса: Добавете индекси, за да ускорите заявките, като намалите времето, през което задържат заключванията.

4.3 Анализиране на високо натоварване на процесора

Когато панелът „Общ преглед“ показва време на процесора постоянно на или близо до 100%, трябва да идентифицирате кои заявки са отговорни и да определите дали те могат да бъдат оптимизирани.

4.3.1 Идентифициране на заявки, изискващи интензивно използване на процесора

За да намерите заявки, които консумират прекомерно много процесор:

Отворете Последни скъпи запитвания панел.
Сортиране по Процесор (мс/сек) за показване на заявки, използващи най-много процесорно време.
Разгледайте най-често срещаните заявки в списъка.
Щракнете с десния бутон върху заявки с висока производителност на процесора и изберете Редактиране на текста на заявката за да видите SQL оператора.
Изберете Показване на план за изпълнение за да се разбере как се изпълнява заявката.

Обърнете внимание не само на използването на процесора от отделните заявки, но и на Изпълнения/мин колона. Заявка, използваща умерено натоварване на процесора на изпълнение, но изпълнявана хиляди пъти в минута, може да бъде най-големият ви консуматор на процесор.

4.3.2 Техники за оптимизация на заявки

Често срещани подходи за намаляване на консумацията на процесор включват:

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

4.4 Проучване на проблеми с паметта

Натоварването с памет може да доведе до прехвърляне на заявки към диска, което значително намалява производителността. „Мониторът на активността“ ви помага да идентифицирате операции, изискващи интензивно използване на паметта.

4.4.1 Разбиране на показателите за паметта

- Използване на паметта Колоната в панела „Процеси“ показва паметта, разпределена за всяка сесия в килобайти. Високата употреба на памет от една сесия често показва:

Големи операции за сортиране или хеширане, които не се побират в първоначално предоставената памет
Заявки, извличащи огромни набори от резултати
Прекомерният паралелизъм създава много копия на операторите на плана за изпълнение
Течове на памет в съхранени процедури или функции на CLR

Прозорецът „Чакане на ресурси“ може да показва „Чакане на паметта“, когато заявките не могат да получат достатъчно памет и трябва да чакат, докато паметта стане достъпна.

4.4.2 Идентифициране на заявки, изискващи интензивно използване на паметта

За да намерите заявки, причиняващи натоварване на паметта:

В Процеси панел, сортиране по Използване на паметта за да видите сесиите, които консумират най-много памет.
Щракнете с десния бутон върху сесии с високо потребление на памет и изберете Детайли за да видите техните запитвания.
В Последни скъпи запитвания панел, търсете заявки с високо Логически четения or Логически записи, тъй като те често корелират с използването на паметта.
Разгледайте плановете за изпълнение на операторите за сортиране и хеширане, които използват памет.

Заявките, показващи предупреждения за „Предоставяне на памет“ в планове за изпълнение или предупреждения за преливане, показват проблеми с натиск върху паметта.

4.5 Откриване на проблеми с производителността на приложенията

Когато потребителите съобщават за бавно време за реакция на приложенията, Activity Monitor ви помага да определите дали базата данни е пречката.

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

За да проучите бавността на приложението:

Обърнете внимание на точното време, в което потребителите съобщават за проблеми, и засегнатите приложения.
Отворете „Монитор на активността“ и проверете Преглед панел за пикове на ресурсите по това време.
В Процеси панел, филтриране по Приложение за да се показват само връзките от засегнатото приложение.
Търсете високо Изчакайте време стойности, които показват закъснения в базата данни.
Проверете Последни скъпи запитвания панел за заявки от това приложение, консумиращи значителни ресурси.

Ако базата данни не показва необичайна активност, докато потребителите изпитват бавна работа, проблемът вероятно се крие в кода на приложението, мрежовата латентност или производителността от страна на клиента.

4.5.2 Идентифициране на неефективни модели на приложение

Activity Monitor разкрива няколко анти-модела в дизайна на приложенията:

Приложения за чат: Много малки заявки вместо по-малко, по-ефективни заявки. Идентифицирани по висок брой връзки и множество прости заявки в „Последни скъпи заявки“.
N+1 заявки: Една заявка, последвана от N допълнителни заявки за свързани данни. Показва се като проста заявка с изключително висок брой изпълнения в минута.
Големи набори от резултати: Приложенията извличат много повече данни от необходимото. Търсете високо Логически четения комбинирани с прости SELECT * заявки.
Липсващи таймаути: Приложенията, които не задават времеви ограничения за команди, могат да оставят връзките отворени за неопределено време, видими като продължителни сесии в панела „Процеси“.

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

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

5.1 Използване на динамични изгледи за управление (DMV)

SQL Server предоставя информация за активността чрез динамични изгледи за управление, към които Activity Monitor отправя запитвания зад кулисите.

5.1.1 Ключови DMV за мониторинг на дейностите

Най-важните DMV за репликиране на функционалността на Activity Monitor включват:

sys.dm_exec_requests: Показва текущо изпълняваните заявки с информация за процесора, входно/изходните операции и чакащите данни.
sys.dm_exec_sessions: Съдържа информация на ниво сесия, като например потребителско име, име на хост и име на програма.
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:

Изтеглете последната версия от http://whoisactive.com.
Изтеглянето е SQL скрипт, съдържащ дефиницията на процедурата.
Отворете скрипта в SQL Server Студио за управление.
Свържете се с вашия SQL Server инстанция.
Изпълнете скрипта, за да създадете процедурата в главната база данни.
Предоставете разрешения за изпълнение на съответните потребители.

Тъй като sp_WhoIsActive е инсталиран в master, той е достъпен от всеки контекст на базата данни.

5.2.2 Примери за основна употреба

Най-лесният начин за използване на sp_WhoIsActive е:

EXEC sp_WhoIsActive;

Това връща набор от резултати, показващ всички активни сесии с техните заявки, типове чакане, информация за блокиране и използване на ресурси.

За 10-секундна проба, показваща активност през този период:

EXEC sp_WhoIsActive @delta_interval = 10;

Това изчислява делти за показатели като CPU и четения, показвайки какво се е случило през тези 10 секунди.

5.2.3 Разширени параметри

sp_WhoIsActive поддържа множество параметри за персонализиране:

@филтър: Филтрирайте резултатите по конкретни сесии, бази данни или данни за вход.
@тип_филтър: Посочете за какво се прилага филтърът (сесия, база данни, вход и т.н.).
@get_plans: Включете планове за изпълнение в резултатите (задайте на 1).
@get_locks: Показване на подробна информация за заключване (зададено на 1).
@get_transaction_info: Показване на подробности за транзакцията (зададено на 1).
@сортиране_поръчка: Подредете резултатите по различни показатели (процесор, четене, времетраене и др.).
@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. Те са най-полезни за бързи проверки, когато се нуждаете от минимална информация бързо.

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

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

sp_lock: Показва информация за заключване (отхвърлено; използвайте sys.dm_tran_locks вместо това).
sp_монитор: Показва статистика за SQL Server дейност.
sp_помощ: Показва дефинициите на обекти и метаданните.
DBCC SQLPERF: Показва използването на пространството в регистрационния файл на транзакциите и статистиката за чакане.

5.4 Създаване на персонализирани скриптове за наблюдение

За среди, изискващи специфично наблюдение извън това, което Activity Monitor предоставя, можете да създавате персонализирани решения, използвайки DMVs.

5.4.1 Пълен еквивалентен скрипт на Activity Monitor

Ето един подробен скрипт, който възпроизвежда повечето функции на Activity Monitor:

-- 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 агент

Можете да планирате персонализирани скриптове за наблюдение, като използвате SQL Server Агент:

Създайте таблица за съхраняване на резултатите от мониторинга.
Променете скрипта си за наблюдение, за да вмъкнете резултати в тази таблица.
In SQL Server Студио за управление, разгъване SQL Server Агент в Object Explorer.
Щракнете с десния бутон Работа и изберете Нова работа.
Конфигурирайте задачата да изпълнява вашия скрипт за наблюдение на редовни интервали.
Настройте предупреждения или отчети въз основа на събраните данни.

Този подход позволява проследяване на историята и анализ на тенденциите, които Activity Monitor не предоставя.

6. Ограничения и съображения на монитора на активността

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

6.1 Разбиране на разходите на Activity Monitor

Activity Monitor не е безплатен – той изразходва сървърни ресурси за събиране и показване на информация. Разбирането на това натоварване ви помага да го използвате отговорно.

6.1.1 Въздействие върху сървърните ресурси

Activity Monitor изпълнява заявки към системните DMV-та при всяко обновяване. Тези заявки консумират процесорна мощност, генерират логически четения и могат за кратко да задържат заключвания върху системните таблици. На натоварени сървъри това натоварване може да повлияе на производителността.

Екраните „Процеси“ и „Последни скъпи заявки“ са особено скъпи, тъй като трябва да сканират потенциално големи DMV и кеширани таблици. На сървъри с хиляди кеширани планове за заявки, обновяването на „Последни скъпи заявки“ може да отнеме няколко секунди.

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

6.1.2 Най-добри практики за интервал на обновяване

Изберете интервали на обновяване, подходящи за вашата ситуация:

1-5 секунди: Само за незабавно отстраняване на критични проблеми на слабо натоварени сървъри. Не оставяйте Activity Monitor да работи през тези интервали.
10 секунди (по подразбиране): Разумно за повечето сценарии за отстраняване на неизправности и общо наблюдение.
30-60 секунди: По-добър избор за производствени сървъри под голямо натоварване или при наблюдение за продължителни периоди.
Само ръчно обновяване: За ситуации, в които искате да проверявате текущото състояние от време на време, без непрекъснато запитване.

Винаги затваряйте Activity Monitor, когато приключите с проучването. Не го оставяйте да работи непрекъснато, особено когато е включено множество копия от различни потребители.

6.2 Проблеми с групирането на типа чакане

Подходът на Activity Monitor за категоризиране на чаканията, макар и да опростява изгледа, може да скрие важна диагностична информация.

6.2.1 Как Activity Monitor групира чаканията

SQL Server проследява стотици различни типове чакане, всеки от които показва специфичен ресурс или условие. Activity Monitor ги групира в широки категории като „Buffer Latch“, „Lock“ и „Pamet“.

Например, категорията „Buffer Latch“ включва PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX и няколко други специфични типа чакане. Въпреки че всички те са свързани с достъпа до страница, те имат различни причини и решения.

Microsoft не документира точно кои типове чакания се съпоставят с кои категории, което затруднява разбирането какво всъщност виждате.

6.2.2 Липсващи типове чакане

Мониторът на активността не показва всички типове чакания. Най-забележителното е, че често пропуска CXPACKET чаканията, които показват паралелно изпълнение на заявки. CXPACKET чаканията са често срещани и обикновено не са проблематични, но знанието за тяхното наличие ви помага да разберете характеристиките на работното натоварване.

Когато Activity Monitor показва „Buffer Latch“ като най-голямо чакане, но други инструменти показват, че CXPACKET доминира, несъответствието идва от логиката за филтриране и групиране на Activity Monitor.

6.2.3 Защо специфичните видове чакания са важни

Познаването на конкретния тип чакане е важно за отстраняване на неизправности:

PAGELATCH_EX: Често показва спор за tempdb на страниците за разпределение. Решението включва добавяне на още tempdb файлове с данни.
PAGELATCH_SH: Може да показва горещи страници в потребителските таблици. Решението включва разделяне или реорганизация на индекси.
ЗАТЪРЧАВАНЕ_НА_СТРАНИЦАТА: Често срещано по време на актуализации. Може да показва нормална работа, а не проблем.

Мониторът на активността групира всички тези елементи под „Buffer Latch“, което затруднява диагностиката. Инструменти като sp_WhoIsActive и DMV заявки показват специфични типове чакане.

6.3 Точност и навременност на данните

Activity Monitor предоставя изглед почти в реално време, но „почти“ е ключовата дума. Разбирането на метода му за събиране на данни ви помага да интерпретирате резултатите правилно.

6.3.1 Моментна снимка срещу непрекъснато наблюдение

Мониторът на активността показва моментни снимки, направени на всеки интервал на обновяване. Събитията, случващи се между моментните снимки, не се записват. Ако заявка се изпълнява в продължение на 2 секунди, а вие обновявате на всеки 10 секунди, може да я видите веднъж или изобщо да не я видите, в зависимост от времето.

Това означава, че Activity Monitor се справя отлично с откриването на постоянни проблеми (блокиране с продължителност минути, постоянно високо натоварване на процесора), но може да пропусне временни проблеми (кратки безизходици, случайни пикове на заявките).

6.3.2 Агрегиране и вземане на проби

Панелът „Последни скъпи заявки“ показва обобщени данни, откакто плановете за заявки са влезли в кеша. Две еднакви заявки с различни стойности на параметрите се показват като един ред, ако споделят план. Това обобщаване може да маскира проблеми със специфични комбинации от параметри (проблеми с анализа на параметри).

Панелът „Изчакване на ресурси“ изчислява честотите, като сравнява моментни снимки. Ако статистиката за изчакване се нулира между моментните снимки (рядко, но е възможно), изчислените честоти може да са неправилни.

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

Мониторът на активността не е подходящ за всеки сценарий на наблюдение. Разпознайте кога алтернативни инструменти са по-добър избор.

6.4.1 Изисквания за исторически анализ

Мониторът на активността показва само текуща или скорошна активност. Той не съхранява исторически данни. Ако трябва да анализирате тенденции в продължение на дни или седмици, да сравните текущата производителност с базовите стойности или да генерирате отчети за моделите на производителност, Мониторът на активността не е достатъчен.

За исторически анализ използвайте SQL Serverвграденото табло за управление на производителността, разширени събития с файлови цели или решения за мониторинг от трети страни.

6.4.2 Необходими са подробни статистики за чакане

Когато ви е необходима точна информация за типа на чакане за разширена настройка, групирането и филтрирането на Activity Monitor я правят неадекватна. Използвайте DMV заявки директно или sp_WhoIsActive вместо това.

За подробен анализ на статистиката на чаканията, изпратете заявка директно към sys.dm_os_wait_stats и филтрирайте ръчно безобидните чакания.

6.4.3 Съображения за производствен сървър

На производствени сървъри с голямо натоварване, натоварването на Activity Monitor може да бъде проблематично. Няколко администратори на бази данни не трябва да изпълняват Activity Monitor едновременно на един и същ сървър.

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

7. Най-добри практики за използване на монитора на активността

Спазването на най-добрите практики гарантира, че ще получите максимална полза от Activity Monitor, като същевременно минимизирате отрицателното въздействие върху вашите сървъри.

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

Мониторът на активността е отличен в специфични сценарии. Използвайте го, когато силните му страни съответстват на вашите нужди.

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

Мониторът на активността е идеален, когато потребителите в момента изпитват проблеми и е необходимо незабавно да диагностицирате проблема. Изгледът в реално време ви помага да видите какво се случва в момента.

Когато получите сигнал, че „приложението е бавно“, отварянето на Activity Monitor трябва да бъде една от първите ви стъпки. Можете бързо да определите дали базата данни е заета, блокирана или неактивна.

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

Когато дадено приложение престане да реагира, Activity Monitor ви помага да определите дали причината са проблеми с базата данни. Филтрирайте панела „Процеси“ по име на приложение, за да видите само активността в базата данни на това приложение.

Ако приложението не показва активност в базата данни, докато потребителите съобщават за проблеми, проблемът се крие другаде в стека. Ако видите обширно блокиране или скъпи заявки, значи сте открили виновника си.

7.1.3 Бързи проверки на състоянието

Мониторът на активността предоставя отлично табло за бързи проверки на състоянието по време на рутинно администриране. Отворете го, погледнете графиките „Общ преглед“ и се уверете, че нищо не изглежда необичайно.

Тази бегла проверка отнема секунди и може да разкрие проблеми, преди да станат критични. Направете я част от ежедневието си.

7.2 Оптимални настройки за конфигурация

Правилното конфигуриране на Activity Monitor подобрява както неговата полезност, така и потреблението на ресурси.

7.2.1 Препоръчителни интервали за обновяване

Съобразете интервала на обновяване с целта си:

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

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

7.2.2 Стратегии за филтриране

Използвайте филтри, за да се фокусирате върху подходяща информация и да намалите когнитивното натоварване:

Филтриране на процеси по База данни за да видите само активността спрямо конкретни бази данни.
Филтриране по Вход за проследяване на активността на конкретен потребител.
Филтриране по Състояние на задачата = RUNNING за скриване на неактивни сесии.
Филтриране по Приложение за изолиране на трафика от конкретни програми.
Показване само на непразни елементи в Блокирано от да виждате само блокиращи ситуации.

7.2.3 Избор и сортиране на колони

Разработете систематичен подход за преглед на данните от Монитора на активността:

Започнете с общ преглед: Проверете графиките за очевидни пикове или аномалии.
Проверете процесите за блокиране: Сортирайте по ИД на сесия, след което потърсете стойности за „Блокирано от“.
Преглед на ресурсите за изчакване: Сортирайте по кумулативно време на изчакване, за да идентифицирате пречките в ресурсите.
Анализирайте скъпи заявки: Сортирайте по различни показатели (процесор, изпълнения, четения), за да намерите различни типове проблеми.
Проверка с I/O панела: Проверете дали заявките с интензивен входно-изходен трафик корелират с висока дискова активност.

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

Мониторът на активността работи най-добре като част от по-широк набор от инструменти, а не като самостоятелно решение.

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

Монитор на активността и SQL Server Профилърите се допълват добре. Когато откриете проблемна сесия в Activity Monitor, щракнете с десния бутон върху нея и изберете Проследяване на процеса в SQL Server Profiler.

Това стартира Profiler с вече конфигурирани филтри да улавят само активността на тази сесия. Виждате пълната последователност от изпълнени оператори, информация за времето и съобщения за грешки – подробности, които Activity Monitor не предоставя.

За да научите повече за SQL Server Възможности за профилиране и усъвършенствани техники за проследяване, вижте нашите подробен SQL Server Ръководство за профилиране.

7.3.2 Допълване с разширени събития

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

Използвайте „Монитор на активността“ за незабавно разследване и „Разширени събития“ за текущо наблюдение и исторически анализ. Двата инструмента отговарят на различни нужди.

За да научите повече за SQL Server Разширени възможности за събития и усъвършенствани техники за наблюдение, вижте нашите подробен SQL Server Разширено ръководство за събития.

7.3.3 Решения за мониторинг от трети страни

Търговски инструменти като SolarWinds Database Performance Analyzer, Redgate SQL Monitor и Quest Spotlight предоставят функции, които липсват на Activity Monitor: предупреждения, исторически тенденции, планиране на капацитета и автоматизирана диагностика.

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

7.4 често срещани грешки, които трябва да избягвате

Разбирането на често срещаните грешки в Activity Monitor ви помага да го използвате по-ефективно.

7.4.1 Оставяне на Activity Monitor работещ непрекъснато

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

Затваряйте „Монитор на активността“, когато не го използвате активно. Ако се нуждаете от непрекъснато наблюдение, внедрете подходящо решение за наблюдение с планирано събиране на данни.

7.4.2 Прекомерно разчитане само на Activity Monitor

Мониторът на активността предоставя една перспектива за състоянието на сървъра. Не разчитайте единствено на него. Допълнете го с Windows Performance Monitor за показатели на ниво операционна система, Extended Events за подробно проследяване и анализ на плана за изпълнение за настройване на заявки.

Мониторът на активността ви помага да идентифицирате проблеми, но решаването им често изисква допълнителни инструменти и по-задълбочен анализ.

Научете повече за SQL Server монитор за производителност в нашия пълно ръководство.

7.4.3 Пренебрегване на историческите тенденции

Мониторът на активността показва текущото състояние, но проблемите с производителността често имат модели, видими само във времето. Внедрете събиране на исторически данни, за да можете да сравнявате текущите показатели с базовите стойности и да идентифицирате тенденции.

Без исторически контекст, може да не осъзнаете, че днешното „нормално“ използване на процесора е с 30% по-високо от базовото ниво от миналия месец, което показва постепенно влошаване.

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

Самият Монитор на активността понякога има проблеми. Познаването на начините за отстраняване на тези проблеми предотвратява разочарованието.

8.1 Мониторът на активността не се отваря или не показва данни

Когато Activity Monitor се отвори, но показва празни панели или изобщо не се отваря, няколко фактора може да са причина за това.

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

Най-честата причина за проблеми с Activity Monitor са недостатъчните разрешения. За да проверите и разрешите проблемите:

Проверете разрешенията на ниво сървър:

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

Ако не се върнат редове, нямате разрешение VIEW SERVER STATE.
Помолете администратор на сървъра да го разреши:
```
USE master;
GRANT VIEW SERVER STATE TO [YourLogin];
```
Затворете и отворете отново Монитора на активността, след като разрешенията са предоставени.

8.1.2 Проблеми със съвместимостта на версиите

Използване на стара версия на SQL Server Management Studio за свързване с по-нов SQL Server Версията може да причини повреди в Activity Monitor. Инструментът може да не разпознава нови типове чакане или колони на системния изглед.

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

8.1.3 Проблеми със защитната стена и мрежата

Мониторът на активността изисква връзка с SQL Server екземпляр на стандартни портове (1433 по подразбиране). Ако можете да се свържете чрез Object Explorer, но Activity Monitor не работи, правилата на защитната стена може да блокират определени връзки.

Проверете дали вашият клиент може да достигне SQL Server машината на всички необходими портове. Проверете както защитната стена на Windows, така и всички мрежови защитни стени между клиента и сървъра.

8.2 Мониторът на активността е поставен на пауза за постоянно

Често срещан проблем, особено в SQL Server 2019 г., Мониторът на активността се отваря в състояние на пауза и отказва да се възобнови.

8.2.1 Разбиране на състоянието на пауза

Когато Activity Monitor е на пауза, всички панели показват състояние „Пауза“ с бутон за възобновяване, който може да не функционира. Това ви пречи да виждате каквато и да е активност на сървъра.

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

8.2.2 Често срещани причини

Мониторът на активността може да влезе в постоянно състояние на пауза поради:

Липсва разрешение за преглед на състоянието на сървъра в по-новите панели, добавени наскоро SQL Server версии
Отдалечените връзки са деактивирани на SQL Server инстанция
Неуспешно удостоверяване за специфични системни заявки
Грешки в специфични компилации на SSMS, особено от 18.0 до 18.3
Проблеми със свързаността между клиента и сървъра

8.2.3 Стъпки за разрешаване

За да разрешите проблеми със състоянието на пауза в Activity Monitor:

Актуализиране на SSMS: Изтеглете и инсталирайте най-новото SQL Server Версия на Management Studio от уебсайта на Microsoft. Много грешки, свързани с паузирано състояние, бяха отстранени в по-късни издания.
Проверете разрешенията: Уверете се, че имате разрешения за ПРЕГЛЕД НА СЪСТОЯНИЕТО НА СЪРВЪРА и ПРЕГЛЕД НА ВСЯКА ДЕФИНИЦИЯ.
Проверете отдалечените връзки: Проверете дали SQL Server екземплярът позволява отдалечени връзки:
```
EXEC sp_configure 'remote access';
```
Ако стойността е 0, помолете администратор да я активира.
Рестартирайте SSMS: Понякога просто затваряне на всички прозорци и рестартиране SQL Server Management Studio решава проблема.
Свързване с удостоверяване на Windows: Ако използвате SQL удостоверяване, опитайте Windows удостоверяване, тъй като понякога то заобикаля проблемите с паузирането, свързани с удостоверяването.

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

Ако самият Activity Monitor стане бавен или причини влошаване на производителността на сървъра, е необходима корекция.

8.3.1 Намаляване на разходите за мониторинг

За да се сведе до минимум въздействието на Activity Monitor:

Увеличете интервала на обновяване до 30 секунди или 1 минута.
Затворете панелите, които не използвате активно, като щракнете върху бутона за свиване.
Когато панелите са свити, Activity Monitor не отправя заявки за данни за тях.
Избягвайте едновременното изпълнение на множество екземпляри на Activity Monitor.
Затворете изцяло „Монитор на активността“, когато не проучвате активно проблеми.

8.3.2 Алтернативни методи за лек мониторинг

Ако Activity Monitor е твърде ресурсоемък за вашата среда, помислете за алтернативи:

Запитване директно към DMV: Напишете специфични T-SQL заявки, които извличат само информацията, от която се нуждаете.
Използвайте sp_WhoIsActive: Тази съхранена процедура е силно оптимизирана и обикновено има по-ниски режийни разходи от Activity Monitor.
Приложете вземане на проби: Планирайте задачи на SQL Agent, които заснемат моментни снимки на данни от DMV на редовни интервали, съхранявайки резултатите в таблици за по-късен анализ.
Мониториране на вторични реплики: In Групи за достъпност „Винаги включено“, стартирайте Activity Monitor спрямо четим вторичен сървър, а не спрямо първичния.

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

Понякога Activity Monitor показва информация, която изглежда неправилна или непълна.

8.4.1 Проверка на данни с DMVs

Когато резултатите от „Монитор на активността“ изглеждат подозрителни, проверете ги, като отправите директна заявка към съответните 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 Разбиране на времето за обновяване на данните

Не забравяйте, че Мониторът на активността показва моментни снимки. Заявка, която е изпълнена между интервали на обновяване, няма да се появи в „Последни скъпи заявки“, освен ако планът ѝ за изпълнение не е в кеша.

По подобен начин, статистиката за изчакване в панела „Изчакване на ресурси“ отразява натрупването от последната снимка. Бързо променящите се работни натоварвания може да показват различни модели при всяко обновяване.

9. Разширени техники за наблюдение на активността

Опитните администратори на бази данни използват Activity Monitor по сложни начини, за да извлекат максимална диагностична стойност.

9.1 Комбиниране на множество панели за анализ на първопричините

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

9.1.1 Съпоставяне на чаканията с процесите

Когато панелът „Чакане на ресурси“ показва високи времена на изчакване в дадена категория, използвайте панела „Процеси“, за да определите кои сесии изпитват тези чакания:

Обърнете внимание на категорията чакане с високо кумулативно време на чакане (напр. „Заключване“).
Преминете към панела „Процеси“.
Сортиране по Тип чакане да групирате сесиите по текущото им чакане.
Потърсете сесии, показващи типове чакане в проблемната категория.
За тези сесии, разгледайте Изчакайте ресурс колона, за да видите кои обекти от базата данни са включени.
Щракнете с десния бутон и изберете Детайли за да видите текста на заявката.

Тази корелация ви помага да преминете от „имаме чакащи заключвания“ към „тази конкретна заявка чака заключвания на тази таблица“.

9.1.2 Свързване на скъпи заявки с проблеми с входно/изходните операции

Когато панелът „Входно/изходни операции с файлове с данни“ показва висока дискова активност в определена база данни:

Обърнете внимание кои файлове от базата данни имат висока скорост на четене или запис от MB/s.
Превключване към „Последни скъпи заявки“.
Сортиране по Физически четения/сек за идентифициране на заявки, които четат интензивно от диска.
Филтрирайте или визуално идентифицирайте заявки, изпълнявани към базата данни с висок I/O.
Проверете плановете за изпълнение на тези заявки за сканиране на таблици или липсващи индекси, причиняващи прекомерно количество входно-изходни операции.

Този многопанален анализ свързва симптомите (висок дисков входно-изходен трафик) с причините (конкретни неефективни заявки).

9.2 Използване на Activity Monitor за планиране на капацитета

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

9.2.1 Идентифициране на модели на пикова употреба

Следете активността на сървъра по различно време на деня, за да идентифицирате модели на употреба:

Отворете „Монитор на активността“ по време на известните пикови работни часове.
Обърнете внимание на пиковите стойности на графиката за % време на процесора.
Запишете максималния брой чакащи задачи.
Наблюдавайте заявките за партиди/сек в пиковите часове.
Документирайте най-натоварените бази данни в панела „Процеси“.
Повторете извън пиковите часове за сравнение.

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

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

Въпреки че Activity Monitor показва текущото състояние, можете да го използвате за проверка на тенденциите на място, като записвате ключови показатели във времето:

Правете екранни снимки на панела „Общ преглед“ по едно и също време всеки ден
Запишете пиковите стойности от всяка графика
Сравнявайте седмица след седмица, за да определите тенденциите на растеж
Следете за постепенно увеличаване на средното време на процесора или скоростта на входно/изходни операции.

Това ръчно проследяване на тенденциите допълва по-сложни решения за мониторинг и помага за обосноваване на разширяването на капацитета.

9.3 Документиране на базовите показатели за изпълнение

Определянето на базови показатели за ефективност ви помага да разпознаете кога производителността се влошава.

9.3.1 Събиране на базови показатели

По време на периоди с известна добра производителност, документирайте показателите на Activity Monitor:

Отворете „Монитор на активността“ по време на нормални бизнес операции (не пикови или извънпикови часове).
Стойности на панела „Общ преглед на записа“:
- Типичен диапазон на % време на процесора
- Среден брой чакащи задачи
- Нормална скорост на входно/изходни операции за база данни
- Типични заявки за пакети/сек
Обърнете внимание на категориите в панела „Чакане на ресурси“, които показват най-голямото време на изчакване.
Документирайте броя на активните процеси, обикновено в панела „Процеси“.
Записвайте представителни показатели за изпълнение на заявки от „Последни скъпи заявки“.

Запазете тази базова документация за бъдещи справки, когато проучвате проблеми с производителността.

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

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

Процесорното време значително по-високо ли е от базовото? Фокусирайте се върху заявки, изискващи интензивно използване на процесора.
Задачите за чакане 2-3 пъти ли са по-високи от базовите нива? Проучете чаканията на ресурсите.
Значително ли е по-висок входно-изходният обем? Проверете панела за входно-изходни данни с файлове и скъпите заявки.
По-ниски ли са пакетните заявки от базовата линия по време на пиковите часове? Потърсете блокиране или проблеми с връзката.

Това сравнение ви помага да определите какво се е променило и да насочите усилията си за отстраняване на неизправности по подходящ начин.

9.4 Създаване на персонализирани работни процеси за мониторинг

Разработете систематични работни процеси за често срещани сценарии на разследване, за да осигурите задълбочен и повторяем анализ.

9.4.1 Поетапен процес на разследване

Когато потребителите съобщават за проблеми с производителността, следвайте последователен работен процес:

Бърза проверка на здравето: Отворете „Монитор на активността“ и сканирайте графиките в панела „Общ преглед“ за очевидни аномалии.
Проверете за блокиране: Разгънете панела „Процеси“, филтрирайте за „Непразни“ в колоната „Блокирано от“.
Идентифицирайте спора за ресурси: Преглед на панела „Чакане на ресурси“, сортиран по време на изчакване.
Намерете скъпи заявки: Разгледайте последните скъпи заявки, сортирани по процесор, след това изпълнения и накрая четения.
Съпоставяне на модели на входно/изходни данни: Свържете скъпите заявки с активността на панела за входно/изходни операции с файлове с данни.
Констатации по документи: Направете екранни снимки и запишете съответните идентификатори на сесии, типове чакане и подробности за заявките.
Дълбоко гмуркане: Използвайте следи от Profiler, анализ на план за изпълнение и заявки към DMV за подробно проучване на идентифицираните проблеми.

9.4.2 Критерии за ескалация

Установете критерии за това кога да ескалирате проблемите, а кога да продължите разследването:

Ескалирайте незабавно: Блокиращи вериги с продължителност >5 минути, време на процесора на 100% за >2 минути, критични системни процеси, показващи състояние SUSPENDED.
Ескалиране с анализ: Повтарящи се скъпи заявки, консумиращи >50% от процесора, постоянно високи времена за отговор на входно/изходни операции >50ms, многократни неуспешни заявки за памет.
Проучете допълнително: Временни чакания, разрешаващи се в рамките на минути, заявки с неоптимални планове, но с приемлива производителност, незначителни блокирания с продължителност <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 Мониторът на активността от 2005 г. беше далеч по-ограничен:

Достъпно през папката „Управление“ в Object Explorer, а не през лентата с инструменти
Единична решетка, показваща списък с процеси с основна информация
Няма графични диаграми или множество панели
Без скъпи заявки или наблюдение на входно/изходни данни
Ограничена информация за статистиката на чакането

Редизайнът от 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 Първоначално проучване с панел за общ преглед

Отворете „Монитор на активността“ и разгледайте панела „Общ преглед“:

Графиката за % време на процесора показва 85-95% използване на процесора, значително по-високо от нормалните 30-40% базови стойности.
Броят на чакащите задачи варира между 10 и 20, в сравнение с нормалната базова стойност от 0 до 3.
Входно-изходните операции от базата данни показват умерена активност около 50 MB/s.
Заявките за пакети/сек са по-ниски от очакваното при 100/сек, в сравнение с типичните 300-400/сек по време на работно време.

Този модел предполага затруднения на процесора с конфликт на ресурси, водещи до намалена пропускателна способност. Сървърът работи усилено, но не обработва много заявки.

11.1.2 Идентифициране на проблемната заявка

Разгънете панела „Последни скъпи заявки“ и сортирайте по „Изпълнения/мин“:

Най-често срещаната заявка показва 15 000 изпълнения в минута.
Щракнете с десния бутон и изберете Редактиране на текста на заявката да разгледа запитването.
Заявката е прост SELECT оператор, извличащ запис на един потребител: SELECT * FROM Users WHERE UserId = @UserId.
Тази заявка не трябва да се изпълнява 15 000 пъти в минута при нормална употреба на приложението.

Щракнете с десния бутон върху заявката и изберете Показване на план за изпълнениеПланът показва сканиране на таблицата Users с предупреждение за липсващ индекс в колоната UserId.

Филтрирайте панела „Процеси“ по приложение, за да се показват само връзките на уеб приложението. Няколко сесии показват, че една и съща заявка се изпълнява многократно.

11.1.3 Резолюция и проверка

Проблемът произтича от два фактора: прекомерен брой изпълнения на заявки и липсващ индекс. Стъпки за разрешаване:

Създайте липсващия индекс:

CREATE NONCLUSTERED INDEX IX_Users_UserId 
ON Users (UserId);

Свържете се с екипа за разработка относно прекомерните изпълнения. Разследването разкрива проблем с N+1 заявка в кода на приложението, при който цикъл извлича потребителски данни за всеки елемент в списък.
Променете приложението да групирате потребителските търсения в една заявка, използвайки клауза IN или параметър, който се използва като таблична стойност.
Проверете корекцията чрез наблюдение на Activity Monitor след внедряването. Натоварването на процесора спада до 35-40%, изпълненията в минута намаляват до 200-300 и времето за реакция на приложенията се връща към нормалното.

11.2 Казус: Разрешаване на проблем с блокиране

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

11.2.1 Откриване на блокиращата верига

Отворете „Монитор на активността“ по време на едно от тези събития на замръзване и разгънете панела „Процеси“:

Сортиране по Сесиен идентификатор за да видите всички организирани сесии.
Няколко сесии показват стойности в Блокирано от колона, всички сочещи към идентификатор на сесия 73.
Сесия 73 показва „1“ в Блокер за глава колона, потвърждавайки, че това е основната причина.
- Тип чакане За блокирани сесии показва LCK_M_X, което показва, че чакат ексклузивни заключвания.
- Изчакайте ресурс колоната показва, че блокирането е в таблицата „Поръчки“.

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

Щракнете с десния бутон върху Сесия 73 и изберете Детайли за да видите командата:

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

Тази актуализация е част от пакетна обработка, която се изпълнява на всеки час. Проверка на Вход колоната потвърждава, че сесията принадлежи към акаунта на услугата за пакетна обработка.

Заявката заключва таблицата „Поръчки“, докато обработва хиляди поръчки. Изчакайте време за блокирани сесии се увеличава постоянно, което потвърждава, че проблемът е в тази продължителна операция.

11.2.3 Внедряване на корекцията

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

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

Внедрени дългосрочни решения:

Препланирайте пакетната задача да се движи извън пиковите часове (2-4 сутринта вместо през работно време).
Променете пакетната обработка да актуализира поръчките на по-малки партиди от по 100 записа едновременно, освобождавайки заключванията между партидите.
Добавяне на индекс в колоната OrderId, за да ускорите операцията по актуализиране.
Помислете за изолация на SNAPSHOT за операции по четене, за да се намали блокиращото въздействие.

11.3 Казус: Идентифициране на прекомерни изпълнения на заявки

Мониторингът на базата данни показва, че използването на процесора постепенно се е увеличило през последния месец, но не са настъпили очевидни промени в кода на приложението.

11.3.1 Откриване на необичаен брой изпълнения

Отворете „Монитор на активността“ и разгледайте панела „Последни скъпи заявки“:

Сортиране по Изпълнения/мин за да видите най-често изпълняваните заявки.
Най-често срещаната заявка показва 37 000 изпълнения в минута – много повече от всяка друга заявка.
Щракнете с десния бутон и изберете Редактиране на текста на заявката.
Заявката извлича информация за категорията продукти:
```
SELECT CategoryId, CategoryName 
FROM ProductCategories 
WHERE CategoryId = @CategoryId;
```
Тази проста заявка би трябвало да е бърза и кешируема, но въпреки това се изпълнява десетки хиляди пъти в минута.

11.3.2 Проследяване до кода на приложението

В панела „Процеси“ намерете сесии, изпълняващи тази заявка:

Обърнете внимание на Приложение колоната показва „ProductCatalogService“.
Щракнете с десния бутон върху една от тези сесии и изберете Проследяване на процеса в SQL Server Profiler.
SQL Profiler разкрива, че заявката се изпълнява многократно в бърза последователност с различни стойности на CategoryId.
Свържете се с екипа за разработка, управляващ ProductCatalogService, за преглед на кода.

Прегледът на кода разкрива проблема: скорошна промяна извлича списъци с продукти с категории. За всеки продукт в резултатния набор (често над 1,000 продукта), кодът прави отделно извикване към базата данни, за да извлече информация за категорията – класически проблем със заявка N+1.

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

Приложете правилна корекция:

Промяна на заявката за приложение За да използвате 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;
```
Разполагане на актуализирания код и наблюдавайте Монитора на активността.
Проверете корекцията: Изпълненията в минута за заявката за категорията падат от 37 000 на под 100, а общото използване на процесора намалява с 40%.
Документирайте наученото и споделете с екипа за разработка, за да предотвратите подобни проблеми при бъдещи промени в кода.

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 Обобщение на ключовите точки

В това ръководство разгледахме как „Мониторът на активността“ ви помага да разберете и отстраните неизправности SQL Server производителност:

Activity Monitor осигурява видимост в реално време на процесите, чаканията, заявките и входно/изходните операции чрез организиран графичен интерфейс.
Петте панела – Общ преглед, Процеси, Чакане на ресурси, Входно-изходни операции с файлове с данни и Последни скъпи заявки – предлагат уникални перспективи за активността на сървъра.
Често срещани сценарии за отстраняване на неизправности, като прекомерно изпълнение на заявки, блокиращи вериги и високо натоварване на процесора, стават управляеми чрез систематично разследване на Activity Monitor.
Въпреки че е мощен, Activity Monitor има ограничения, включително липса на исторически данни, групиране по тип чакане и разходи за наблюдение, които влияят на неговата приложимост.
Допълването на Activity Monitor със заявки към DMV, sp_WhoIsActive, Extended Events и потенциално инструменти на трети страни създава цялостна стратегия за мониторинг.
Следването на най-добрите практики за интервали на обновяване, затварянето на Activity Monitor, когато не се използва, и комбинирането на множество панели за корелация увеличава максимално стойността му, като същевременно минимизира въздействието.

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

Мониторът на активността трябва да служи като инструмент за първа реакция при разследвания на производителността, а не като единствен инструмент. Силата му се състои в осигуряването на незабавна видимост по време на активно отстраняване на неизправности, като ви помага бързо да определите дали базата данни е пречката и да идентифицирате кои специфични аспекти се нуждаят от по-задълбочено проучване.

Мислете за Activity Monitor като за аналогия с таблото в колата ви – то ви казва веднага, ако нещо не е наред, и ви помага да идентифицирате общата област на безпокойство. Точно както таблото на колата ви не ви казва точно защо свети лампата за проверка на двигателя, Activity Monitor ви насочва към проблеми, без винаги да разкрива пълната им причина. Този по-задълбочен анализ изисква допълнителни инструменти и експертиза.

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

13.3 Продължаване на вашето учебно пътешествие

Овладяването на Activity Monitor е само една стъпка към това да станете ефективен администратор на бази данни. Продължете да развивате уменията си, като:

Да се научим да интерпретираме плановете за изпълнение и да идентифицираме неефективни операции
Разбирателство SQL Server статистика на чакането и нейните последици
Изучаване на техники за проектиране и оптимизация на индекси
Проучване SQL Serverархитектурата на и как обработва заявки
Практикуване на систематични методи за отстраняване на проблеми
Изграждане на опит с разширени събития за детайлно проследяване
Разбиране на нивата на изолация на транзакциите и тяхното влияние върху производителността

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

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

Разширете знанията си с тези ценни ресурси:

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

14. Често задавани въпроси (FAQ)

Въпрос: Какво е SQL Server ActivityMonitor?

A: SQL Server Мониторът на активността е вграден инструмент в SQL Server Management Studio, което показва информация в реално време за процесите, изпълнявани на SQL Server екземпляр и тяхното въздействие върху сървърните ресурси. Той предоставя графично табло с пет панела, показващи различни аспекти на сървърната активност, включително използване на процесора, чакащи задачи, скорости на входно/изходни операции, активни сесии и скъпи заявки.

В: Как да отворя Монитор на активността в SSMS?

A: Можете да отворите Activity Monitor, като използвате четири метода: (1) Щракнете върху иконата Activity Monitor в лентата с инструменти на SSMS, (2) Щракнете с десния бутон върху SQL Server име на екземпляр в Object Explorer и изберете Дейност Monitor, (3) Натиснете Ctrl + Друг + Aили (4) Конфигурирайте SSMS да го стартира автоматично чрез Инструменти -> Опции -> Заобикаляща среда -> Startup.

В: Какви разрешения са ми необходими, за да използвам Activity Monitor?

A: Нуждаете се от ПРЕГЛЕД НА СЪСТОЯНИЕТО НА СЪРВЪРА разрешение за преглед на по-голямата част от информацията от Монитора на активността. За панела за вход/изход на файлове с данни също ви е необходимо едно от двете СЪЗДАЙТЕ БАЗА ДАННИ, ПРОМЕНЯНЕ НА ВСЯКА БАЗА ДАННИ или ВИЖТЕ ВСЯКО ОПРЕДЕЛЕНИЕ разрешения. Без тези разрешения, „Мониторът на активността“ може да се отвори, но да показва празни панели.

В: Защо моят Монитор на активността е на пауза или не работи?

A: Мониторът на активността обикновено спира поради проблеми с разрешенията, остарели версии на SSMS или деактивирани отдалечени връзки. За да разрешите проблема: (1) Актуализирайте до най-новата версия на SSMS, (2) Проверете дали имате разрешение за ПРЕГЛЕД НА СЪСТОЯНИЕТО НА СЪРВЪРА, (3) Проверете дали отдалечените връзки са активирани на SQL Server например, (4) Рестартирайте SSMS и (5) Опитайте да се свържете с Windows удостоверяване вместо SQL удостоверяване, ако е приложимо.

В: Каква е разликата между Activity Monitor и sp_WhoIsActive?

A: Activity Monitor е графичен инструмент, вграден в SSMS, предоставящ организирани панели за различни аспекти на наблюдение. sp_WhoIsActive е безплатна съхранена процедура, създадена от общността, която връща подробна информация за сесията в един набор от резултати с по-специфични типове чакане, подробности за блокиране и опции за персонализиране от Activity Monitor. Activity Monitor е по-добър за визуално проучване, докато sp_WhoIsActive се отличава със скриптово наблюдение и предоставя по-подробна информация.

В: Влияе ли Мониторът на активността на производителността на сървъра?

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. Можете да заявите тези DMV директно, използвайки T-SQL, за да извлечете еквивалентна информация програмно, което позволява персонализирани скриптове за наблюдение и автоматизирано събиране на данни.

В: Какъв е интервалът на обновяване по подразбиране?

A: Интервалът на обновяване по подразбиране е 10 секунди. Можете да промените това, като щракнете с десния бутон някъде в панела „Общ преглед“ и изберете Интервал на обновяванеи избор от предварително дефинирани опции: 1 секунда, 5 секунди, 10 секунди, 30 секунди, 1 минута или 1 час. По-малките интервали осигуряват повече изгледи в реално време, но увеличават натоварването от наблюдение.

В: Как мога автоматично да отворя Монитора на активността при стартиране на SSMS?

A: Конфигуриране на автоматично стартиране чрез опции за SSMS: Отидете до Инструменти -> Опции -> Заобикаляща среда -> Startup, След което изберете Отворете Object Explorer и Activity Monitor от При стартиране падащо меню. Мониторът на активността ще се отваря автоматично всеки път, когато се свържете със сървър в SSMS.

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

A: Ключовите ограничения включват: (1) Няма възможности за съхранение на исторически данни или проследяване на тенденции, (2) Типовете чакания са групирани в категории, а не са показани конкретно, (3) Някои типове чакания, като CXPACKET, може да не се появят, (4) Моментните снимки към даден момент може да пропускат временни проблеми, (5) Разходите за наблюдение могат да повлияят на натоварените сървъри, (6) Няма механизъм за предупреждение за проактивно наблюдение и (7) Не могат да се обобщават данни от множество сървъри SQL Server случаи. За тези нужди допълнете Activity Monitor с Extended Events, набори за събиране на данни или инструменти за наблюдение на трети страни.

За автора

Юан Шенг е старши администратор на бази данни (DBA) с над 10 години опит в SQL Server среди и управление на корпоративни бази данни. Той е разрешил успешно стотици сценарии за възстановяване на бази данни във финансови услуги, здравеопазване и производствени организации.

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

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

Имате въпроси относно SQL Server възстановяване или имате нужда от допълнителни насоки за отстраняване на проблеми с базата данни? Юан приветства обратна връзка и предложения за подобряване на тези технически ресурси.