SQL Server Монітор активності: повний посібник для адміністраторів баз даних [2026]

1. Введення

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

SQL Server Монітор активності – це вбудована діагностична функціяostінструмент ic всередині SQL Server Студія управління, яка відображає інформацію про SQL Server процеси та їхній вплив на продуктивність сервера. Це дозволяє відстежувати SQL Server процеси, моніторити очікування ресурсів, аналізувати ресурсомісткі запити та спостерігати за шаблонами вводу/виводу — все це з єдиного інтерфейсу.

1.2 Чому варто використовувати SQL Server Монітор активності?

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

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

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

1.3 Монітор активності проти інших інструментів моніторингу

Хоча Монітор активності є цінним, важливо розуміти, як він порівнюється з іншими варіантами моніторингу:

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

Монітор активності проти sp_who2: Традиційна команда sp_who2 показує основну інформацію про сеанс, але Activity Monitor йде далі, відображаючи статистику очікування, ресурсомісткі запити та метрики вводу/виводу в організованому візуальному форматі.

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

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

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

• Нуль Cost: Як вбудований SQL Server Функція Management Studio не вимагає ліцензійної плати чи зусиль щодо розгортання.
• Моніторинг у реальному часі: Переглядайте поточну активність сервера в міру її виникнення, завдяки налаштованим інтервалам оновлення від 1 секунди до 1 години.
• Інтегровані дії: Клацніть правою кнопкою миші на процесах, щоб завершити сеанси, переглянути деталі запиту або запустити їх. SQL Server Трасування профайлера — все це з інструменту.
• Кілька перспектив: Переглядайте стан сервера з різних точок зору за допомогою п'яти спеціалізованих панелей, кожна з яких зосереджена на певних аспектах продуктивності.
• Швидке усунення несправностей: Визначте мost поширені проблеми з продуктивністю протягом кількох хвилин, що прискорює середній час їх вирішення.
• Низький бар'єр для входу: Для ефективного використання інструменту не потрібні поглиблені знання, хоча й SQL Server експертний досвід допомагає з інтерпретацією.

2. Отримання Starз монітором активності

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

2.1 Передумови та системні вимоги

використовувати SQL Server Монітор активності, вам потрібен SQL Server Management Studio (SSMS), встановлено на вашому локальному комп’ютері або сервері jump. Інструмент Activity Monitor було значно перероблено в SQL Server 2008 року, тому інформація в цьому посібнику стосується SQL Server 2008 та новіші версії.

Ви повинні мати мережеве підключення до SQL Server екземпляр, який ви хочете моніторити. Для cloud-hostДля доступу до екземпляра баз даних, як правило, потрібне VPN-з’єднання або належним чином налаштовані правила брандмауера.

Монітор активності працює з усіма випусками SQL Server, включаючи Express, Standard та Enterprise. Сам інструмент працює на клієнтському комп’ютері в SSMS, тому на ресурси сервера впливають лише запити моніторингу, які він виконує.

2.2 Необхідні дозволи

Для коректної роботи Монітора активності необхідні відповідні дозволи. Без відповідних прав ви можете побачити порожній екран або помилки "доступ заборонено".

2.2.1 Дозвіл на перегляд стану сервера

Команда ПЕРЕГЛЯНУТИ СТАН СЕРВЕРА Дозвіл є основною вимогою для використання Монітора активності. Цей дозвіл на рівні сервера дозволяє переглядати всі активні процеси та пов’язані з ними показники.

Щоб надати цей дозвіл, адміністратор сервера може виконати:

GRANT VIEW SERVER STATE TO [YourLoginName];

Без параметра VIEW SERVER STATE (ПЕРЕГЛЯД СТАНУ СЕРВЕРА) Монітор активності може відкриватися, але не відображати дані в жодній зі своїх панелей.

2.2.2 Дозволи на рівні бази даних

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

• CREATE DATABASE дозвіл, або
• ЗМІНИТИ БУДЬ-ЯКУ БАЗУ ДАНИХ дозвіл, або
• ПЕРЕГЛЯНУТИ БУДЬ-ЯКЕ ВИЗНАЧЕННЯ дозвіл

Ці дозволи мають бути поєднані з ПЕРЕГЛЯНУТИ СТАН СЕРВЕРА для повної функціональності Монітора активності.

2.2.3 Виправлення неполадок із дозволами

Якщо Монітор активності відкривається, але не відображає даних, це означає, що дозволиost поширена причина. Перевірте, чи вашому входу надано 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: З панелі інструментів

Найшвидший спосіб відкрити Монітор активності – це скористатися значком на панелі інструментів:

1. Підключіться до свого SQL Server приклад у SQL Server Студія управління.
2. Знайдіть піктограму «Монітор активності» на стандартній панелі інструментів (вона схожа на стовпчасту діаграму із зеленою кнопкою відтворення).
3. Клацніть значок, щоб запустити Монітор активності.

Цей метод найшвидший, якщо ви вже працюєте в SSMS і вам потрібно швидко перевірити активність сервера.

2.3.2 Спосіб 2: З Провідника об'єктів

Ви також можете запустити Монітор активності безпосередньо з Провідника об'єктів:

1. У провіднику об'єктів знайдіть SQL Server екземпляр, який ви хочете моніторити.
2. Клацніть правою кнопкою миші на назві екземпляра.
3. Виберіть Activity Monitor з контекстного меню.

Цей метод корисний під час підключення до кількох серверів, оскільки він гарантує, що ви контролюєте правильний екземпляр.

2.3.3 Спосіб 3: Використання комбінації клавіш

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

1. Переконайтеся, що SSMS є активним вікном, і ви підключені до екземпляра.
2. Натисніть Ctrl + інший + A.
3. Монітор активності відкриється для поточного вибраного екземпляра в Провіднику об'єктів.

Зверніть увагу, що Монітор активності підключиться до будь-якого екземпляра сервера, який ви вибрали в Провіднику об'єктів, тому переконайтеся, що ви вибрали правильний екземпляр, перш ніж використовувати це скорочення.

2.3.4 Спосіб 4: З меню параметрів (Starконфігурація tup)

Якщо ви часто використовуєте Монітор активності, ви можете налаштувати SSMS на його автоматичний запуск щоразу, коли виtarзастосування:

1. In SQL Server Студія управління, перейдіть до Інструменти -> Опції.
2. У діалоговому вікні «Параметри» розгорніть Навколишнє середовище, А потім виберіть Starтрубка.
3. Від На сtarтрубка спадний список, виберіть Відкрийте Провідник об'єктів та Монітор активності.
4. Виберіть OK.

Під час наступного запуску SSMS та підключення до сервера, Монітор активності відкриється автоматично разом із Провідником об’єктів.

3. Розуміння панелей монітора активності

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

3.1 Панель огляду

На панелі «Огляд» представлено чотири графіки в режимі реального часу, які дають вам швидке уявлення про стан вашого здоров’я. SQL Server наприклад. Ці графіки оновлюються з налаштованим інтервалом і допомагають вам одразу виявити аномальні закономірності.

3.1.1 % часу процесора

Цей графік показує відсоток часу, який процесор витрачає на виконання потоків, що не перебувають у стані простою, для SQL Server екземпляр на всіх процесорах. Значення представляє SQL Serverвикористання процесора, а не використання процесора всього сервера.

Якщо ви постійно бачите, що час процесора становить 100% або близько до нього, ваш сервер обмежений ресурсами процесора. Це може свідчити про неефективні запити, відсутні індекси або недостатню потужність обладнання. Використовуйте панель «Нещодавні дорогі запити», щоб визначити, які запити споживають ресурси процесора.ost CPU.

3.1.2 Завдання очікування

Ця метрика відображає кількість завдань, які очікують на вивільнення ресурсів, перш ніж зможуть продовжити свою роботу. Завдання можуть очікувати на процесор, операції вводу/виводу, пам'ять або блокування.

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

3.1.3 Введення/виведення даних (МБ/с)

Цей графік показує швидкість передачі даних між пам'яттю та диском. Він поєднує як зчитування, так і запис, вимірюється в мегабайтах за секунду.

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

3.1.4 Пакетні запити/сек

Цей показник відображає кількість SQL Server кількість пакетів, отриманих екземпляром за секунду. Пакет може бути одним оператором або кількома операторами, надісланими разом.

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

3.1.5 Налаштування інтервалів оновлення

Ви можете налаштувати частоту оновлення даних Монітора активності:

1. Клацніть правою кнопкою миші будь-де в області «Огляд».
2. Виберіть Інтервал оновлення.
3. Виберіть інтервал із попередньо визначених значень: 1 секунда, 5 секунд, 10 секунд (за замовчуванням), 30 секунд, 1 хвилина або 1 година.

