Розширене усунення неполадок з допомогою розширених подій, Інші СУБД, Бази даних, статті

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

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


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


Комплексна система додатків буде мати багато програмних і апаратних компонентів, які можуть вимагати аналізу, але тут мене цікавить один з них – SQL Server. Якщо не торкатися різних методологій усунення проблем продуктивності (розмова про яких вийде далеко за рамки цієї статті), які засоби, необхідні для усунення неполадок в SQL Server?


Усунення неполадок в SQL Server 2005


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


Хоча SQL Server постійно пропонував поліпшення в області усунення неполадок, у цих варіантів є певні проблеми. Послеобработка даних, які видаються DBCC, незграбна, через необхідність скидати результати в тимчасову таблицю, перш ніж з ними можна буде що-небудь зробити. І виконання трасування / Профілювальники SQL може викликати падіння продуктивності в разі невдалої установки (такий як відстеження всіх подій отримання і віддачі блокування на зайнятій системі, при якій забуто про фільтровку стовпців DatabaseId і ObjectId події). Знімок екрану на рис. 1 показує діалог, який використовується для настройки фільтра під нову трасування.


Збільшити

Рис. 1. Налаштування фільтру в Профілювальники SQL Server 2008


SQL Server 2005 додав динамічні уявлення і функції управління (спільно відомі як DMV) в якості способу отримання інформації від механізму бази даних. DMV замістили деякі команди DBCC, системні таблиці і збережені процедури, а також надали багато нових областей роботи з механізмом. Ці DMV є компонований командами з широкими можливостями – їх можна використовувати в комплексних операторах T-SQL, що виконують фільтрацію і постобробку результатів DMV.


