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

версії 11.0.1 має низку нових важливих можливостей, які істотно відрізняють нову версію від усіх попередніх. 11.0.1 може працювати з будь-якою версією SQL Server, починаючи з 4.9.2 та закінчуючи System 11.

Однак деякі найбільш цікаві види інформації про характер використання об'єктів баз даних та взаємодію сервера з мережею видаються тільки при моніторингу SQL Server System 10 і System 11. Природно, дані роботи іменованих кеш-буферів видаються тільки при контролі продуктивності SQL Server System 11.

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

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

При запуску необхідно скасувати перевірку пам'яті сервера, яку виконує команда dbcc memusage, оскільки ця команда суттєво уповільнює роботу сервера. Для цього при запуску sqlmon (клієнтського модуля) необхідно вказати параметр nomem.

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

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

Так, для підтримки 20 вікон у командному файлі запуску серверного модуля необхідно вказати параметр п2 0. При цьому потрібно змінити адресу початку області пам'яті сервера, що розділяється, за допомогою команди buildmaster і деяких інших дій. Ці дії в жодному разі не можна виконувати під час роботи SQL Server. (Докладно про процес розширення кількості клієнтів, що одночасно підтримуються, див. посібник із серверного модуля Server Supplement.)

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

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

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

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

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

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

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

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

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

Головне вікно (Main Window)
Тут міститься список вікон, що підтримуються програмою. У разі, якщо при запуску sglmon - клієнтського модуля - не було вказано параметр nomem, у цьому вікні також буде видано кругову діаграму використання пам'яті серверної машини.

Кеш-буфери (Cache)
У цьому вікні видаються графіки, що характеризують роботу кеш-буферів процедур та даних. Контролюючи кількість фізичних та логічних операцій введення-виводу в кеш-буфері даних, користувач може визначити, яку частину звернень до сторінок даних сервер виконає, використовуючи сторінки, що вже знаходяться у буфері. Подібна статистика, отримана за буфером даних та буфером процедур, дозволяє визначити загальний обсяг пам'яті, необхідний кеш-буферам сервера, та співвідношення між кеш-буферами даних та процедур.

Кеш-буфер даних тільки для SQL Server System 11 (Data Cach)
Вікно повідомляє кількість операцій фізичного та логічного введення-виведення по кожному з іменованих кеш-буферів, налаштованих на сервері.

Дискове введення/виведення (Device I/O)
Тут знаходяться графіки та зведені таблиці за поточною та повною кількістю звернень до дисків. Вони допомагають оптимізувати розподіл навантаження вводу-виводу серед серверних пристроїв. При аналізі інформації, що видається корисно використовувати стандартну схему вибору назв серверних пристроїв за назвами відповідних розділів фізичних дисків, оскільки, спостерігаючи за швидкістю обміну з серверними пристроями, слід знати, до якого дискового контролера підключено кожне з цих пристроїв.

Робота з мережею, тільки для SQL Server System 10 та 11 (Network Activity)
У вікні повідомляється статистична інформація про мережевий введення виводу - розміри пакетів, обсяги трафіку тощо.

Блокування доступу до об'єктів лише для SQL Server System 10 і 11 (Object Lock Status)
Тут видається інформація про блокування доступу до таблиць даних, включаючи докладний розподіл типів блокувань, що використовуються, назви процесів, що утримують блокування і т.д.

Введення-виведення сторінок об'єктів тільки для SQL Server System 10 і 11 (Object Page I/O)
Вікно містить інформацію про інтенсивність введення-виведення сторінок однієї з таблиць даних сервера. Зверніть увагу на ефективність при складанні переліку найбільш часто використовуваних таблиць сервера. Такі відомості не видаються процедурою sp_sysmon.

Зведення даних про продуктивність (Performance Summar)
Тут представлена ​​загальна картина функціонування SQL Server - відсоток використання часу процесора, кількість транзакцій, що обробляються в секунду, обсяг мережевого трафіку, дискового вводу-виводу, а також інтенсивність використання блокувань.

Динаміка показників продуктивності (Performance Trend)
У вікні будуються безперервні графіки, залежно від часу показників продуктивності сервера, що видаються у вікні Performance Summary.

Активність серверних процесів (Process Activit)
Вікно дозволяє вибрати один або кілька серверних процесів та стежити за використанням процесора та обсягами введення-виводу по кожному з процесів.

Детальні дані про процес (Process Detail)
Вікно містить докладну інформацію про вибраний серверний процес.

Список процесів (Process List)
Вікно містить список всіх наявних на даний момент серверних процесів із зазначенням їхнього стану. Дуже схоже видачу серверної команди sp_who.

Використання блокувань (Process Lock Activity)
Вікно видає інформацію про використання блокувань вибраним серверним процесом.

Використання процедур, що зберігаються (Stored Procedure Activity)
Вікно містить відомості про виконання процедур, що зберігаються, і часу роботи кожної процедури.

Обробка транзакцій (Transaction Activity)
У вікні можна побачити стовпчасту діаграму, що показує кількість транзакцій, що обробляються, з розподілом по різних типах транзакцій. Очевидно, наприклад, яку частину транзакцій вдається виконати з використанням механізму оновлення записів на місці (update in place).

26.12.2006 Кевін Клайн

Яке питання найменше хотілося б отримати адміністратору баз даних? Ймовірно, повідомлення від користувача про погіршення роботи програми або питання, що сталося з базою даних. Доводиться відкладати всі справи і переходити в «аварійний режим», гадаючи, чи це надовго. Оскільки одним із основних обов'язків адміністратора баз даних є забезпечення якісного функціонування промислових баз даних, залишається тільки максимально швидко усунути несправність. Часу з'ясування причини збою, зазвичай, немає.