Встановлення інтервалів оновлення менше 10 секунд збільшує навантаження на моніторинг вашого сервера. Для виробничих систем з високим навантаженням варто використовувати інтервали 30 секунд або довше, щоб мінімізувати вплив.

3.2 Панель «Процеси»

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

3.2.1 Розуміння інформації про процес

Кожен рядок на панелі «Процеси» представляє активний сеанс на сервері. Панель відображає сеанси з усіх баз даних та всіх користувачів, що дає вам повне уявлення про активність сервера.

Відображена інформація включає ім'я користувача для входу, назву програми, hostім'я, база даних, до якої здійснюється доступ, і поточна команда. Це допомагає вам співвіднести активність бази даних із певними користувачами або програмами.

3.2.2 Пояснення ключових стовпців

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

• ID сеансу: Унікальний ідентифікатор для кожного з’єднання. Системні процеси використовують негативні ідентифікатори сеансів.
• Процес користувача: Вказує, чи це сеанс користувача (Так), чи системний процес (Ні).
• Вхід: Команда SQL Server ім'я користувача або обліковий запис Windows, пов'язаний із сеансом.
• База даних: Поточний контекст бази даних для сеансу.
• Стан завдання: Показує поточну активність сеансу (ЗАПУСК, ПРИЗУПИНЕНИЙ, СОН тощо).
• команда: Тип виконуваної команди (SELECT, INSERT, UPDATE тощо).
• Застосування: Назва програми, яка створила з’єднання.
• Час очікування: Як довго (у мілісекундах) сеанс чекає на ресурси.
• Тип очікування: Конкретний тип ресурсу, на який очікує сеанс.
• Час процесора: Загальний час процесора, спожитий цим сеансом з моменту підключення.
• Використання пам'яті: Об'єм пам'яті (у КБ), що наразі виділений для сеансу.

3.2.3 Процеси фільтрації та сортування

Панель «Процеси» містить потужні можливості фільтрації, які допоможуть вам зосередитися на відповідних сеансах:

1. Клацніть стрілку спадного списку в будь-якому заголовку стовпця.
2. Фільтр показує доступні значення для цього стовпця, зокрема ВСІ, Бланки та Непорожні.
3. Виберіть певні значення, щоб відфільтрувати відображення лише за цими сеансами.

Наприклад, ви можете фільтрувати Стан завдання щоб відобразити лише ЗАПУСКАНІ сеанси або відфільтрувати Database щоб побачити активність у певній базі даних.

Ви також можете сортувати за будь-яким стовпцем, клацнувши його заголовок. Клацніть один раз для сортування у порядку зростання, двічі для сортування у порядку спадання.

3.2.4 Визначення блокування та заблокованих сеансів

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

• Заблоковано: Показує ідентифікатор сеансу, який блокує цей сеанс. Якщо цей стовпець містить значення, сеанс очікує на блокування, яке утримується іншим сеансом.
• Блокувальник голови: Відображає «1», якщо цей сеанс блокує інші, але сам не заблокований. Це є основною причиною ланцюжка блокування.

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

3.2.5 Дії процесу (Знищення, Деталізація, Трасування)

Монітор активності дозволяє виконувати дії в окремих сеансах:

1. Клацніть правою кнопкою миші на будь-якому сеансі в області «Процеси».
2. Ви побачите кілька варіантів:
   • Подробиці: Показує останню команду, виконану в цьому сеансі.
   • Процес знищення: Завершує сеанс (використовувати з обережністю).
   • Трасування процесу в SQL Server профайлер: Запуски SQL Server Профіль і автоматично фільтрує, щоб відображати лише активність із цього сеансу.

Опція «Деталі» показує текст команди, але зверніть увагу, що це останній команда виконана — можливо, вона ще не виконується. Опція «Трасування» особливо корисна, коли вам потрібно побачити повну послідовність команд, які виконує сеанс.

3.3 Панель очікування ресурсів

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

3.3.1 Розуміння статистики очікування