Наприклад, код показаний на рис. 2 повертає лише показники фрагментації і щільності сторінки (обидва округлені) кінцевого рівня всіх індексів в базі даних, з фільтром на рівні фрагментації. Це не можна було зробити просто, використовуючи мою стару команду DBCC SHOWCONTIG. (Додаткові відомості про DMV см. в “Dynamic Management Views and Functions (Transact-SQL) (” Подання та функції динамічного управління (Transact-SQL) “)”. До того ж, SQL Server 2005 додав ряд інших функцій, які можна було використовувати для усунення неполадок, включаючи тригери DDL (мови визначення даних) та повідомлення про події.




Рис. 2. Використання DMV для отримання вражаючих результатів

SELECT
OBJECT_NAME (ips.[object_id]) AS “Object Name”,
si.name AS “Index Name”,
ROUND (ips.avg_fragmentation_in_percent, 2) AS “Fragmentation”,
ips.page_count AS “Pages”,
ROUND (ips.avg_page_space_used_in_percent, 2) AS “Page Density”
FROM sys.dm_db_index_physical_stats (
DB_ID (“SQLskillsDB”), NULL, NULL, NULL, “DETAILED”) ips
CROSS APPLY sys.indexes si
WHERE
si.object_id = ips.object_id
AND si.index_id = ips.index_id
AND ips.index_level = 0 — only the leaf level
AND ips.avg_fragmentation_in_percent > 10; — filter on fragmentation
GO

Різні групи всередині корпорації Майкрософт також надали корисні засоби усунення проблем продуктивності, такі як службова програми SQLdiag, службові програми RML для SQL Server, Звіти панелі моніторингу продуктивності SQL Server 2005 і DMVStats. Існує також провайдер відстеження подій для Windows (ETW) для SQL Server 2005, що дозволяє виконувати інтеграцію подій SQL Trace з подіями з інших частин Windows.


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


Розширені події


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




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


Подія Подія – це певна точка в коді. Деякими з прикладів є точка, на якій оператор T-SQL завершив виконуватися або точка, на якій завершено отримання блокування. Кожна подія має певні корисні дані (набір стовпців, що повертаються подією) і визначається з використанням моделі ETW (де кожна подія повертає канал і ключове слово як частину корисних даних), щоб дозволити інтеграцію з ETW. SQL Server 2008 спочатку постачався з 254 очікуваними подіями і, з плином часу, очікується додавання нових.


Список певних подій можна побачити, використовуючи наступний код:

SELECT xp.[name], xo.*
FROM sys.dm_xe_objects xo, sys.dm_xe_packages xp
WHERE xp.[guid] = xo.[package_guid]
AND xo.[object_type] = “event”
ORDER BY xp.[name];

А корисне навантаження для події можна знайти, використовуючи цей код:

SELECT * FROM sys.dm_xe_object_columns
WHERE [object_name] = “sql_statement_completed”;
GO

Відзначте, що у системи розширених подій є вичерпний набір інформаційних DMV, які описують всі події, цілі і так далі. Додаткові відомості див в “SQL Server Extended Events Dynamic Management Views (“Динамічні подання керування розширених подій SQL Server”) “.


Предикати Предикати є методом, використовуваним для фільтрації подій з використанням набору логічних правил, перед споживанням подій. Предикати можуть бути простими, такими як перевірка, є Чи один із стовпців, повернутих в корисному навантаженні, події, певним значенням (наприклад, фільтрація подій отримання блокування за ідентифікатором об’єкта).


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


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


Дія Дія – це набір команд, що виконуються синхронно, перед споживанням події. Будь-яка дія може бути прив’язане до будь-якої події. Зазвичай вони збирають додаткові дані для приєднання до корисної навантаженні події (такий, як стек T-SQL або план виконання запиту) або виконують певні обчислення, що приєднуються до корисної навантаженні події.


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

SELECT xp.[name], xo.*
FROM sys.dm_xe_objects xo, sys.dm_xe_packages xp
WHERE xp.[guid] = xo.[package_guid]
AND xo.[object_type] = “action”
ORDER BY xp.[name];

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


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

SELECT xp.[name], xo.*
FROM sys.dm_xe_objects xo, sys.dm_xe_packages xp
WHERE xp.[guid] = xo.[package_guid]
AND xo.[object_type] = “target”
ORDER BY xp.[name];

Додаткові відомості про цілі см. в “SQL Server Extended Events Targets (” Цілі розширених подій SQL Server “)”.


Пакет Пакет – це контейнер, що визначає об’єкти розширених подій (такі, як події, дії та цілі). Пакет міститься всередині описуваного їм модуля (такого, як виконуваний файл або DLL), як показано на рис. 3.



Рис. 4. Життєвий цикл події розширених подій

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

Використання розширених подій


Електронна документація SQL Server 2008 включає два приклади використання розширених подій: “Практичний посібник: визначення запитів, що утримують блокування” і “Практичне керівництво: пошук об’єктів, на яких взято найбільше число блокувань “.

Я хотів би розібрати приклад налаштування сеансу розширених подій та проаналізувати результати. Як я дізнався, коли почав використовувати розширені події в кінці 2007 року, зібрати простий сеанс дуже просто (За допомогою нехитрих операторів DDL T-SQL), але аналіз результатів – нетривіальна задача.

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

Треба зауважити, я був розробником в групі підсистеми сховища SQL Server протягом багатьох років і вважаю себе високопрофесійним програмістом C, C + + і зборок, але мені довелося провести кілька годин, розбираючись в коді, необхідному для програмного вилучення полів корисних навантажень з даних XML. Я не намагаюся відрадити читачів від використання розширених подій; я просто попереджаю, що тим, у кого немає досвіду роботи з даними XML, доведеться витратити деякі зусилля на навчання йому, перш ніж з’являться результати.

Ось мій сценарій: я адміністратор бази даних, що використовує функцію регулятора ресурсів в SQL Server 2008, щоб ізолювати різні групи в моєї компанії на одному з робочих серверів. Я створив два пула регулятора ресурсів (розробки та маркетингу) для подання використання даного сервера кожної з груп. Регулятор ресурсів дозволяє мені обмежувати використання ЦП і пам’яті на виконання запитів кожним пулом, але не обсяг використовуваних ними ресурсів вводу / виводу. Так що мені хотілося б встановити механізм зворотних платежів, що допомагає компенсувати витрати на установку нової мережі, виставляючи кожній групі рахунок за використання введення / виводу на цьому сервері.

Я припускаю, що найпростішим способом ініціалізації запису інформації введення / виводу буде робити це, коли завершується робота будь-якого оператора T-SQL і я знаю, що в пакеті package0 є подія, що називається sql_statement_completed. Так які ж дані збираються в корисному навантаженні події?

Виконання такого коду дасть мені список всіх даних, включаючи як читання, так і записи:

SELECT [name] FROM sys.dm_xe_object_columns
WHERE [object_name] = “sql_statement_completed”;
GO

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

Тепер мені потрібно обчислити, яка група виконала певний оператор T-SQL, так що потрібно дія, яка сказало б мені це. Виконання коду дає мені список усіх дій, які я можу зробити при запуску події включаючи дію, що збирає session_resource_pool_id в пакеті sqlserver:

SELECT xp.[name], xo.*
FROM sys.dm_xe_objects xo, sys.dm_xe_packages xp
WHERE xp.[guid] = xo.[package_guid]
AND xo.[object_type] = “action”
ORDER BY xp.[name];

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

IF EXISTS (
SELECT * FROM sys.server_event_sessions
WHERE name = “MonitorIO”)
DROP EVENT SESSION MonitorIO ON SERVER;
GO
CREATE EVENT SESSION MonitorIO ON SERVER
ADD EVENT sqlserver.sql_statement_completed
(ACTION (sqlserver.session_resource_pool_id))
ADD TARGET package0.ring_buffer;
GO

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

Для початку мого сеансу, мені потрібно виконати такий код:

ALTER EVENT SESSION MonitorIO ON SERVER
STATE = START;
GO

Тепер він працює.

Після імітації деякого обсягу діяльності груп маркетингу і розробки, я готовий до аналізу результатів сеансу. Даний код витягне дані з кільцевого буфера:

SELECT CAST(xest.target_data AS XML) StatementData
FROM sys.dm_xe_session_targets xest
JOIN sys.dm_xe_sessions xes ON
xes.address = xest.event_session_address
WHERE xest.target_name = “ring_buffer”
AND xes.name = “MonitorIO”;
GO

Однак, він витягує дані як одне велике значення XML. Якщо мені потрібно розбити його на складові, я можу використовувати код, показаний на рис. 5.

Рис. 5. Розбиття даних XML

SELECT
Data2.Results.value (“(data/.)[6]”, “bigint”) AS Reads,
Data2.Results.value (“(data/.)[7]”, “bigint”) AS Writes,
Data2.Results.value (“(action/.)[1]”, “int”) AS ResourcePoolID
FROM
(SELECT CAST(xest.target_data AS XML) StatementData
FROM sys.dm_xe_session_targets xest
JOIN sys.dm_xe_sessions xes ON
xes.address = xest.event_session_address
WHERE xest.target_name = “ring_buffer”
AND xes.name = “MonitorIO”) Statements
CROSS APPLY StatementData.nodes (“//RingBufferTarget/event”) AS Data2 (Results);
GO

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

Рис. 6. Отримання зведеного висновку

SELECT DT.ResourcePoolID,
SUM (DT.Reads) as TotalReads,
SUM (DT.Writes) AS TotalWrites
FROM
(SELECT
Data2.Results.value (“(data/.)[6]”, “bigint”) AS Reads,
Data2.Results.value (“(data/.)[7]”, “bigint”) AS Writes,
Data2.Results.value (“(action/.)[1]”, “int”) AS ResourcePoolID
FROM
(SELECT CAST(xest.target_data AS XML) StatementData
FROM sys.dm_xe_session_targets xest
JOIN sys.dm_xe_sessions xes ON
xes.address = xest.event_session_address
WHERE xest.target_name = “ring_buffer”
AND xes.name = “MonitorIO”) Statements
CROSS APPLY StatementData.nodes (“//RingBufferTarget/event”) AS Data2 (Results)) AS DT
WHERE DT.ResourcePoolID > 255 — only show user-defined resource pools
GROUP BY DT.ResourcePoolID;
GO

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




Рис. 7. Вихідні дані мого запиту















ResourcePoolID

TotalReads

TotalWrites
256 3831 244
257 5708155 1818

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

І, нарешті, мені потрібно зупинити сеанс, використовуючи наступний код:

ALTER EVENT SESSION MonitorIO ON SERVER
STATE = STOP;
GO

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

Сеанс розширених подій system_health


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

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

SELECT CAST (xest.target_data AS XML)
FROM sys.dm_xe_session_targets xest
JOIN sys.dm_xe_sessions xes ON
xes.address = xest.event_session_address
WHERE xes.name = “system_health”;
GO

Висновок


Мені сказали, що група SQL Server планує, в майбутньому, додати в sqlserver.exe багато нових подій. Фактично, число підскочило з 165 в CTP-версії лютого 2007 року (подання спільноті) до 254 в RTM-версії (остаточна первісна).

Варто також звернути увагу на деякі дійсно цікаво виглядають події, наприклад події запису даних змін (яке я висвітлив у своїй статті “Відстеження змін в корпоративній базі даних “з випуску журналу TechNet Magazine за листопад 2008 року), стиснення даних і розбиття сторінок індексів. Розбиття сторінок індексів виглядає багатообіцяючим способом з’ясування того, які індекси накопичують підриває продуктивність фрагментацію, без необхідності періодично виконувати DMV sys.dm_db_index_physical_stats на всіх індексах.

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*