Більше ніяких авралів – просто систематичне спостереження

Але чи це єдине, що можна зробити? Існує можливість проводити запобіжний моніторинг продуктивності, просту процедуру управління, яка використовує визначення базових параметрів роботи системи, отримання еталонів та безперервне спостереження. У цій статті я розповім про те, як застосовувати попереджувальний моніторинг та як створити безкоштовну контрольну систему за допомогою Windows System Monitor.

Запобіжний моніторинг

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

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

Базові параметри, еталон, монітор

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

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

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

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

Крок 1: Визначте базові параметри продуктивності.

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

Щоб наочно показати якість функціонування, найкращі базові параметри використовують трохи графіків (в ідеалі один), щоб з першого погляду можна було побачити, як працює сервер. Коли буде визначено базові параметри, потрібно зробити таке. По-перше, виберіть варіант для збереження даних продуктивності в системному журналі або їх відображення в реальному часі. Ідеально мати обидві можливості: журнали реєстрації дозволяють повернутися до показань у будь-який час, щоб проаналізувати, якою була продуктивність, коли безпосереднє спостереження за системою не велося. Моніторинг у реальному часі не займає робоче місце на диску та ресурси сервера, але вимагає приділити системі 100 відсотків уваги. По-друге, потрібно визначити інтервал, через який вестиметься спостереження, враховуючи витрати у продуктивності для збору даних та операції введення-виведення даних та оцінити витрати на необхідний простір. Чим більше інтервал, тим вище ймовірність, що дані, що цікавлять, по продуктивності не будуть отримані. І, нарешті, оберіть локальний або дистанційний моніторинг. Локальний моніторинг, у якому процес спостереження використовує контрольований сервер, додає непродуктивні видатки процесор і диск сервера. Дистанційний моніторинг, який використовує окремий сервер, може позбавити таких проблем, проте це сильно збільшує робоче навантаження на мережу.

Перераховані метрики System Monitor або лічильники, які рекомендується використовувати для визначення базових параметрів. Не можу сказати, яке значення “правильне” у тих окремо взятого докладання, оскільки він змінюється від системи до системи. Використовуйте середнє значення різних базових параметрів для встановлення звичайної стандартної (за базовими параметрами) продуктивності та позначте, що цей варіант і є правильним для експлуатованої системи

Визначення базових параметрів за допомогою System Monitor

Тепер для цілей збирання базових параметрів викличемо System Monitor. Відкриємо Control Panel, Administrative Tools, Performance. Двічі клацніть на Performance Logs and Alerts на лівій панелі. Натисніть праву кнопку на Counter Logs та вкажемо New Log Settings. Введіть назву для графіки та натисніть OK. У діалоговому вікні Select Counters виберіть перший лічильник, а потім натисніть Add. Повторюйте ці операції, поки всі лічильники не будуть додані, а потім натисніть Close.

Спочатку спробуйте за замовчуванням 15-секундний інтервал. Або виберіть інший інтервал, натиснувши Properties (або використовуйте клавішну комбінацію швидкого виклику Ctrl + Q), а потім введіть значення під позначкою Sample automatically every: seconds. Довші інтервали займають менше місця, проте вони забезпечують менш докладні дані.

Виберіть таблицю Log Files та визначте місце, де зберігатимуться дані. Є можливість переглянути дані пізніше, використовуючи уявлення View Log File Data. System Monitor виглядатиме так, як на екрані 1, коли він збирає дані базових параметрів продуктивності. Видно, що при одночасному відстеженні безлічі лічильників можна зібрати дуже багато даних, тому слід уважно вибирати лічильники для основної лінії.

Крок 2: Встановлення еталонних значень

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

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

Можна створити свій сценарій, використовуючи набір сценаріїв T-SQL, утиліти osql або Query Analyzer, SQL Profiler і System Monitor. Розробка сценаріїв тестів навантаження в T-SQL зазвичай займає кілька днів. Ще більше часу може знадобитися на збір даних виконання тестів навантаження і аналіз отриманих даних.

Після визначення базових параметрів продуктивності сервера при заздалегідь заданих навантаженнях можна буде дізнатися, чого можна очікувати від системи. Використовуйте дані, зібрані для отримання еталонних значень для формування основи планового спостереження. Наприклад, з'ясувалося, що сервер здатний забезпечити до 249 транзакцій за секунду, перш ніж його робота почне сповільнюватися. У цьому випадку можна встановити повідомлення з низьким пріоритетом, коли сервер досягне завантаження близько 200 TPS, і повідомлення з високим пріоритетом, коли сервер досягне 235 TPS. Такий спосіб дозволить адміністратору дізнатися про можливі проблеми з сервером і вжити необхідних заходів до того, як користувачі щось помітять. І жодних критичних ситуацій. Тепер це можливо.

Крок 3: Плановий моніторинг

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

Можна створити недорогий засіб для спостереження за SQL Server, використовуючи поєднання SQL Server Agent та System Monitor. SQL Server Agent дозволяє визначити, яка подія вивела помилку на монітор, встановити, хто отримує повідомлення про події та автоматично надіслати повідомлення, коли з'являється подія з помилкою.

Встановлення SQL Server Agent може бути тривалим за часом і складним, тому потрібно буде звернутися до розділу опису Alerts в SQL Server Books Online (BOL). SQL Server Agent зазвичай здійснює поточний контроль над повідомленнями про помилки роботи сервера бази даних і не контролює виконання.

Для контролю за продуктивністю сервера використовується System Monitor для спостереження за поточними лічильниками (встановіть частоту опитування з точністю до 15 хвилин).

Memory-Pages/sec

Network Interface-Bytes total/sec

Physical Disk-Disk Transfers/sec

Processor-% Processor Time