Коли SQL Server не може негайно задовольнити запит на ресурс (наприклад, блокування, час процесора або пам'ять), завдання-запитувач переходить у стан очікування. Статистика очікування відстежує ці періоди очікування та допомагає зрозуміти, де сервер витрачає час на очікування, а не на роботу.

Панель «Очікування ресурсів» збирає дані з подань динамічного керування системою, таких як sys.dm_os_wait_stats та sys.dm_exec_requests. З кожним інтервалом оновлення обчислюється різниця між поточним і попереднім знімками, показуючи швидкість накопичення для кожного типу очікування.

3.3.2 Категорії очікування

Монітор активності об’єднує сотні окремих типів очікування в ширші категорії для спрощення інтерпретації:

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

Хоча таке групування спрощує вигляд, воно також приховує важливі деталі. Наприклад, «Buffer Latch» може об’єднувати очікування PAGELATCH_SH, PAGELATCH_UP та PAGELATCH_EX, які мають різні наслідки для продуктивності.

3.3.3 Інтерпретація часу очікування та завдань очікування

В області «Очікування ресурсів» відображається два ключові показники для кожної категорії очікування:

• Сукупний час очікування (мс): Загальна кількість мілісекунд, накопичених протягом поточного інтервалу оновлення для цієї категорії очікування.
• Завдання очікування: Кількість завдань, які наразі очікують на ресурси в цій категорії.

Значення часу очікування є особливо цікавим. Якщо у вас є 10-секундний інтервал оновлення та ви бачите 20 000 мс часу очікування для категорії, це вказує на кілька одночасних очікувань (20 000 мс / 10 000 мс = середнє значення 2 одночасних очікувань протягом інтервалу).

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

Використовуйте панель «Очікування ресурсів», щоб визначити, де ваш сервер витрачає час.ost час очікування:

1. Розгорніть область «Очікування ресурсів».
2. Зверніть увагу на категорії очікування, які накопичують найвищий час очікування.
3. Сортувати за Сукупний час очікування щоб побачити, які ресурси most обмежений.

Очікування з високим рівнем буферної фіксації часто вказує на конфлікт за сторінки даних у пам'яті, що може свідчити про вузькі місця вводу-виводу або конфлікти за тимчасову базу даних. Очікування з високим рівнем блокування вказує на проблеми з блокуванням. Очікування з високим рівнем пам'яті вказує на недостатню кількість виділеної пам'яті для операцій запитів.

3.4 Панель вводу/виводу файлів даних

Панель вводу/виводу файлів даних відображає активність диска для кожного файлу бази даних на вашому сервері, що допомагає виявляти вузькі місця вводу/виводу та розуміти закономірності використання диска.

3.4.1 Розуміння метрик вводу/виводу

Панель вводу/виводу файлів даних відображає кілька показників для кожного файлу бази даних:

• База даних: Ім'я бази даних.
• Тип файлу: Або Дані (включно з таблицями та індексами), або Журнал (журнал транзакцій).
• Логічне ім'я: Логічне ім'я файлу, як визначено в SQL Server.
• Зчитування, МБ/с: Швидкість зчитування даних з цього файлу.
• МБ/сек записаного: Швидкість запису даних у цей файл.
• Час відгуку (мс): Середній час відгуку для операцій вводу/виводу для цього файлу.

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

3.4.2 Виявлення вузьких місць вводу/виводу

Зверніть увагу на ці закономірності, які вказують на проблеми з продуктивністю вводу/виводу:

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

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

Використовуйте панель вводу/виводу файлів даних, щоб зрозуміти, як ваші бази даних використовують дискові ресурси:

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

3.5 Панель «Нещодавні дорогі запити»

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

3.5.1 Розуміння показників запитів

Монітор активності відображає кілька показників для кожного дороговартісного запиту:

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

Ці показники допомагають вам зрозуміти не лише, які запити є дорогими, але й чому вони дорогі та як часто вони їздять.

3.5.2 Параметри сортування

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

1. Клацніть будь-який заголовок стовпця, щоб відсортувати за цим показником.
2. Поширені стратегії сортування включають:
   • Сортувати за процесором: Знайти запити, що використовують most час процесора.
   • Сортувати за Виконаннями/хв: Визначте запити, які виконуються надмірно часто.
   • Сортувати за фізичним зчитуванням: Знайдіть запити, що викликають помилку most дисковий ввід/вивід.
   • Сортувати за середньою тривалістю: Знайдіть довготривалі запити.

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

3.5.3 Перегляд тексту запиту

Щоб побачити фактичний SQL-запит, що стоїть за складним запитом:

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

Це дозволяє вам дослідити логіку запиту та визначити потенційні можливості для оптимізації. Потім ви можете скопіювати текст запиту для тестування змінених версій.

3.5.4 Аналіз планів виконання

Плани виконання показують, як SQL Server виконує запит, виявляючи неефективність, таку як відсутні індекси або невідповідні типи об'єднань:

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

Шукайте операції, які споживають великий відсоток запиту cost, попередження про відсутню статистику або індекси, а також неочікувані операції сканування таблиць. Вони часто вказують на те, на чому слід зосередити зусилля з оптимізації.

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

Зверніть увагу на ці закономірності в області «Нещодавні дорогі запити»:

• Надмірні страти: Запит, що виконується тисячі разів на хвилину, може свідчити про проблему запитів N+1, коли код програми викликає базу даних усередині циклу.
• Високі фізичні показники читання: Запити з високою швидкістю фізичного читання часто потрапляють на диск, що свідчить про відсутні індекси або погано написані запити.
• Високий процесор з низькою тривалістю роботи: Багато швидких запитів, що споживають багато ресурсів процесора, можуть впливати на продуктивність сервера так само сильно, як і кілька повільних запитів.
• Кілька підрахунків планів: Запити з багатьма планами виконання можуть мати проблеми з перехопленням параметрів або непараметризовані запити, що спричиняють роздування кешу планів.

4. Використання монітора активності для усунення несправностей продуктивності

Монітор активності справді сяє, коли ви використовуєте його систематично для діагностики та вирішення проблем продуктивності. У цьому розділі розглядаються поширені сценарії усунення несправностей та способи їх вирішення.

4.1 Діагностика надмірного виконання запитів

Один з нихost Поширеною проблемою продуктивності є виконання запитів набагато частіше, ніж необхідно, часто через проблеми з проектуванням застосунків.

4.1.1 Визначення повторюваних запитів

Щоб виявити запити, які виконуються занадто часто:

1. Відкрийте Монітор активності та розгорніть Нещодавні дорогі запити панель
2. Сортувати за Виконань/хв (виконань за хвилину).
3. Шукайте запити зверху з кількістю виконань, яка здається необґрунтовано високою.
4. Клацніть правою кнопкою миші підозрілий запит і виберіть Редагувати текст запиту щоб перевірити SQL-запит.

Наприклад, якщо ви бачите простий оператор SELECT, який виконується 37 000 разів на хвилину, запитайте себе, чи дійсно програмі потрібно викликати цей запит так часто. Most запити, що виконуються більше кількох тисяч разів на хвилину, потребують розслідування.

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

Надмірне виконання запитів зазвичай виникає через такі проблеми:

• Задача запиту N+1: Код застосунку отримує список елементів, а потім виконує окремий запит для кожного елемента, щоб отримати пов'язані дані. Це створює N додаткових запитів, де N – кількість елементів.
• Відсутнє кешування: Програма запитує дані з бази даних, які rarзмінюється замість того, щоб кешувати його в пам'яті програми.
• Цикли опитування: Код неодноразово запитує базу даних, перевіряючи зміни стану, замість того, щоб використовувати сповіщення про зміни або черги повідомлень.
• Неефективність управління операційними системами (ORM): Entity Framework та подібні інструменти іноді генерують неефективні шаблони запитів, коли розробники не розуміють, як їхній код перетворюється на SQL.

Щоб визначити першопричину, простежте запит до коду програми. Зверніть увагу на додаток та Увійти стовпці в області «Процеси» під час виконання запиту. Ви також можете клацнути процес правою кнопкою миші та вибрати Трасування процесу в SQL Server Профіль щоб побачити закономірність дзвінків.

4.1.3 Рішення та найкращі практики

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

• Пакетна обробка: Змініть код програми, щоб отримувати кілька елементів в одному запиті за допомогою об'єднань або речень IN, а не виконувати окремі запити в циклі.
• Кешування результатів: Кеш часто використовується, дані в пам'яті програми рідко змінюються з відповідним часом закінчення терміну дії.
• Охоче ​​завантаження: Налаштуйте ORM для використання стратегій швидкого завантаження, які витягують пов'язані дані за меншу кількість ефективніших запитів.
• Параметризація запиту: Переконайтеся, що запити використовують параметри, а не об'єднують значення, що покращує повторне використання кешу планів та зменшує накладні витрати на компіляцію.

4.2 Дослідження проблем блокування

Блокування відбувається, коли один сеанс утримує блокування, що перешкоджає продовженню інших сеансів. Це проявляється у повільному часі відгуку програм та розчаруванні користувачів.

4.2.1 Визначення ланцюгів блокування

Щоб виявити та проаналізувати блокування:

1. Відкрийте Монітор активності та розгорніть процеси панель
2. Шукайте сеанси зі значеннями в Заблоковано стовпець — вони очікують на блокування, утримувані іншими сеансами.
3. Знайти сеанси з '1' у Блокувальник голови колонка — це основна причина блокування ланцюгів.
4. Зверніть увагу на Ідентифікатор сеансу блокувальника голови.
5. Клацніть правою кнопкою миші сеанс блокування голови та виберіть ПОДРОБИЦІ щоб побачити, яку команду він виконує.

Розуміння ланцюжка блокування є критично важливим. Головний блокувальник – це сеанс, який вам потрібно дослідити, а не заблоковані сеанси нижче за течією.

4.2.2 Розуміння типів блокувань

Команда Тип очікування У стовпці на панелі «Процеси» вказується, на який тип блокування очікують заблоковані сеанси:

• LCK_M_X: Очікування ексклюзивного блокування, зазвичай спричинене операціями UPDATE, DELETE або INSERT.
• LCK_M_S: Очікування спільного блокування, зазвичай це оператори SELECT, які очікують звільнення ексклюзивних блокувань.
• LCK_M_U: Очікування блокування оновлення – проміжний тип блокування, який використовується під час оновлень.
• LCK_M_IX: Очікування ексклюзивного блокування Intent, що вказує на конкуренцію за блокування на рівні сторінки або рядка.

Команда Ресурс очікування У стовпці показано, який об'єкт бази даних блокується, що допомагає зрозуміти, яка таблиця або індекс бере участь у конфлікті.

4.2.3 Вирішення проблем блокування

Після того, як ви визначили блокувальний сеанс та його дії, у вас є кілька варіантів:

1. Дочекайтеся завершення: Якщо блокувальник заголовків виконує легітимний запит, який незабаром завершиться, можливо, краще дозволити йому завершитися природним шляхом.
2. Завершити сеанс: Якщо блокувальник заголовків застряг або виконує запит, який слід скасувати:
   • Клацніть правою кнопкою миші сеанс на панелі «Процеси».
   • Виберіть вбити процес.
   • Підтвердіть дію в діалоговому вікні.
3. Оптимізація запитів: Якщо блокування повторюється для тих самих запитів, оптимізуйте їх, щоб зменшити тривалість блокування.
4. Налаштування рівнів ізоляції: Розгляньте можливість використання ізоляції знімків, зафіксованих при читанні, щоб зменшити блокування під час робочих навантажень з великим обсягом читання.
5. Налаштування індексу: Додайте індекси для пришвидшення запитів, зменшуючи час утримання блокувань.

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

Коли в області «Огляд» час процесора постійно відображається на рівні 100% або близькому до нього, потрібно визначити, які запити відповідають за це, та визначити, чи можна їх оптимізувати.

4.3.1 Визначення запитів, що ресурсомісткі для процесора

Щоб знайти запити, що споживають надмірну кількість ресурсів процесора:

1. Відкрийте Нещодавні дорогі запити панель
2. Сортувати за Процесор (мс/сек) щоб відобразити запити за допомогою most час процесора.
3. Перегляньте найпопулярніші запити у списку.
4. Клацніть правою кнопкою миші на запитах з високим навантаженням на процесор і виберіть Редагувати текст запиту щоб переглянути SQL-запит.
5. Виберіть Показати план виконання щоб зрозуміти, як виконується запит.

Звертайте увагу не лише на використання процесора окремими запитами, але й на Виконань/хв стовпець. Запит, який використовує помірне навантаження на процесор на виконання, але виконується тисячі разів на хвилину, може бути найбільшим споживачем процесора.

4.3.2 Методи оптимізації запитів

Поширені методи зменшення споживання процесора включають:

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

4.4 Дослідження проблем з пам'яттю

Навантаження пам'яті може призвести до перекидання запитів на диск, що значно знижує продуктивність. Монітор активності допомагає виявляти операції, що ресурсомістко використовують пам'ять.

4.4.1 Розуміння показників пам'яті

Команда Використання пам'яті У стовпці «Процеси» на панелі «Процеси» показано обсяг пам’яті, виділеної для кожного сеансу, у кілобайтах. Високе використання пам’яті одним сеансом часто вказує на:

• Великі операції сортування або хешування, які не помістилися в початково виділену пам'ять
• Запити, що отримують величезні набори результатів
• Надмірний паралелізм, що створює багато копій операторів плану виконання
• Витоки пам'яті в збережених процедурах або функціях CLR

В області «Очікування ресурсів» може відображатися повідомлення «Очікування пам’яті», коли запити не можуть отримати достатньо грантів пам’яті та мають чекати, поки пам’ять стане доступною.

4.4.2 Визначення запитів, що ресурсомісткі до пам'яті

Щоб знайти запити, що перевантажують пам'ять:

1. Перейдіть на вкладку процеси панель, сортувати за Використання пам'яті щоб побачити сеанси, що використовують мost пам'ять.
2. Клацніть правою кнопкою миші сеанси з високим використанням пам'яті та виберіть ПОДРОБИЦІ щоб переглянути їхні запити.
3. Перейдіть на вкладку Нещодавні дорогі запити області, шукайте запити з високим Логічне читання or Логічні записи, оскільки вони часто корелюють з використанням пам'яті.
4. Розгляньте плани виконання для операторів сортування та хешування, які використовують гранти пам'яті.

Запити, що відображають попередження «Грант пам'яті» в планах виконання або попередження про розлив, вказують на проблеми з навантаженням на пам'ять.

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

Коли користувачі повідомляють про повільний час відгуку програм, Монітор активності допомагає визначити, чи є база даних вузьким місцем.

4.5.1 Зв'язок монітора активності з проблемами програм

Щоб дослідити повільність роботи програми:

1. Зверніть увагу на точний час, коли користувачі повідомляють про проблеми, та на які програми це впливає.
2. Відкрийте Монітор активності та перевірте Огляд панель для піків ресурсів у цей час.
3. Перейдіть на вкладку процеси панель, фільтрувати за додаток щоб відображати лише з’єднання з відповідної програми.
4. Шукайте високий Час очікування значення, які вказують на затримки бази даних.
5. Оберіть Нещодавні дорогі запити панель для запитів від цієї програми, яка споживає значні ресурси.

Якщо база даних не показує незвичайної активності, тоді як користувачі відчувають уповільнення роботи, проблема, ймовірно, полягає в коді програми, затримці мережі або продуктивності на стороні клієнта.

4.5.2 Виявлення неефективних шаблонів застосування

Монітор активності виявляє кілька антипаттернів у дизайні додатків:

• Балакучі програми: Багато дрібних запитів замість меншої кількості ефективніших запитів. Визначається великою кількістю підключень та численними простими запитами в розділі "Нещодавні дорогі запити".
• N+1 запитів: Один запит, а потім N додаткових запитів для пов'язаних даних. Відображається як простий запит з надзвичайно високою кількістю виконань за хвилину.
• Великі набори результатів: Програми отримують набагато більше даних, ніж потрібно. Шукайте високий Логічне читання у поєднанні з простими запитами SELECT *.
• Відсутні тайм-аути: Програми, які не встановлюють тайм-аути команд, можуть залишати з’єднання відкритими на невизначений термін, що відображатиметься як тривалі сеанси на панелі «Процеси».

5. Альтернативні методи: отримання даних монітора активності через T-SQL

Хоча Монітор активності надає зручний графічний інтерфейс, іноді потрібно отримувати еквівалентну інформацію програмно або створювати власні рішення для моніторингу.

5.1 Використання динамічних подань управління (DMV)

SQL Server надає інформацію про активність через динамічні подання керування, які Монітор активності запитує за лаштунками.

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

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

• sys.dm_exec_requests: Показує поточні виконувані запити з інформацією про процесор, ввод-вивод та очікування.
• sys.dm_exec_sessions: Містить інформацію на рівні сеансу, таку як ім'я користувача, host назва та назва програми.
• sys.dm_os_wait_stats: Надає сукупну статистику очікування для всього екземпляра.
• sys.dm_exec_query_stats: Містить сукупну статистику продуктивності для кешованих запитів.
• sys.dm_io_virtual_file_stats: Повертає статистику вводу/виводу для даних та файлів журналів.
• sys.dm_exec_sql_text: Отримує SQL-текст для заданого sql_handle або plan_handle.
• sys.dm_exec_query_plan: Повертає план виконання для кешованого запиту.

5.1.2 Зразки запитів для отримання інформації про процес

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

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

5.1.3 Зразки запитів для статистики очікування

Щоб переглянути статистику очікування, подібну до панелі «Очікування ресурсів»:

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

5.2 Використання sp_WhoIsActive

sp_WhoIsActive — це потужна збережена процедура, створена спільнотою, яка надає детальнішу інформацію, ніж Монітор активності, в одному наборі результатів.

5.2.1 Встановлення sp_WhoIsActive

Щоб встановити sp_WhoIsActive:

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

Оскільки sp_WhoIsActive інстальовано в головному сервері, він доступний з будь-якого контексту бази даних.

5.2.2 Основні приклади використання

Найпростіший спосіб використання sp_WhoIsActive:

EXEC sp_WhoIsActive;

Це повертає набір результатів, що відображає всі активні сеанси з їхніми запитами, типами очікування, інформацією про блокування та використанням ресурсів.

Для 10-секундного зразка, що показує активність протягом цього періоду:

EXEC sp_WhoIsActive @delta_interval = 10;

Це обчислює дельти для таких показників, як використання процесора та кількість читань, показуючи, що сталося протягом цих 10 секунд.

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

sp_WhoIsActive підтримує численні параметри для налаштування:

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

Приклад, що показує плани, відсортовані за процесором:

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

5.3 Використання системних збережених процедур

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

5.3.1 sp_who та sp_who2

Процедура sp_who показує основну інформацію про сеанс:

EXEC sp_who;

Процедура sp_who2 надає трохи більше деталей:

EXEC sp_who2;

Обидві процедури показують ідентифікатори сеансів, імена користувачів, час використання процесора та інформацію про блокування. Однак їм бракує детальної інформації, доступної через DMV або монітор активності. Вони...ost корисно для швидких перевірок, коли вам терміново потрібна мінімальна інформація.

5.3.2 Інші корисні системні процедури

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

• sp_lock: Показує інформацію про блокування (застаріло; замість цього використовуйте sys.dm_tran_locks).
• sp_monitor: Відображає статистику щодо SQL Server діяльності.
• sp_довідка: Показує визначення об'єктів та метадані.
• DBCC SQLPERF: Відображає використання простору журналу транзакцій та статистику очікування.

5.4 Створення власних сценаріїв моніторингу

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

5.4.1 Повний еквівалентний скрипт монітора активності

Ось комплексний сценарій, який повторює most Функціональність монітора активності:

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

1. Створіть таблицю для зберігання результатів моніторингу.
2. Змініть свій скрипт моніторингу, щоб вставити результати в цю таблицю.
3. In SQL Server Студія управління, розгорнути SQL Server Агент у Провіднику об'єктів.
4. Клацніть правою кнопкою миші Вакансії і виберіть Нова робота.
5. Налаштуйте завдання для запуску сценарію моніторингу через регулярні проміжки часу.
6. Налаштуйте сповіщення або звіти на основі зібраних даних.

Такий підхід дозволяє відстежувати історію та аналізувати тенденції, чого не забезпечує Activity Monitor.

6. Обмеження та міркування щодо монітора активності

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

6.1 Розуміння накладних витрат монітора активності

Монітор активності не є безкоштовним — він споживає ресурси сервера для збору та відображення інформації. Розуміння цих накладних витрат допоможе вам використовувати його відповідально.

6.1.1 Вплив на ресурси сервера

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

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

У документації Microsoft застерігається, що інтервали оновлення менше 10 секунд можуть помітно вплинути на продуктивність сервера, особливо на вже завантажених системах.

6.1.2 Рекомендації щодо інтервалу оновлення

Виберіть інтервали оновлення, що відповідають вашій ситуації:

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

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

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

Підхід Монітора активності до категоризації очікувань, хоча й спрощує подання, може приховувати важливі діагностичні дані.ostічну інформацію.

6.2.1 Як монітор активності групує очікування

SQL Server відстежує сотні різних типів очікування, кожен з яких вказує на певний ресурс або умову. Монітор активності групує їх у широкі категорії, такі як «Фіксація буфера», «Блокування» та «Пам’ять».

Наприклад, категорія «Buffer Latch» включає PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX та кілька інших специфічних типів очікування. Хоча всі вони пов’язані з доступом до сторінок, вони мають різні причини та рішення.

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

6.2.2 Відсутні типи очікування

Монітор активності не відображає всі типи очікування. Most Примітно, що він часто пропускає очікування CXPACKET, які вказують на паралельне виконання запитів. Очікування CXPACKET є поширеним явищем і зазвичай не створює проблем, але знання про їхню присутність допомагає зрозуміти характеристики робочого навантаження.

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

6.2.3 Чому важливі певні типи очікування

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

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

Монітор активності об’єднує всі ці елементи в розділ «Фіксація буфера», що ускладнює діагностику. Такі інструменти, як sp_WhoIsActive та запити DMV, показують конкретні типи очікування.

6.3 Точність та своєчасність даних

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

6.3.1 Знімковий знімок проти безперервного моніторингу

Монітор активності показує знімки за певний момент часу, зроблені з кожним інтервалом оновлення. Події, що відбуваються між знімками, не фіксуються. Якщо запит виконується протягом 2 секунд, а ви оновлюєтеся кожні 10 секунд, ви можете побачити його один раз або не побачити взагалі, залежно від часу.

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

6.3.2 Агрегація та вибірка

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

Панель «Очікування ресурсів» розраховує показники, порівнюючи знімки. Якщо статистика очікування скидається між знімками (rarе. але можливо), розраховані ставки можуть бути неправильними.

6.4 Коли НЕ слід використовувати монітор активності

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

6.4.1 Вимоги до історичного аналізу

Монітор активності показує лише поточну або нещодавню активність. Він не зберігає історичні дані. Якщо вам потрібно аналізувати тенденції протягом днів або тижнів, порівнювати поточну продуктивність з базовими показниками або створювати звіти про закономірності продуктивності, Монітора активності недостатньо.

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

6.4.2 Потреби в детальній статистиці очікування

Коли вам потрібна точна інформація про тип очікування для розширеного налаштування, групування та фільтрація в Моніторі активності роблять її недостатньою. Використовуйте запити DMV безпосередньо або sp_WhoIsActive замість цього.

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

6.4.3 Міркування щодо робочого сервера

На робочих серверах з високим навантаженням накладні витрати Activity Monitor можуть бути проблематичними. Кілька адміністраторів баз даних не повинні запускати Activity Monitor одночасно на одному сервері.

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

7. Найкращі практики використання монітора активності

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

7.1 Коли використовувати монітор активності

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

7.1.1 Проблеми з продуктивністю в режимі реального часу

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

Коли вам повідомляють, що «додаток працює повільно», одним із перших кроків має бути відкриття Монітора активності. Ви можете швидко визначити, чи база даних зайнята, заблокована чи простоює.

7.1.2 Розслідування уповільнення роботи застосунку

Коли певна програма перестає відповідати, Монітор активності допомагає визначити, чи є причиною проблеми з базою даних. Фільтруйте панель Процеси за назвою програми, щоб бачити активність лише цієї програми в базі даних.

Якщо програма не показує активності бази даних, поки користувачі повідомляють про проблеми, проблема криється в іншому місці стеку. Якщо ви бачите значні блокування або дорогі запити, ви знайшли свого винуватця.

7.1.3 Швидкі перевірки стану

Монітор активності надає чудову панель інструментів для швидкої перевірки стану під час планового адміністрування. Відкрийте її, перегляньте графіки огляду та переконайтеся, що нічого не виглядає незвичним.

Ця поверхнева перевірка займає лічені секунди та може виявити проблеми до того, як вони стануть критичними. Зробіть це частиною свого щоденного розпорядку.

7.2 Оптимальні параметри конфігурації

Правильне налаштування Монітора активності покращує як його корисність, так і споживання ресурсів.

7.2.1 Рекомендовані інтервали оновлення

Зіставте інтервал оновлення з вашою метою:

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

Не забудьте закрити Монітор активності після завершення. Встановлення тривалого інтервалу та забуття про нього призводить до витрачання ресурсів сервера.

7.2.2 Стратегії фільтрації

Використовуйте фільтри, щоб зосередитися на релевантній інформації та зменшити когнітивне навантаження:

• Фільтрувати процеси за Database щоб бачити лише активність у певних базах даних.
• Фільтрувати за Увійти відстежувати активність конкретного користувача.
• Фільтрувати за Стан завдання = RUNNING, щоб приховати сеанси очікування.
• Фільтрувати за додаток ізолювати трафік від певних програм.
• Показувати лише непусті елементи в Заблоковано бачити лише блокуючі ситуації.

7.2.3 Вибір та сортування стовпців

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

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

7.3 Інтеграція з іншими інструментами

Монітор активності найкраще працює як частина ширшого набору інструментів, а не як окреме рішення.

7.3.1 Використання з SQL Server Профіль

Монітор активності та SQL Server Профайлери добре доповнюють один одного. Коли ви визначите проблемний сеанс у Моніторі активності, клацніть його правою кнопкою миші та виберіть Трасування процесу в SQL Server Профіль.

Це запускає Profiler з фільтрами, вже налаштованими для захоплення лише активності цього сеансу. Ви бачите повну послідовність виконаних операторів, інформацію про час та повідомлення про помилки — деталі, яких не надає Activity Monitor.

Щоб дізнатися більше про SQL Server Можливості профайлера та передові методи трасування, див. наші всеосяжний SQL Server Посібник з профайлінгу.

7.3.2 Доповнення розширеними подіями

Розширені події пропонують детальний моніторинг з низькими накладними витратами, який фіксує інформацію, пропущену Монітором активності. Створюйте сеанси розширених подій для відстеження певних подій, таких як блокування, тривалі запити або надмірна кількість перекомпіляцій.

Використовуйте Монітор активності для негайного розслідування та Розширені події для постійного моніторингу та аналізу історії. Ці два інструменти відповідають різним потребам.

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

7.3.3 Рішення для моніторингу від сторонніх розробників

Комерційні інструменти, такі як SolarWinds Database Performance Analyzer, Redgate SQL Monitor та Quest Spotlight, надають функції, яких бракує Activity Monitor: сповіщення, історичні тренди, планування потужності та автоматична діагностика.ostics.

Ці інструменти є цінним доповненням до Activity Monitor, а не заміною. Activity Monitor залишається корисним для швидких перевірок та розслідувань, навіть коли доступні складні інструменти моніторингу.

7.4 поширених помилок, яких слід уникати

Розуміння поширених помилок монітора активності допоможе вам використовувати його ефективніше.

7.4.1 Залишення монітора активності в режимі безперервної роботи

Мost Поширеною помилкою є відкриття Монітора активності та залишення його запущеним на невизначений термін. Це витрачає ресурси сервера та не дає жодної користі, оскільки ви не спостерігаєте активно.

Закривайте Монітор активності, коли ви його активно не використовуєте. Якщо вам потрібен безперервний моніторинг, впровадьте належне рішення для моніторингу із запланованим збором даних.

7.4.2 Надмірна залежність лише від Монітора активності

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

Монітор активності допомагає виявляти проблеми, але їх вирішення часто вимагає додаткових інструментів та глибшого аналізу.

Дізнатися більше про SQL Server монітор продуктивності в нашому Повне керівництво.

7.4.3 Ігнорування історичних тенденцій

Монітор активності показує поточний стан, але проблеми з продуктивністю часто мають закономірності, видимі лише з плином часу. Запровадьте збір історичних даних, щоб ви могли порівнювати поточні показники з базовими показниками та визначати тенденції.

Без історичного контексту ви можете не помітити, що сьогоднішнє «нормальне» використання процесора на 30% вище, ніж базовий показник минулого місяця, що свідчить про поступове зниження.

8. Виправлення неполадок монітора активності

Сам монітор активності іноді має проблеми. Знання того, як вирішувати ці проблеми, запобігає розчаруванню.

8.1 Монітор активності не відкривається або не відображає дані

Якщо Монітор активності відкривається, але відображає порожні панелі або взагалі не відкривається, це може бути пов’язано з кількома факторами.

8.1.1 Проблеми з дозволами

Мost Поширеною причиною проблем з монітором активності є недостатні дозволи. Щоб перевірити та вирішити проблеми:

1. Перевірте дозволи на рівні сервера:

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

2. Якщо рядки не повертаються, у вас немає дозволу на перегляд стану сервера.
3. Попросіть адміністратора сервера надати йому дозвіл:

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

4. Закрийте та знову відкрийте Монітор активності після надання дозволів.

8.1.2 Проблеми сумісності версій

Використання старої версії SQL Server Management Studio для підключення до новішої SQL Server версія може спричинити збої монітора активності. Інструмент може не розпізнавати нові типи очікування або стовпці системного подання.

Завжди використовуйте версію 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 Розуміння стану паузи

Коли Монітор активності призупиняється, усі панелі відображають стан «Призупинено» з кнопкою відновити, яка може не працювати. Це запобігає відображенню будь-якої активності сервера.

Призупинений стан зазвичай виникає через проблеми з дозволами, обмеження віддаленого підключення або помилки версії SSMS, а не через навмисну ​​дію призупинення.

8.2.2 Поширені причини

Монітор активності може перейти в стан постійної паузи через:

• Відсутній дозвіл на перегляд стану сервера на новіших панелях, доданих нещодавно. SQL Server версії
• Віддалені з’єднання вимкнено на SQL Server екземпляр
• Помилки автентифікації для певних системних запитів
• Помилки в певних збірках SSMS, зокрема з 18.0 по 18.3
• Проблеми з підключенням між клієнтом і сервером

8.2.3 Кроки вирішення проблеми

Щоб вирішити проблеми з призупиненням монітора активності:

1. Оновлення SSMS: Завантажте та встановіть останню версію SQL Server Версія Management Studio з веб-сайту Microsoft. Багато помилок призупинення було виправлено в пізніших випусках.
2. Перевірте дозволи: Переконайтеся, що у вас є дозволи ПЕРЕГЛЯД СТАНУ СЕРВЕРА та ПЕРЕГЛЯД БУДЬ-ЯКИХ ВИЗНАЧЕНЬ.
3. Перевірте віддалені з'єднання: Переконайтеся, що SQL Server екземпляр дозволяє віддалені підключення:

   EXEC sp_configure 'remote access';
   

   Якщо значення дорівнює 0, попросіть адміністратора ввімкнути його.

4. Restarт ССМС: Іноді просто закриваючи всі вікна таtarдзвін SQL Server Management Studio вирішує цю проблему.
5. Підключення за допомогою автентифікації Windows: Якщо ви використовуєте автентифікацію SQL, спробуйте автентифікацію Windows, оскільки вона іноді дозволяє обійти проблеми з призупиненням, пов’язані з автентифікацією.

8.3 Проблеми з продуктивністю під час використання монітора активності

Якщо сам Монітор активності стає повільним або призводить до зниження продуктивності сервера, потрібне налаштування.

8.3.1 Зменшення накладних витрат на моніторинг

Щоб мінімізувати вплив Монітора активності:

1. Збільште інтервал оновлення до 30 секунд або 1 хвилини.
2. Закрийте панелі, які ви не використовуєте активно, натиснувши кнопку згортання.
3. Коли панелі згорнуті, Монітор активності не запитує дані для них.
4. Уникайте одночасного запуску кількох екземплярів Монітора активності.
5. Повністю закривайте Монітор активності, коли не досліджуєте проблеми.

8.3.2 Альтернативні методи моніторингу легких матеріалів

Якщо Монітор активності занадто ресурсоємний для вашого середовища, розгляньте альтернативи:

• Звертайтеся безпосередньо до DMV: Напишіть специфічні T-SQL запити, які отримують лише потрібну вам інформацію.
• Використовуйте sp_WhoIsActive: Ця збережена процедура є високооптимізованою та зазвичай має менші накладні витрати, ніж Activity Monitor.
• Впровадити вибірку: Плануйте завдання агента SQL, які регулярно роблять знімки даних DMV та зберігають результати в таблицях для подальшого аналізу.
• Моніторинг вторинних реплік: In Групи доступності Always On, запустіть Монітор активності для читабельного вторинного диска, а не для основного.

8.4 Неточна або відсутня інформація

Іноді Монітор активності відображає інформацію, яка здається неправильною або неповною.

8.4.1 Перевірка даних за допомогою DMV

Коли результати монітора активності здаються підозрілими, перевірте їх, звернувшись безпосередньо до відповідних DMV. Наприклад, якщо на панелі «Процеси» блокування не відображається, але користувачі повідомляють про нього, виконайте запит:

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

Якщо цей запит показує блокування, яке пропустив Монітор активності, ви підтвердили проблему з дисплеєм.

8.4.2 Розуміння часу оновлення даних

Пам’ятайте, що Монітор активності показує знімки. Запит, який виконувався між інтервалами оновлення, не відображатиметься в розділі «Нещодавні дорогі запити», якщо його план виконання не залишається в кеші.

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

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

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

9.1 Об'єднання кількох панелей для аналізу першопричини

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

9.1.1 Співвідношення очікувань з процесами

Коли в області «Очікування ресурсів» відображається тривалий час очікування в певній категорії, скористайтеся областю «Процеси», щоб визначити, у яких сеансах спостерігається цей час очікування:

1. Зверніть увагу на категорію очікування з високим сукупним часом очікування (наприклад, «Блокування»).
2. Перейдіть до панелі «Процеси».
3. Сортувати за Тип очікування групувати сеанси за їх поточним очікуванням.
4. Шукайте сеанси, що відображають типи очікування в проблемній категорії.
5. Для цих сесій перегляньте Ресурс очікування стовпець, щоб побачити, які об’єкти бази даних задіяні.
6. Клацніть правою кнопкою миші та виберіть ПОДРОБИЦІ щоб переглянути текст запиту.

Ця кореляція допомагає вам перейти від «у нас є очікування блокувань» до «цей конкретний запит очікує блокувань на цій таблиці».

9.1.2 Пов'язування дорогих запитів із проблемами вводу/виводу

Коли панель вводу/виводу файлів даних показує високу активність диска в певній базі даних:

1. Зверніть увагу, які файли бази даних мають високу швидкість читання або запису в МБ/с.
2. Перейти до розділу «Нещодавні дорогі запити».
3. Сортувати за Фізичні читання/сек для виявлення запитів, які здійснюють інтенсивне читання з диска.
4. Фільтруйте або візуально ідентифікуйте запити, що виконуються до бази даних з високим рівнем вводу-виводу.
5. Перевірте плани виконання цих запитів на наявність сканування таблиць або відсутніх індексів, що спричиняють надмірне введення-виведення.

Цей багатопанельний аналіз пов'язує симптоми (високий обсяг дискового вводу/виводу) з причинами (конкретні неефективні запити).

9.2 Використання монітора активності для планування потужності

Хоча Монітор активності не зберігає історичні дані, ви можете стратегічно використовувати його для спостережень за плануванням потужностей.

9.2.1 Визначення моделей пікового використання

Моніторинг активності сервера в різний час доби, щоб визначити закономірності використання:

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

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

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

Хоча Монітор активності показує поточний стан, ви можете використовувати його для вибіркової перевірки трендів, записуючи ключові показники з плином часу:

• Робіть знімки екрана панелі «Огляд» щодня в один і той самий час
• Запишіть пікові значення з кожного графіка
• Порівнюйте показники тиждень за тижнем, щоб визначити тенденції зростання
• Слідкуйте за поступовим збільшенням середнього часу обробки процесора або швидкості вводу-виводу

Таке ручне відстеження трендів доповнює більш складні рішення для моніторингу та допомагає виправдати розширення потужностей.

9.3 Документування базових показників ефективності

Встановлення базових показників продуктивності допомагає розпізнати, коли продуктивність знижується.

9.3.1 Отримання базових показників

Протягом періодів відомої хорошої роботи документуйте показники монітора активності:

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

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

9.3.2 Порівняння поточної та базової продуктивності

Коли виникають проблеми з продуктивністю, порівняйте поточні показники монітора активності із задокументованими базовими показниками:

• Чи значно вищий час роботи процесора, ніж базовий? Зосередьтеся на запитах, що ресурсомісткі для процесора.
• Чи обсяг завдань очікування в 2-3 рази перевищує базовий рівень? Дослідіть очікування ресурсів.
• Чи значно вищий рівень вводу/виводу? Перевірте панель вводу/виводу файлів даних та ресурсомісткі запити.
• Чи кількість пакетних запитів нижча за базову в години пік? Шукайте блокування або проблеми з підключенням.

Це порівняння допомагає вам визначити, що змінилося, і належним чином зосередити зусилля на усуненні несправностей.

9.4 Створення власних робочих процесів моніторингу

Розробіть систематичні робочі процеси для поширених сценаріїв розслідування, щоб забезпечити ретельний та повторюваний аналіз.

9.4.1 Покроковий процес розслідування

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

1. Швидка перевірка здоров'я: Відкрийте Монітор активності та проскануйте графіки панелі Огляд на наявність очевидних аномалій.
2. Перевірте наявність блокування: Розгорніть панель «Процеси», відфільтруйте непусті елементи у стовпці «Заблоковано».
3. Визначте конкуренцію за ресурси: Панель «Огляд очікування ресурсів», відсортована за часом очікування.
4. Знайдіть дорогі запити: Перегляньте останні дорогі запити, відсортовані за процесором, потім за виконанням, а потім за кількістю читань.
5. Співвідношення шаблонів вводу/виводу: Перехресне посилання на ресурсомісткі запити з активністю панелі вводу-виводу файлів даних.
6. Результати документа: Зробіть знімки екрана та запишіть відповідні ідентифікатори сеансів, типи очікування та деталі запитів.
7. Глибоке занурення: Використовуйте трасування Profiler, аналіз плану виконання та запити DMV для детального дослідження виявлених проблем.

9.4.2 Критерії ескалації

Встановіть критерії щодо того, коли слід ескалувати проблеми, а коли продовжувати розслідування:

• Негайно ескалювати: Ланцюжки блокування тривалістю >5 хвилин, завантаження процесора на 100% протягом >2 хвилин, критичні системні процеси перебувають у стані ПРИЗУПИНЕННЯ.
• Ескалація з аналізом: Повторювані ресурсоємні запити, що споживають >50% ресурсів процесора, постійно високий час відгуку вводу-виводу >50 мс, повторювані збої у наданні пам'яті.
• Дослідіть далі: Темпrarочікування y, вирішення яких триває лічені хвилини, запити з неоптимальними планами, але з прийнятною продуктивністю, незначне блокування тривалістю <30 секунд.

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

Монітор активності еволюціонував по всьому SQL Server версії, причому кожен випуск приносить покращення, а іноді й нові проблеми.

10.1 Монітор активності в SQL Server 2008 і новіші

SQL Server У 2008 році було представлено сучасний дизайн монітора активності, який залишається практично незмінним і донині.

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

Команда SQL Server Редизайн монітора активності 2008 року приніс значні покращення:

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

Ці зміни перетворили Монітор активності з простого списку процесів на комплексну панель моніторингу.

10.1.2 Зміни порівняно з SQL Server 2005

SQL Server Монітор активності 2005 року був набагато обмеженішим:

• Доступ до папки «Керування» в провіднику об'єктів, а не через панель інструментів
• Одна сітка, що відображає список процесів з основною інформацією
• Немає графічних діаграм або кількох панелей
• Без дорогих запитів чи моніторингу вводу/виводу
• Обмежена інформація про статистику очікування

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

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

SQL Server У 2014 та 2016 роках було внесено поступові покращення до базового збору даних Activity Monitor, але візуальних змін було мало.

10.2.1 Покращення та вдосконалення

Ключові покращення в цих версіях включали:

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

Основний інтерфейс залишився узгодженим з SQL Server 2008 рік, підтримуючи знайомство для адміністраторів.

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

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

10.3.1 Найновіші функції та можливості

SQL Server Монітор активності за 2019 та 2022 роки включає:

• Підтримка нових типів очікування, запроваджених у цих версіях
• Покращена продуктивність рендерингу в SSMS за допомогою технології WPF
• Краща обробка великої кількості активних сеансів
• Покращена сумісність з хмарними SQL-платформами
• Точніші показники процесора та вводу-виводу

10.3.2 Відомі проблеми в останніх версіях

SQL Server У 2019 році було представлено кілька помилок у Моніторі активності:

• Постійний паузиний стан: Монітор активності часто переходить у стан паузи та не відновлює роботу, особливо в SSMS 18.0-18.3. Виправлено в пізніших версіях SSMS.
• Збої віддаленого підключення: Деякі конфігурації запобігають відкриттю Монітора активності на віддалених екземплярах. Спосіб вирішення проблеми включає ввімкнення певних прапорців трасування або використання новіших збірок SSMS.
• Проблеми з дозволом: Нові системні представлення потребують додаткових дозволів, які не є чітко задокументованими, що призводить до порожніх екранів навіть із VIEW SERVER STATE.

Завжди використовуйте найновішу версію SSMS під час роботи з SQL Server 2019 та 2022 роки, щоб уникнути цих проблем.

11. Практичні випадки та приклади використання

Реальні приклади демонструють, як ефективно застосовувати Монітор активності в поширених сценаріях усунення несправностей.

11.1 Тематичне дослідження: Діагностика повільного веб-застосунку

Команда розробників повідомляє, що їхній вебзастосунок став неприйнятно повільним, а завантаження сторінок займає 20-30 секунд замість звичайних 2-3 секунд.

11.1.1 Початкове дослідження з оглядовою панеллю

Відкрийте Монітор активності та перегляньте панель Огляд:

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

Ця закономірність вказує на вузьке місце процесора через конкуренцію за ресурси, що призводить до зниження пропускної здатності. Сервер працює інтенсивно, але обробляє не так багато запитів.

11.1.2 Визначення проблемного запиту

Розгорніть панель «Нещодавні дорогі запити» та відсортуйте за кількістю виконань/хв:

1. Найпопулярніший запит показує 15 000 виконань за хвилину.
2. Клацніть правою кнопкою миші та виберіть Редагувати текст запиту щоб перевірити запит.
3. Запит — це простий оператор SELECT, який отримує запис одного користувача: SELECT * FROM Users WHERE UserId = @UserId.
4. Цей запит не повинен виконуватися 15 000 разів на хвилину за звичайного використання програми.

Клацніть запит правою кнопкою миші та виберіть Показати план виконанняПлан показує сканування таблиці Users з попередженням про відсутність індексу у стовпці UserId.

Фільтруйте панель «Процеси» за програмою, щоб відображати лише підключення веб-програми. Кілька сеансів показують, що один і той самий запит виконується повторно.

11.1.3 Вирішення проблеми та перевірка

Проблема виникає через дві причини: надмірну кількість виконань запитів та відсутність індексу. Кроки вирішення:

1. Створіть відсутній індекс:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Зв'яжіться з командою розробників щодо надмірної кількості виконань. Розслідування виявляє проблему запитів N+1 у коді програми, де цикл отримує дані користувача для кожного елемента у списку.
3. Змінити програму об'єднати пошукові запити користувачів в один запит за допомогою речення IN або параметра, що повертає значення в таблиці.
4. Перевірте виправлення шляхом моніторингу Activity Monitor після розгортання. Завантаження процесора падає до 35-40%, кількість виконань за хвилину зменшується до 200-300, а час відгуку програм повертається до норми.

11.2 Тематичне дослідження: Вирішення проблеми блокування

Користувачі повідомляють, що система введення замовлень періодично зависає на 30-60 секунд, перш ніж відновити нормальну роботу.

11.2.1 Виявлення ланцюга блокування

Відкрийте Монітор активності під час одного з цих зависань і розгорніть панель Процеси:

1. Сортувати за Ідентифікатор сеансу щоб побачити всі організовані сесії.
2. Кілька сеансів показують значення в Заблоковано стовпець, усі з яких вказують на ідентифікатор сеансу 73.
3. Сесія 73 показує «1» у Блокувальник голови стовпець, що підтверджує, що це є першопричиною.
4. Команда Тип очікування для заблокованих сесій відображається LCK_M_X, що вказує на очікування ексклюзивних блокувань.
5. Команда Ресурс очікування У стовпці показано, що блокування здійснюється в таблиці «Замовлення».

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

Клацніть правою кнопкою миші на Сеансі 73 та виберіть ПОДРОБИЦІ щоб переглянути команду:

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

Це оновлення є частиною пакетної обробки, яка виконується щогодини. Перевірка Увійти підтверджує, що сеанс належить до облікового запису служби пакетної обробки.

Запит блокує таблицю «Замовлення» під час обробки тисяч замовлень. Час очікування для заблокованих сеансів постійно зростає, що підтверджує, що проблема полягає в цій тривалій операції.

11.2.3 Впровадження виправлення

Короткострокове вирішення:

1. Деталі сеансу документа 73, включаючи текст запиту та тривалість.
2. Дозвольте оновленню завершитися природним шляхом, оскільки це законна пакетна обробка.
3. Після завершення перевірте, чи заблоковані сесії очищені, і чи відновлюється нормальна робота.

Впроваджені довгострокові рішення:

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

11.3 Тематичне дослідження: Виявлення надмірної кількості виконань запитів

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

11.3.1 Виявлення аномальної кількості виконань

Відкрийте Монітор активності та перегляньте панель «Нещодавні дорогі запити»:

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

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

5. Цей простий запит має бути швидким і кешованим, проте він виконується десятки тисяч разів на хвилину.

11.3.2 Трасування до коду програми

На панелі «Процеси» знайдіть сеанси, що виконують цей запит:

1. Зверніть увагу на додаток У стовпці відображається «Сервіс каталогу продуктів».
2. Клацніть правою кнопкою миші один із цих сеансів і виберіть Трасування процесу в SQL Server Профіль.
3. SQL Profiler показує, що запит виконується багаторазово у швидкій послідовності з різними значеннями CategoryId.
4. Зверніться до команди розробників, яка керує ProductCatalogService, для перевірки коду.

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

11.3.3 Оптимізація програми

Впровадити належне виправлення:

1. Змінити запит програми щоб використати JOIN для отримання продуктів та їх категорій в одному виклику бази даних:

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

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

12. Виявлення потенційного пошкодження бази даних

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

12.1 Симптоми потенційного пошкодження бази даних

Якщо база даних пошкоджена та до неї здійснюється доступ, ви можете іноді бачити:

1. В області «Процеси»:

• Сеанси зависли в стані SUSPENDED з незвичайними типами очікування
• Процеси, що показують стани помилок
• Запити повторюються з помилками

2. В області очікування ресурсів:

• Незвичайні типи очікування, пов'язані з вводом/виводом, які можуть свідчити про проблеми з диском (хоча це, скоріше, вказує на проблеми з обладнанням, ніж на логічне пошкодження)

3. У розділі «Нещодавні дорогі запити»:

• Запити з аномально високим обсягом фізичних зчитувань, якщо вони неодноразово намагаються зчитати пошкоджені сторінки

12.2 Подальша перевірка за допомогою DBCC CHECKDB

Коли Монітор активності відображає симптоми, що вказують на потенційне пошкодження, слід негайно виконати команду DBCC CHECKDB для перевірки цілісності бази даних. Ця команда сканує всі сторінки бази даних, перевіряє контрольні суми та наявність помилок логічної узгодженості.

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

12.3 Ремонт за допомогою професійних інструментів

Якщо DBCC CHECKDB підтверджує пошкодження бази даних, у вас є кілька варіантів відновлення:

• Бажаним підходом є відновлення з відомої справної резервної копії. Див. наш вичерпний посібник із резервного копіювання та відновлення SQL Server базами даних.
• У разі незначних пошкоджень, DBCC CHECKDB з REPAIR_REBUILD може вирішити проблеми.
• Для критично важливих баз даних без нещодавніх резервних копій, професійний Програмне забезпечення для відновлення SQL а служби часто можуть відновити дані, які вбудовані опції відновлення не можуть.

13. Висновок

SQL Server Монітор активності є безцінним інструментом для адміністраторів баз даних, надаючи негайне уявлення про продуктивність сервера та допомагаючи швидко та ефективно діагностувати проблеми.

13.1 Резюме ключових положень

У цьому посібнику ми досліджували, як Монітор активності допомагає вам зрозуміти та усунути неполадки SQL Server продуктивність:

• Монітор активності забезпечує видимість процесів, очікування, запитів та вводу-виводу в режимі реального часу через організований графічний інтерфейс.
• П’ять панелей — «Огляд», «Процеси», «Очікування ресурсів», «Ввод-вивод файлів даних» та «Нещодавні дорогі запити» — пропонують унікальні перспективи щодо активності сервера.
• Поширені сценарії усунення несправностей, такі як надмірне виконання запитів, ланцюжки блокування та високе використання процесора, стають керованими завдяки систематичному дослідженню Activity Monitor.
• Хоча Activity Monitor і є потужним, він має обмеження, зокрема брак історичних даних, групування типів очікування та накладні витрати на моніторинг, що впливають на його застосування.cability.
• Доповнення монітора активності запитами DMV, sp_WhoIsActive, розширеними подіями та потенційно сторонніми інструментами створює комплексну стратегію моніторингу.
• Дотримання найкращих практик щодо інтервалів оновлення, закриття монітора активності, коли він не використовується, та об’єднання кількох панелей для кореляції максимізує його цінність, мінімізуючи вплив.

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

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

Уявіть собі Монітор активності як аналог приладової панелі у вашому автомобілі — вона одразу повідомляє вам про проблеми та допомагає визначити загальну проблемну зону. Так само, як приладова панель вашого автомобіля не повідомляє вам точно, чому загорілася лампочка «Check Engine», Монітор активності вказує на проблеми, не завжди розкриваючи їх повну першопричину. Такий глибший аналіз вимагає додаткових інструментів та досвіду.

Інтегруйте Монітор активності в ширший інструментарій, який включає аналіз плану виконання, відстеження статистики очікування, рішення для історичного моніторингу та найкращі практики продуктивності. Використовуйте його разом із належними стратегіями індексації, методами оптимізації запитів та плануванням потужності.

13.3 Продовження вашої навчальної подорожі

Оволодіння Activity Monitor – це лише один крок до того, щоб стати ефективним адміністратором бази даних. Продовжуйте розвивати свої навички, використовуючи такі методи:

• Навчитися інтерпретувати плани виконання та виявляти неефективні операції
• Розуміння SQL Server статистика очікування та її значення
• Вивчення методів проектування та оптимізації індексів
• Дослідження SQL ServerАрхітектура та як вона обробляє запити
• Практикуючи систематичні методології усунення несправностей
• Нарощування досвіду роботи з розширеними подіями для детального трасування
• Розуміння рівнів ізоляції транзакцій та їхнього впливу на продуктивність

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

13.4 Додаткові ресурси

Розширте свої знання за допомогою цих цінних ресурсів:

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

14. Поширені запитання (FAQ)

З: Що таке SQL Server Монітор активності?

A: SQL Server Монітор активності – це вбудований інструмент у SQL Server Management Studio, яка відображає інформацію про процеси, що виконуються в режимі реального часу SQL Server екземпляр та їхній вплив на ресурси сервера. Він надає графічну панель інструментів із п'ятьма панелями, що відображають різні аспекти активності сервера, включаючи використання процесора, завдання очікування, швидкість вводу/виводу, активні сесії та ресурсомісткі запити.

З: Як відкрити Монітор активності в SSMS?

A: Ви можете відкрити Монітор активності чотирма способами: (1) Клацніть значок Монітора активності на панелі інструментів SSMS, (2) Клацніть правою кнопкою миші SQL Server ім'я екземпляра в Object Explorer та виберіть Activity Monitor, (3) Натисніть Ctrl + інший + Aабо (4) Налаштуйте SSMS для автоматичного запуску через Інструменти -> Опції -> Навколишнє середовище -> Starтрубка.

З: Які дозволи мені потрібні для використання Монітора активності?

В: Вам потрібно ПЕРЕГЛЯНУТИ СТАН СЕРВЕРА дозвіл побачити мost Інформація про монітор активності. Для панелі вводу/виводу файлів даних вам також знадобиться CREATE DATABASE, ЗМІНИТИ БУДЬ-ЯКУ БАЗУ ДАНИХабо ПЕРЕГЛЯНУТИ БУДЬ-ЯКЕ ВИЗНАЧЕННЯ дозволи. Без цих дозволів Монітор активності може відкриватися, але відображати порожні панелі.

З: Чому мій Монітор активності призупинено або не працює?

A: Монітор активності зазвичай призупиняється через проблеми з дозволами, застарілі версії SSMS або вимкнені віддалені підключення. Щоб вирішити проблему: (1) Оновіть SSMS до останньої версії, (2) Перевірте, чи маєте ви дозвіл ПЕРЕГЛЯД СТАНУ СЕРВЕРА, (3) Перевірте, чи ввімкнено віддалені підключення на SQL Server приклад, (4) Резtart SSMS та (5) спробуйте підключитися з автентифікацією Windows замість автентифікації SQL, якщо це можливоcabLe.

З: Яка різниця між Монітором активності та sp_WhoIsActive?

A: Монітор активності – це графічний інструмент, вбудований у SSMS, який надає організовані панелі для різних аспектів моніторингу. sp_WhoIsActive – це безкоштовна збережена процедура, створена спільнотою, яка повертає детальну інформацію про сеанс в одному наборі результатів з більш конкретними типами очікування, деталями блокування та параметрами налаштування, ніж Монітор активності. Монітор активності кращий для візуального дослідження, тоді як sp_WhoIsActive чудово справляється зі сценарійним моніторингом і надає детальнішу інформацію.

З: Чи впливає монітор активності на продуктивність сервера?

В: Так, Activity Monitor має вимірні накладні витрати, оскільки він запитує системні DMV з кожним інтервалом оновлення. Вплив зростає з нижчою частотою оновлення — Microsoft попереджає, що інтервали менше 10 секунд можуть впливати на продуктивність сервера. Завжди закривайте Activity Monitor, коли він не використовується активно, і враховуйте інтервали оновлення 30-60 секунд на робочих серверах з високим навантаженням.

З: Чи можу я отримати дані монітора активності за допомогою T-SQL?

A: Так, Монітор активності запитує динамічні подання керування системою, такі як 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?tarтуп?

A: Налаштуйте автоматичний запуск через параметри SSMS: Перейдіть до Інструменти -> Опції -> Навколишнє середовище -> Starтрубка, А потім виберіть Відкрийте Провідник об'єктів та Монітор активності від На сtarтрубка випадаючий список. Монітор активності автоматично відкриватиметься щоразу, коли ви підключатиметесь до сервера в SSMS.

З: Які обмеження має Монітор активності?

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

---

Про автора

Юань Шен є старшим адміністратором баз даних (DBA) з понад 10-річним досвідом роботи в SQL Server середовища та управління корпоративними базами даних. Він успішно вирішив сотні сценаріїв відновлення баз даних у фінансових службах, охороні здоров'я та виробничих організаціях.

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

Завдяки своїй технічній експертизі та практичному підходу, Юань зосереджується на створенні комплексних посібників, які допомагають адміністраторам баз даних та ІТ-фахівцям вирішувати складні SQL Server ефективно вирішує проблеми. Він слідкує за останніми новинками SQL Server випуски та технології баз даних Microsoft, що розвиваються, регулярно тестуючи сценарії відновлення, щоб переконатися, що його рекомендації відображають найкращі практики реального світу.

Є запитання щодо SQL Server відновлення чи потрібні додаткові інструкції з усунення несправностей бази даних? Юань вітає відгуки та пропозиції для покращення цих технічних ресурсів.