SQLServer:Access Methods-Full Scans/sec

SQLServer:Buffer Manager-Buffer Cache Hit Ratio

SQLServer:Databases Application Database-Transactions/sec

SQLServer:General Statistics-User onnections

SQLServer:Latches-Average Latch Wait Time

SQLServer:Locks-Average Wait Time

SQLServer:Locks-Lock Timeouts/sec

SQLServer:Locks-Number of Deadlocks/sec

SQLServer:Memory Manager-Memory Grants Pending

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

Для попередження можна використовувати безкоштовні інструменти, такі як SQL Server Alerts & Notifications, System Monitor або придбати Microsoft Operations Manager (MOM) або інші засоби. Я рекомендую встановити попередження принаймні для наступних ситуацій:

• помилки, що впливають на експлуатацію, особливо помилки з показником важливості від 19 до 25
• блокування
• використання процесора
• використання диска
• сканування (SQLServer:Access Methods)

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

• журнал SQL Server
• журнал SQL Agent
• журнал додатків Windows, Security, та System
• журнал виконання завдань SQL Server

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

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

Таблиця 1. Об'єкти та лічильники System Monitor для визначення базових параметрів

Об'єкт та лічильник	Опис
Memory-Pages/sec	Число сторінок читання або запису на диск за секунду. Цей лічильник є первинним індикатором типів помилок, викликаних системними затримками або проблемами з продуктивністю.
Network Interface-Bytes total/sec	Число байтів, що проходять по мережному інтерфейсу за секунду. Коли показник цього лічильника знижується або має таку тенденцію, це вказує на те, що проблеми з мережею можуть впливати на програму
PhysicalDisk-Disk Transfers/sec	Оцінка дискових операцій читання/запису. Встановіть лічильник для кожного фізичного диска на сервері
Processor-% Processor Time	Відсоткове співвідношення часу, що процесор витрачає виконання робочого потоку. Цей лічильник працює як первинний індикатор діяльності процесора. Якщо всі процесори, що працюють на SQL Server, показують стовідсоткове використання, запити кінцевого користувача, швидше за все, ігноруються
SQLServer:Access Methods-Full Scans/sec	Число необмежених заповнених таблиць або індексних сканувань за секунду. Зниження значень цього лічильника на краще, тому що перегляди часто викликають брак ресурсів проблеми кешування
SQLServer:Buffer Manager-Buffer Cache Hit Ratio	Відсоткове ставлення сторінок, які вимагали читання від диска. Чим вище їх кількість, тим менше вводу/виводу на диск. У добре налаштованій системі це значення має бути 80 або вищим.
SQLServer:Databases-Log Growths	На скільки для конкретної бази даних виріс файл транзакцій. У добре налаштованій системі значення цього лічильника має бути низьким, ймовірно, менше ніж один за кілька днів
SQLServer:Databases Application Database-Percent Log Used	Відсоткове відношення вільного місця у журнальному файлі. Цей лічильник планово варіює, але не повинен досягати 100
SQLServer:Databases Application Database-Transactions/sec	Число транзакцій, підтверджених у базі даних. Цей лічильник часом опускається в стандартах. Слідкуйте за тим, коли транзакції починають шикуватися в чергу, це вказує на те, що дискове введення/виведення може бути повільним
SQLServer:Latches-Average Latch Wait Time	Середній час затримки запиту перед заповненням. Це значення лічильника може бути високим, коли сервер стикається із суперництвом за ресурси, особливо за пам'ять або за введення/виведення
SQLServer:Locks-Average Wait Time, Lock Waits/sec, Number of Deadlocks/sec	Тимчасові блокування утримують ресурси SQL Server. Спостерігайте за висхідною тенденцією цих пов'язаних із блокуванням лічильників, що вказує на можливу проблему з продуктивністю
SQLServer:General Statistics-User Connections	Число підключень до сервера бази даних. Перевіряйте будь-які помітні зрушення у значенні цього лічильника. Вони можуть вказувати на мережні проблеми та свідчити про навантаження та уповільнення
SQLServer:Memory Manager-Memory Grants Pending	Поточна кількість процесів, що очікують надання простору пам'яті. Високе чи зростаюче значення може вказувати на недостатній обсяг пам'яті
SQLServer:User Settable-Query (a tracer query)	Спеціалізований лічильник також відомий як покажчик запитів. Цей лічильник - створений користувачем запит, який вказує на загальну швидкість або ефективність системи. Щоб встановити це значення, програма викликає sp_user_counter1 і повертає числове значення.

Будь-якому адміністратору баз даних, напевно, доводилося стикатися з тим, що все працює повільно, або взагалі не працює. Перше, що при цьому потрібно з'ясувати - це те, що взагалі відбувається на SQL Server в даний момент. Здавалося б, що в арсеналі адміністратора стільки всяких корисних штук: гуєвий Activity Monitor, купа Dynamic Management Views (dmv), процедури sp_who і sp_who2, що зберігаються, що залишилися у спадок ще з часів SQL Server 7 і SQL Server 2000.
Але, давайте розберемося.

Засоби моніторингу

Activity Monitor

Здавалося б, чудова штука, займається саме тим, що треба - моніторить активність. Запускаю важкий бухгалтерський звіт і дивлюся, що мені покаже Activity Monitor.
На скріншотах монітор активності від SQL Server 2005:

та від SQL Server Denali (2012) CTP 3.


М-так. А якщо десяток людей запустить такі звіти? Але ж це не рідкість... Розбиратися буде досить незручно, хоча, звичайно, прогрес на обличчя. У Denali Activity Monitor показує набагато більше корисної інформації (наприклад, на якому конкретно ресурсі відбувається очікування), плюс, ми можемо, наприклад, для потрібної сесії запустити профайлер прямо з монітора і відстежувати її вже в профайлері, але, чорт забирай, він додатково навантажує і без того навантажений сервер. До того ж проблема з гальмами вже є, а ті запити, які на момент запуску профайлера вже почали виконуватися, ми не побачимо.
А я хочу бачити саме це – хто і що виконує саме зараз.

sp_who та sp_who2

На скріншоті результат виконання sp_who (згори) та sp_who2 (знизу), виконаних під час побудови того ж злощасного звіту:


Ага. Дуже інформативно. Дивлячись на sp_who, ми можемо побачити тільки те, що щось виконується. Звичайно виконується – ми ж для того й дивимося, а бачимо, що виконується якийсь SELECT. Або кілька якихось SELECT"ів. Здорово.
sp_who2 показує більше інформації. Тепер ми можемо бачити, скільки процесорного часу витрачено сесією (і стовпчиком скласти сумарний час, мабуть), кількість i/o-операцій, ім'я бази даних в якій все це виконується і ким заблокована ця сесія (якщо вона заблокована).
Activity Monitor, як бачимо, дає більше інформації.

DMV

Починаючи з SQL Server 2005, ми отримали нову можливість отримувати інформацію про стан сервера – Dynamic Management Views. MSDN говорить так: "Динамічні адміністративні уявлення та функції повертають дані про стан сервера, які можуть використовуватися для контролю справності екземпляра сервера, діагностики проблем та налаштування продуктивності.".
І дійсно, в 2005-му SQL Server є набір уявлень, пов'язаних з виконанням запитів в даний момент (втім, для перегляду "історії" теж є уявлення): ось вони. І їх кількість, від версії до версії продовжує збільшуватися!
Напевно, мастисті адміністратори мають напоготові купу скриптів, що дозволяють отримати інформацію про поточний стан сервера, але що робити, якщо досвіду роботи з DMV ще немає, а проблеми вже є?

sp_WhoIsActive

Adam Machanic (SQL Server MVP і MCITP) розробив і постійно допрацьовує збережену процедуру sp_WhoIsActive, яка спирається якраз на ці самі DMV і страшенно легка у використанні. Завантажити останню версію sp_WhoIsActive можна. Сам Адам має цикл статей, присвячених sp_WhoIsActive, що складається аж із 30 (тридцяти!) штук, почитати його можна, а я ж, постараюся зацікавити вас у прочитанні цього матеріалу:).
Отже, вважатимемо, що ви завантажили і запустили цей скрипт на одному з тестових серверів (на будь-якій версії, починаючи з 2005 і закінчуючи Denali). Адам радить зберігати її в системній базі даних master, щоб її можна було викликати в контексті будь-якої БД, але це не обов'язково, просто при виклику її в контексті іншої БД доведеться писати назву повністю - БД.схема.sp_whoIsActive.
Отже, спробуємо. На скріншоті результат її виконання під час побудови того самого звіту:

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

• - для активного запиту показує час виконання, для "сплячої" сесії - час "сну";
• - Власне, spid;
• - показує текст виконуваного зараз запиту, чи текст останнього виконаного запиту, якщо сесія спить;
• - Ну ви зрозуміли;
• - Дуже цікавий стовпець. Він виводиться у форматі (Ax: Bms/Cms/Dms)E. А - це кількість завдань, що очікують на ресурсі E. B/C/D - це час очікування в мілісекундах. Якщо очікує звільнення ресурсу лише одна сесія (як на скріншоті), буде показано її час очікування, якщо 2 сесії – їх час очікування у форматі B/C. Якщо ж очікують 3 і більше - ми побачимо мінімальний, середній та максимальний час очікування на цьому ресурсі у форматі B/C/D;
• - для активного запиту - сумарний час ЦП, витрачений цим запитом, для сплячої сесії - сумарний час ЦП за "все життя" цієї сесії;
• - для активного запиту – це кількість операцій запису в TempDB за час виконання запиту; для сплячої сесії - сумарна кількість записів у TempDB за весь час життя сесії;
• - для активного запиту – кількість сторінок у TempDB, виділених для цього запиту; для сплячої сесії - сумарна кількість сторінок у TempDB, виділених за весь час життя сесії;
• - якщо раптом ми заблоковані кимось, покаже spid (session_id) того, ким ми заблоковані;
• - для активного запиту - кількість логічних читань, виконаних при виконанні цього запиту; для сплячої сесії - кількість прочитаних сторінок за весь час життя цієї сесії;
• - все те саме, але про запис;
• - для активного запиту – кількість фізичних читань, виконаних при виконанні цього запиту; для сплячої сесії - зазвичай, сумарна кількість фізичних читань протягом усього життя сесії;
• - для активного запиту кількість восьмикілобайтових сторінок, використаних при виконанні цього запиту; для сплячої сесії - скільки сумарно сторінок пам'яті виділялося їй за її час життя;
• - статус сесії – виконується, спить тощо;
• - показує кількість транзакцій, відкритих цією сесією;
• - показує, якщо така можливість, процес виконання операції (наприклад, BACKUP, RESTORE), ніколи не покаже на скільки відсотків виконано SELECT.

Інші стовпці в стандартному висновку sp_WhoIsActive малоцікаві, і описувати їх я не буду - їхнє призначення, я думаю, зрозуміло всім (host_name, database_name, program_name, start_time, login_time, request_id, collection_time).

І чо? Це все?

Ні, це ще не все. Ще я розповім про те з якими (найцікавішими і кориснішими, на мій погляд) параметрами можна викликати sp_WhoIsActive і що з цього вийде.

• @help - це дуже корисний параметр. При викликі sp_whoIsActive @help = 1 , ми отримуємо на екран інформацію про ВСІ параметри і стовпці, що виводяться. Тож якщо щось залишиться незрозумілим, завжди можна подивитися "допомогу"
• @filter_type та @filter - дозволяють відфільтрувати результат виконання. @filter_type може приймати значення "session", "program", "database", "login" та "host". У параметрі @filter ми вказуємо, який саме об'єкт обраного типу нас цікавить. Наприклад, ми хочемо побачити всі сесії, що виконуються в БД master, для цього викликаємо exec sp_whoIsActive @filter_type = "database", @filter = "master". У параметрі @filter можна використовувати "%";
• @not_filter_type та @not_filter - дозволяють нам фільтрувати "навпаки". Тобто, наприклад, ми хочемо бачити всі, крім тих сесій, у яких в полі "database" стоїть "master", для цього виконуємо exec sp_WhoIsActive @not_filter_type = "database", @not_filter = "master". Ну, або, ми захочемо побачити що виконують всі користувачі крім користувача sa… Застосувань може бути безліч. У параметрі @not_filter допустиме використання %;
• @show_system_spids = 1 - покаже інформацію про системні сесії;
• @get_full_inner_text = 1 - у полі sql_text буде перебувати не просто текст поточного запиту (стейтмента) у пакеті (батчі), а текст всього батча цілком;
• @get_plans - додасть до висновку стовпець із планами виконання запитів;
• @get_transaction_info = 1 - додасть до висновку кількість та обсяг записів до журналів транзакцій, а також час початку останньої транзакції;
• @get_locks = 1 - додасть до висновку інформацію про всі блокування, накладені під час виконання запиту;
• @find_block_leaders = 1 - простежить ланцюжок блокувань і покаже сумарну кількість сесій, що очікують на зняття блокування поточною сесією;
• @output_column_list = "[%]" - а раптом ви не хочете бачити інформацію про tempDB у виведенні sp_whoIsActive? За допомогою цього параметра можна керувати тим, що виводить;
• @destination_table = "table_name" - спробує вставити результат виконання записати в таблицю, але не перевіряти чи існує ця таблиця і чи вистачає прав на вставку до неї.

Ось тепер все

У результаті, ми маємо ще один надзвичайно зручний та гнучкий інструмент для відстеження поточної активності на SQL Server. Для нормальної його роботи цілком достатньо дозволу VIEW SERVER STATE та прав на звернення до dmv.
Варто також додати, в тому випадку, коли до сервера можливе підключення тільки через

Список контрольних питань аудиту продуктивності

Введіть результати в таблицю, наведену вище.

Використання монітора продуктивності (Performance Monutor) для ідентифікації вузьких місць апаратних засобів SQL Server

Найкраще розпочати аудит продуктивності SQL Server з монітора продуктивності (System Monitor). Моніторинг кількох основних лічильників за період 24 годин дозволить вам отримати досить гарне уявлення про будь-які головні апаратні проблеми, які позначаються на продуктивності SQL Server.

В ідеалі Ви повинні використовувати монітор продуктивності для створення файлу реєстрації (журналу) показань ключових лічильників на 24 години. Ви маєте вибрати "типовий" 24-годинний період для створення файлу реєстрації. Наприклад, виберіть типовий робочий день, не кінець тижня чи свято.

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

Як інтерпретувати ключові лічильники монітора продуктивності

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

Пам'ять: Сторінки/секунди

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

У припущенні, що SQL Server є єдиним головним додатком, що виконується на вашому сервері, це число має в ідеалі перебувати в інтервалі між нулем і 20. Цілком імовірно, що Ви спостерігатимете викиди, що значно перевищують 20, що цілком нормаллю. Основним тут є підтримка середнього значення обміну сторінками за секунду менше 20.

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

У більшості випадків, на фізичному сервері, спеціалізованому під SQL Server, з адекватною кількістю оперативної пам'яті, середнє значення обміну сторінками буде менше 20. Адекватну кількість оперативної пам'яті для SQL Server можна визначити за таким критерієм: сервер повинен мати коефіцієнт вдалого звернення в кеш буфера (Buffer Hit Cache Ratio) 99% та вище. Даний лічильник описаний нижче у цій статті. Якщо Ви маєте SQL Server, у якого цей коефіцієнт має значення 99 % або вище протягом 24 годин, але Ви отримуєте середнє значення обміну сторінками більше 20 протягом того самого періоду часу, це може вказувати на те, що у Вас виконуються й інші програми на фізичному сервері крім SQL Server. Якщо справа саме так, Ви повинні в ідеальному випадку видалити ці програми, дозволивши SQL Server бути єдиним головним додатком на фізичному сервері.

Якщо ваш сервер SQL не виконує жодних інших програм, і обмін сторінками перевищує 20 в середньому протягом 24 годин, це може означати, що Ви змінили параметри налаштування пам'яті SQL Server. SQL Server має бути конфігурований так, щоб була встановлена ​​опція "Dynamically configure SQL Server memory" (Динамічно конфігурувати пам'ять SQL Server), а установка "Maximum Memory" повинна знаходитись у найбільшому значенні. Для оптимальної роботи SQL Server потрібно дозволити взяти стільки оперативної пам'яті, скільки йому потрібно для власних потреб, не відчуваючи необхідності конкурувати за оперативну пам'ять з іншими програмами.

Пам'ять: Доступний простір

Інший спосіб з'ясувати, чи має ваш SQL Server достатньо фізичної оперативної пам'яті, полягає в тому, щоб перевірити лічильник Memory Object: Available Bytes. Його значення має бути понад 5 МБ. В іншому випадку, ваш сервер SQL потребує більшої кількості фізичної оперативної пам'яті. На сервері, що спеціалізується під SQL Server, останній намагається утримувати від 4-10MB вільної фізичної пам'яті. Фізична оперативна пам'ять, що залишилася, використовується операційною системою і SQL Server. Коли обсяг доступної пам'яті близько до 5 МБ або нижче, найбільш ймовірно, що SQL Server зазнає перевантаження через брак пам'яті. Якщо це має місце, Ви повинні збільшити кількість фізичної оперативної пам'яті на сервері, зменшити навантаження на сервер або змінити параметри конфігурації пам'яті вашого SQL Server відповідно.

Фізичний диск: Час роботи диска %

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

Як емпіричне правило, лічильник часу диска має показувати менше 55%. Якщо показання лічильника перевищують 55 % протягом безперервних періодів (понад 10 хвилин протягом 24 годин моніторингу), то ваш SQL Server може мати проблеми з операціями введення/виведення. Якщо Ви спостерігаєте цю поведінку лише зрідка протягом ваших 24 годин моніторингу, я б не хвилювався надто сильно, але якби це траплялося часто (скажімо, кілька разів на годину), то я почав би шукати способи збільшити продуктивність операцій вводу/виводу на сервері або зменшити завантаження сервера. Деякі способи збільшувати дискове введення/виведення полягають у додаванні нових дисків до масиву (якщо це можливо), заміні дисків на більш швидкі, додаванні кеш-пам'яті на платі контролера (якщо це можливо), використання різних версій RAID або встановлення швидкішого контролера.

Перед використанням цього лічильника під NT 4.0 потрібно вручну включити його, ввівши в Command Prompt наступне: "diskperf-y". Після цього потрібно буде перезавантажити сервер. Таким чином потрібно відразу включати дискові лічильники під Windows NT 4.0. Якщо Ви працюєте під Windows 2000, цей лічильник увімкнено за замовчуванням.

Фізичний диск: Середня довжина черги диска

Крім спостереження за значенням лічильника "Фізичний диск: Час роботи диска", бажано також відстежувати значення лічильника середньої довжини черги диска (Avg. Disk Queue Length). Якщо це значення перевищує значення 2 для безперервних періодів (понад 10 хвилин протягом вашого 24 годинного моніторингу) для кожного дисководу в масиві, цей масив може виявитися вузьким місцем продуктивності системи. Подібно до лічильника часу роботи диска, якщо це відбувається зрідка протягом 24 годин періоду моніторингу, я не сильно б хвилювався, але якщо це відбувається часто, тоді я б почав шукати способи збільшити продуктивність системи введення/виводу сервера, як це описано вище.

Вам доведеться обчислити цей показник, оскільки Performance Monitor не знає скільки фізичних дисків знаходиться у вашому масиві. Наприклад, якщо у вас є масив з 6 фізичних дисків і середня довжина черги дорівнює 10 для цього масиву, тоді фактичне середнє значення дискової черги для кожного диска становить 1.66 (10/6=1.66), що добре вкладається в рекомендований показник 2 на один фізичний диск.

Перед використанням цього лічильника під NT 4.0, не забудьте вручну включити його, набравши на запрошення до введення команд NT (Command Prompt) наступне: "diskperf-y" з наступним перезавантаженням вашого сервера. Тому потрібно вмикати дискові лічильники відразу після інсталяції Windows NT 4.0. Якщо Ви використовуєте Windows 2000, цей лічильник буде включений за замовчуванням.

Використовуйте обидва описані вище лічильники, щоб точно з'ясувати, чи зазнає ваш сервер проблеми з системою введення/виведення. Наприклад, якщо Ви бачите багато періодів часу, протягом яких час роботи диска більше 55 %, і коли середнє значення довжини черги диска становить більше 2 на один фізичний диск, Ви можете бути впевненими, що сервер має проблеми із системою введення – виведення.

Процесор: Процесорний час %

Лічильник Processor Object: % Processor Time є для кожного центрального процесора та оцінює використання кожного окремого центрального процесора. Аналогічний лічильник є також для всієї сукупності центральних процесорів (загальна кількість). Це ключовий лічильник для стеження використання центрального процесора. Якщо загальний час завантаження процесорів за цим лічильником перевищує 80 % протягом безперервних періодів (понад 10 хвилин протягом 24 годинного періоду моніторингу), Ви можете вважати центральний процесор вузьким місцем системи. Якщо ці періоди сильного завантаження відбуваються зрідка, і Ви вважаєте, що можете змиритися з цим, то все гаразд. Але якщо вони виникають часто, Вам слід розглянути такі варіанти зниження завантаження сервера, як придбання швидших центральних процесорів, встановлення більшої кількості центральних процесорів або придбання центральних процесорів, які мають більший вбудований кеш другого рівня (L2).

Система: Довжина черги процесора

Поряд із лічильником процесорного часу, Вам слід також контролювати лічильник довжини черги процесора (Processor Queue Length). Якщо цей показник перевищує значення 2 на один центральний процесор протягом безперервних періодів (понад 10 хвилин протягом 24 годинного періоду моніторингу), то ймовірно це є вузькою ланкою системи. Наприклад, якщо на Вашому сервері є 4 центральні процесори, довжина черги процесора не повинна перевищувати загалом значення 8.

Якщо довжина черги процесора регулярно перевищує рекомендований максимум, але використання центрального процесора не настільки високо (що є типовим випадком), розгляньте варіант зменшення значення конфігураційного параметра SQL Server "max worker threads" (максимального числа ниток). Можливою причиною високого значення довжини черги процесора є наявність надлишкового числа робочих ниток, що чекають своєї черги. Зменшуючи їх кількість, що Ви і робите за допомогою цього параметра, змушує задіяти пулінг ниток (якщо це ще немає), або підвищити його роль.

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

Буфер SQL Server: Коефіцієнт вдалого звернення до кешу буфера

Цей лічильник (SQL Server Buffer: Buffer Cache Hit Ratio) показує, як часто SQL Server звертається до буфера, а не жорсткого диска, щоб отримати дані. У додатках OLTP цей коефіцієнт повинен перевищувати 90%, а в ідеалі бути вище 99%. Якщо ваш коефіцієнт вдалого звернення до буферного кешу нижче 90%, Вам слід піти та купити більше оперативної пам'яті вже сьогодні. Якщо цей коефіцієнт лежить у діапазоні між 90% і 99%, то Ви повинні серйозно розглянути варіант купівлі додаткової оперативної пам'яті, оскільки чим ближче Ви наближаєтеся до 99%, тим швидше ваш SQL Server працюватиме. У деяких випадках, якщо ваша база даних є дуже великою, Вам не вдасться наблизитися до 99%, навіть якщо Ви поставите максимальну кількість оперативної пам'яті на вашому сервері. Тоді все, що Ви можете зробити - це додати пам'ять по максимуму і змиритися з існуючим станом речей.

У додатках OLAP коефіцієнт може бути набагато меншим через природу роботи цього OLAP-додатка. У будь-якому випадку збільшення оперативної пам'яті має прискорити роботу SQL Server.

SQL Server: Користувальницькі підключення

Оскільки кількість користувачів Сервер SQL, впливає на його продуктивність, рекомендується стежити за лічильником підключення користувача (SQL Server General Statistics Object: User Connections counter). Він показує кількість підключень користувача, а не кількість користувачів, які підключені до SQL Server в даний момент часу.

Якщо показання цього лічильника перевищують 255, Вам слід збільшити значення конфігураційного параметра "Maximum Worker Threads" (максимальна кількість робочих ниток), значення за замовчуванням якого дорівнює 255. Якщо число підключень перевищує наявне число робочих ниток, то SQL Server почне спільно використовувати робочі нитки що може негативно позначитися на продуктивності. Встановлення цього параметра має бути вищим, ніж максимальна кількість підключень, яка може бути досягнута на вашому сервері.

Що далі

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

Будь-якому адміністратору баз даних, напевно, доводилося стикатися з тим, що все працює повільно, або взагалі не працює. Перше, що при цьому потрібно з'ясувати - це те, що взагалі відбувається на SQL Server в даний момент. Здавалося б, що в арсеналі адміністратора стільки всяких корисних штук: гуєвий Activity Monitor, купа Dynamic Management Views (dmv), процедури sp_who і sp_who2, що зберігаються, що залишилися у спадок ще з часів SQL Server 7 і SQL Server 2000.
Але, давайте розберемося.

Засоби моніторингу

Activity Monitor

Здавалося б, чудова штука, займається саме тим, що треба - моніторить активність. Запускаю важкий бухгалтерський звіт і дивлюся, що мені покаже Activity Monitor.
На скріншотах монітор активності від SQL Server 2005:

І від SQL Server Denali (2012) CTP 3.


М-так. А якщо десяток людей запустить такі звіти? Але ж це не рідкість... Розбиратися буде досить незручно, хоча, звичайно, прогрес на обличчя. У Denali Activity Monitor показує набагато більше корисної інформації (наприклад, на якому конкретно ресурсі відбувається очікування), плюс, ми можемо, наприклад, для потрібної сесії запустити профайлер прямо з монітора і відстежувати її вже в профайлері, але, чорт забирай, він додатково навантажує і без того навантажений сервер. До того ж проблема з гальмами вже є, а ті запити, які на момент запуску профайлера вже почали виконуватися, ми не побачимо.
А я хочу бачити саме це – хто і що виконує саме зараз.

sp_who та sp_who2

На скріншоті результат виконання sp_who (згори) та sp_who2 (знизу), виконаних під час побудови того ж злощасного звіту:


Ага. Дуже інформативно. Дивлячись на sp_who, ми можемо побачити тільки те, що щось виконується. Звичайно виконується – ми ж для того й дивимося, а бачимо, що виконується якийсь SELECT. Або кілька якихось SELECT"ів. Здорово.
sp_who2 показує більше інформації. Тепер ми можемо бачити, скільки процесорного часу витрачено сесією (і стовпчиком скласти сумарний час, мабуть), кількість i/o-операцій, ім'я бази даних в якій все це виконується і ким заблокована ця сесія (якщо вона заблокована).
Activity Monitor, як бачимо, дає більше інформації.

DMV

Починаючи з SQL Server 2005, ми отримали нову можливість отримувати інформацію про стан сервера – Dynamic Management Views. MSDN говорить так: «Динамічні адміністративні уявлення та функції повертають дані про стан сервера, які можуть використовуватися для контролю справності екземпляра сервера, діагностики проблем та налаштування продуктивності.».
І дійсно, в 2005-му SQL Server є набір уявлень, пов'язаних з виконанням запитів в даний момент (втім, для перегляду «історії» теж є уявлення): ось вони. І їх кількість, від версії до версії продовжує збільшуватися!
Напевно, мастисті адміністратори мають напоготові купу скриптів, що дозволяють отримати інформацію про поточний стан сервера, але що робити, якщо досвіду роботи з DMV ще немає, а проблеми вже є?

sp_WhoIsActive

Adam Machanic (SQL Server MVP і MCITP) розробив і постійно допрацьовує збережену процедуру sp_WhoIsActive, яка спирається якраз на ці самі DMV і страшенно легка у використанні. Завантажити останню версію sp_WhoIsActive можна. Сам Адам має цикл статей, присвячених sp_WhoIsActive, що складається аж із 30 (тридцяти!) штук, почитати його можна, а я ж, постараюся зацікавити вас у прочитанні цього матеріалу:).
Отже, вважатимемо, що ви завантажили і запустили цей скрипт на одному з тестових серверів (на будь-якій версії, починаючи з 2005 і закінчуючи Denali). Адам радить зберігати її в системній базі даних master, щоб її можна було викликати в контексті будь-якої БД, але це не обов'язково, просто при виклику її в контексті іншої БД доведеться писати назву повністю - БД.схема.sp_whoIsActive.
Отже, спробуємо. На скріншоті результат її виконання під час побудови того самого звіту:

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

• - для активного запиту показує час виконання, для сплячої сесії - час сну;
• - Власне, spid;
• - показує текст виконуваного зараз запиту, чи текст останнього виконаного запиту, якщо сесія спить;
• - Ну ви зрозуміли;
• - Дуже цікавий стовпець. Він виводиться у форматі (Ax: Bms/Cms/Dms)E. А - це кількість завдань, що очікують на ресурсі E. B/C/D - це час очікування в мілісекундах. Якщо очікує звільнення ресурсу лише одна сесія (як на скріншоті), буде показано її час очікування, якщо 2 сесії – їх час очікування у форматі B/C. Якщо ж очікують 3 і більше - ми побачимо мінімальний, середній та максимальний час очікування на цьому ресурсі у форматі B/C/D;
• - для активного запиту - сумарний час ЦП, витрачений цим запитом, для сплячої сесії - сумарний час ЦП за «все життя» цієї сесії;
• - для активного запиту – це кількість операцій запису в TempDB за час виконання запиту; для сплячої сесії - сумарна кількість записів у TempDB за весь час життя сесії;
• - для активного запиту – кількість сторінок у TempDB, виділених для цього запиту; для сплячої сесії - сумарна кількість сторінок у TempDB, виділених за весь час життя сесії;
• - якщо раптом ми заблоковані кимось, покаже spid (session_id) того, ким ми заблоковані;
• - для активного запиту - кількість логічних читань, виконаних при виконанні цього запиту; для сплячої сесії - кількість прочитаних сторінок за весь час життя цієї сесії;
• - все те саме, але про запис;
• - для активного запиту – кількість фізичних читань, виконаних при виконанні цього запиту; для сплячої сесії - зазвичай, сумарна кількість фізичних читань протягом усього життя сесії;
• - для активного запиту кількість восьмикілобайтових сторінок, використаних при виконанні цього запиту; для сплячої сесії - скільки сумарно сторінок пам'яті виділялося їй за її час життя;
• - статус сесії – виконується, спить тощо;
• - показує кількість транзакцій, відкритих цією сесією;
• - показує, якщо така можливість, процес виконання операції (наприклад, BACKUP, RESTORE), ніколи не покаже на скільки відсотків виконано SELECT.

Інші стовпці в стандартному висновку sp_WhoIsActive малоцікаві, і описувати їх я не буду - їхнє призначення, я думаю, зрозуміло всім (host_name, database_name, program_name, start_time, login_time, request_id, collection_time).

І чо? Це все?

Ні, це ще не все. Ще я розповім про те з якими (найцікавішими і кориснішими, на мій погляд) параметрами можна викликати sp_WhoIsActive і що з цього вийде.

• @help - це дуже корисний параметр. При викликі sp_whoIsActive @help = 1 , ми отримуємо на екран інформацію про ВСІ параметри і стовпці, що виводяться. Тож якщо щось залишиться незрозумілим, завжди можна подивитися «допомогу»
• @filter_type та @filter - дозволяють відфільтрувати результат виконання. @filter_type може приймати значення "session", "program", "database", "login" та "host". У параметрі ми вказуємо, який саме об'єкт обраного типу нас цікавить. Наприклад, ми хочемо побачити всі сесії, що виконуються в БД master, для цього викликаємо exec sp_whoIsActive @filter_type = "database", = "master". У параметрі допустиме використання "%";
• @not_filter_type і @not_filter - дозволяють нам фільтрувати "навпаки". Тобто, наприклад, ми хочемо бачити все, окрім тих сесій, у яких в полі "database" стоїть "master", для цього виконуємо exec sp_WhoIsActive @not_filter_type = "database", @not_filter = "master". Ну, або, ми захочемо побачити що виконують всі користувачі крім користувача sa… Застосувань може бути безліч. У параметрі @not_filter допустиме використання %;
• @show_system_spids = 1 - покаже інформацію про системні сесії;
• @get_full_inner_text = 1 - у полі sql_text буде перебувати не просто текст поточного запиту (стейтмента) у пакеті (батчі), а текст всього батча цілком;
• @get_plans - додасть до висновку стовпець із планами виконання запитів;
• @get_transaction_info = 1 - додасть до висновку кількість та обсяг записів до журналів транзакцій, а також час початку останньої транзакції;
• @get_locks = 1 - додасть до висновку інформацію про всі блокування, накладені під час виконання запиту;
• @find_block_leaders = 1 - простежить ланцюжок блокувань і покаже сумарну кількість сесій, що очікують на зняття блокування поточною сесією;
• @output_column_list = "[%]" - а раптом ви не хочете бачити інформацію про tempDB у виведенні sp_whoIsActive? За допомогою цього параметра можна керувати тим, що виводить;
• @destination_table = "table_name" - спробує вставити результат виконання записати в таблицю, але не перевіряти чи існує ця таблиця і чи вистачає прав на вставку до неї.

Ось тепер все

У результаті, ми маємо ще один надзвичайно зручний та гнучкий інструмент для відстеження поточної активності на SQL Server. Для нормальної його роботи цілком достатньо дозволу VIEW SERVER STATE та прав на звернення до dmv.
Варто також додати, в тому випадку, коли до сервера можливе підключення тільки через