مثالهای عملی
مثال 1: بررسی وجود Event در نسخه جاری
در این سناریو هدف، تأیید نام Package Object پیش از Deployment است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
o.name AS event_name,
o.description
FROM sys.dm_xe_objects AS o
WHERE o.object_type = N'event'
AND o.name = N'xml_deadlock_report';
| خروجی نمونه | تفسیر |
|---|
| xml_deadlock_report | Occurs when a deadlock is detected | نتیجه نمایشی مثال 1؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
وجود Event به معنی فعال بودن Collector نیست؛ Session و Target را جداگانه بررسی کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 2: ساخت Session اختصاصی Ring Buffer
در این سناریو هدف، ایجاد Collector کوچک و Idempotent برای Lab است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'Capture_Deadlocks')
DROP EVENT SESSION [Capture_Deadlocks] ON SERVER;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
CREATE EVENT SESSION [Capture_Deadlocks] ON SERVER
ADD EVENT sqlserver.xml_deadlock_report
ADD TARGET package0.ring_buffer(SET max_memory = 4096)
WITH (STARTUP_STATE = ON);
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
| خروجی نمونه | تفسیر |
|---|
| Capture_Deadlocks با startup_state فعال تعریف میشود | نتیجه نمایشی مثال 2؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
DROP قبلی تاریخچه را حذف میکند؛ در Production از ALTER و نسخهبندی بدون از دست دادن شواهد استفاده کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 3: شروع Session و کنترل وضعیت
در این سناریو هدف، فعالسازی Runtime و اثبات Started بودن است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
ALTER EVENT SESSION [Capture_Deadlocks] ON SERVER STATE = START;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
SELECT s.name, s.create_time
FROM sys.dm_xe_sessions AS s
WHERE s.name = N'Capture_Deadlocks';
| خروجی نمونه | تفسیر |
|---|
| Capture_Deadlocks | 2026-07-22 05:30 | نتیجه نمایشی مثال 3؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
STARTUP_STATE فقط رفتار پس از Restart را تعیین میکند و Session تازه را لزوماً همان لحظه Start نمیکند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 4: خواندن xml_report از Ring Buffer
در این سناریو هدف، استخراج Payload اصلی Event از Target حافظه است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
;WITH rb AS
(
SELECT CAST(t.target_data AS xml) AS target_xml
FROM sys.dm_xe_session_targets AS t
JOIN sys.dm_xe_sessions AS s ON s.address = t.event_session_address
WHERE s.name = N'Capture_Deadlocks'
AND t.target_name = N'ring_buffer'
)
SELECT
e.n.value('@timestamp', 'datetime2') AS event_utc,
e.n.query('(data[@name="xml_report"]/value/deadlock)[1]') AS deadlock_xml
FROM rb
CROSS APPLY target_xml.nodes('/RingBufferTarget/event[@name="xml_deadlock_report"]') AS e(n)
ORDER BY event_utc DESC;
| خروجی نمونه | تفسیر |
|---|
| 2026-07-22 03:31:04 | <deadlock>...</deadlock> | نتیجه نمایشی مثال 4؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
اگر Ring Buffer خالی است، وقوع Deadlock، Started بودن Session و Drop Count را بررسی کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 5: ساخت Event File با Rollover
در این سناریو هدف، ساخت آرشیو محدود و پایدارتر از Ring Buffer است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'Capture_Deadlocks_File')
DROP EVENT SESSION [Capture_Deadlocks_File] ON SERVER;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
CREATE EVENT SESSION [Capture_Deadlocks_File] ON SERVER
ADD EVENT sqlserver.xml_deadlock_report
ADD TARGET package0.event_file
(
SET filename = N'C:\XE\Deadlocks.xel',
max_file_size = 100,
max_rollover_files = 5
)
WITH (STARTUP_STATE = ON);
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
| خروجی نمونه | تفسیر |
|---|
| حداکثر پنج فایل صد مگابایتی با Rollover تعریف میشود | نتیجه نمایشی مثال 5؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
مسیر باید از دید سرویس SQL Server موجود و قابل نوشتن باشد؛ مسیر Client SSMS ملاک نیست. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 6: خواندن فایلهای Deadlock
در این سناریو هدف، خواندن همه Rollover Fileها با Wildcard کنترلشده است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
object_name,
file_name,
file_offset,
CAST(event_data AS xml) AS event_xml
FROM sys.fn_xe_file_target_read_file
(
N'C:\XE\Deadlocks*.xel',
NULL,
NULL,
NULL
)
WHERE object_name = N'xml_deadlock_report';
| خروجی نمونه | تفسیر |
|---|
| xml_deadlock_report | C:XEDeadlocks_0_*.xel | offset | <event ...> | نتیجه نمایشی مثال 6؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
تابع فایل را روی SQL Server اجرا میکند؛ دسترسی فایل و مسیر باید برای Host سرور معتبر باشد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 7: استخراج Victim از Payload Event
در این سناریو هدف، عبور از Envelope رویداد و رسیدن به Victim List است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
;WITH xe AS
(
SELECT CAST(event_data AS xml) AS event_xml
FROM sys.fn_xe_file_target_read_file(N'C:\XE\Deadlocks*.xel', NULL, NULL, NULL)
WHERE object_name = N'xml_deadlock_report'
), d AS
(
SELECT event_xml.query('(event/data[@name="xml_report"]/value/deadlock)[1]') AS deadlock_xml
FROM xe
)
SELECT
v.n.value('@id', 'nvarchar(100)') AS victim_process_id
FROM d
CROSS APPLY deadlock_xml.nodes('/deadlock/victim-list/victimProcess') AS v(n);
| خروجی نمونه | تفسیر |
|---|
| process2f72c1088 | نتیجه نمایشی مثال 7؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
برای رسیدن به SPID، victim_process_id را با @id در process-list همان Deadlock مرتبط کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 8: افزودن Actionهای تشخیصی
در این سناریو هدف، غنیسازی رخداد برای نسبت دادن آن به سرویس مالک است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'Capture_Deadlocks_Actions')
DROP EVENT SESSION [Capture_Deadlocks_Actions] ON SERVER;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
CREATE EVENT SESSION [Capture_Deadlocks_Actions] ON SERVER
ADD EVENT sqlserver.xml_deadlock_report
(
ACTION
(
sqlserver.client_app_name,
sqlserver.client_hostname,
sqlserver.database_name,
sqlserver.session_id
)
)
ADD TARGET package0.ring_buffer;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
| خروجی نمونه | تفسیر |
|---|
| Event همراه App، Host، Database و Session Action تعریف میشود | نتیجه نمایشی مثال 8؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
هر Action هزینه و حجم دارد؛ فقط فیلدهایی را بگیرید که Runbook واقعاً مصرف میکند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 9: کنترل تنظیمات Retention و Startup
در این سناریو هدف، ممیزی گزینههای عملیاتی Session پس از Deployment است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
name,
event_retention_mode_desc,
max_memory,
max_dispatch_latency,
startup_state
FROM sys.server_event_sessions
WHERE name LIKE N'Capture_Deadlocks%';
| خروجی نمونه | تفسیر |
|---|
| Capture_Deadlocks_File | ALLOW_SINGLE_EVENT_LOSS | 4096 | 30 | 1 | نتیجه نمایشی مثال 9؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Retention Mode بدون مانیتور Disk و Dropped Event تضمین از دست نرفتن شواهد نیست. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 10: توقف و پاکسازی Session آزمایشی
در این سناریو هدف، پاکسازی Idempotent منابع Lab پس از پایان تمرین است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
IF EXISTS (SELECT 1 FROM sys.dm_xe_sessions WHERE name = N'Capture_Deadlocks')
ALTER EVENT SESSION [Capture_Deadlocks] ON SERVER STATE = STOP;
IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'Capture_Deadlocks')
DROP EVENT SESSION [Capture_Deadlocks] ON SERVER;
| خروجی نمونه | تفسیر |
|---|
| Session آزمایشی در صورت وجود متوقف و حذف میشود | نتیجه نمایشی مثال 10؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
در Production حذف Session شواهد و پوشش مانیتورینگ را از بین میبرد؛ Change رسمی لازم است. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
سؤالات متداول
پرسش 1: xml_deadlock_report Extended Event دقیقاً چه مسئلهای را در SQL Server حل میکند؟
رویداد sqlserver.xml_deadlock_report متن کامل Deadlock XML را در Extended Events ثبت میکند و روش استاندارد برای آرشیو و تحلیل Deadlockهای SQL Server است. ارزش اصلی آن زمانی آشکار میشود که سؤال عملیاتی مشخص باشد؛ مثلاً شناسایی Head Blocker، تعیین منبع انتظار یا حفظ شواهد Deadlock. خروجی باید کنار زمان رخداد و مشخصات Application نگهداری شود تا از یک Snapshot خام به پاسخ قابل اقدام برسیم.
پرسش 2: برای شروع کار با xml_deadlock_report Extended Event چه پیشنیازی لازم است؟
ابتدا در محیط آزمایش Syntax و ستونهای نسخه نصبشده را بررسی کنید، سپس مجوز حداقلی مشاهده وضعیت را در نظر بگیرید. ایجاد و مدیریت Session به ALTER ANY EVENT SESSION یا مجوز متناظر نسخه نیاز دارد. اجرای Query با حساب Production پرقدرت راهحل مناسبی نیست و بهتر است نقش مانیتورینگ مشخص و ممیزیشده ساخته شود.
پرسش 3: استفاده از xml_deadlock_report Extended Event چه ارزش تجاری برای سامانه پرتراکنش دارد؟
کاهش زمان تشخیص Incident، جلوگیری از تصمیم عجولانه و کوتاهشدن اختلال مستقیمترین ارزشها هستند. وقتی داده این ابزار با SLA و مالک سرویس پیوند بخورد، تیم میتواند بین کندی عادی، Blocking زیانآور و Deadlock تکرارشونده تفاوت بگذارد و هزینه توقف را کم کند.
پرسش 4: چه زمانی برای پیادهسازی مانیتورینگ xml_deadlock_report Extended Event به مشاوره تخصصی نیاز داریم؟
اگر رخدادها تکراری، چندپایگاهدادهای، حساس به امنیت یا دارای حجم Event بالا هستند، طراحی Baseline، Retention و Runbook تخصصی مفید است. مشاوره SQL Server باید در کنار جمعآوری داده، Query Plan، تراکنش، ایندکس و رفتار کد Application را نیز بررسی کند؛ خرید ابزار بدون فرایند پاسخگویی کافی نیست.
پرسش 5: تفاوت xml_deadlock_report Extended Event با ابزار نزدیک آن چیست؟
system_health همین Event را بهصورت پیشفرض میگیرد، ولی Session اختصاصی Retention، مسیر فایل و چرخه عملیاتی قابل کنترلتری میدهد. انتخاب درست به این بستگی دارد که داده لحظهای، تاریخچه XML، مشخصات Session یا امکان اقدام مدیریتی لازم باشد. در عیبیابی حرفهای معمولاً چند منبع مکمل کنار هم استفاده میشوند، نه اینکه یک خروجی به تنهایی حقیقت کامل فرض شود.
پرسش 6: آیا میتوان پیادهسازی داشبورد یا پروژه xml_deadlock_report Extended Event را به تیم متخصص سپرد؟
بله؛ تحویل حرفهای باید شامل تعریف نیاز، Queryهای کمهزینه، کنترل مجوز، ذخیره UTC، سیاست Retention، هشدار قابل تنظیم، داشبورد و Runbook اعتبارسنجیشده باشد. پیش از پذیرش پروژه، اثر مانیتورینگ روی Production و روش تست خطا نیز باید مستند شود.
پرسش 7: رایجترین خطا هنگام تحلیل xml_deadlock_report Extended Event چیست؟
حذف Session یا فایل پیش از انتقال شواهد، تاریخچه رخداد را از بین میبرد؛ چرخه نگهداری و دسترسی را مستند کنید. خطای دوم تصمیمگیری از روی یک Snapshot بدون Baseline است. زمان رخداد، Login، Host، Database، Transaction و Query متناظر را کنار هم قرار دهید و هر مقدار NULL یا نامشخص را صادقانه حفظ کنید.
پرسش 8: آیا Query گرفتن از xml_deadlock_report Extended Event روی Performance اثر میگذارد؟
Event کمحجم است، اما Ring Buffer محدود و Event File نیازمند سقف اندازه و تعداد Rollover مشخص است. خود مشاهده نیز رایگان نیست، بهویژه وقتی XML، Plan یا Text برای تعداد زیادی Session استخراج شود. Period نمونهبرداری، فیلتر، سقف نگهداری و مانیتور Dropped Event باید بخشی از طراحی باشد.
پرسش 9: بهترین روش استفاده Production از xml_deadlock_report Extended Event چیست؟
پرسش عملیاتی را از قبل تعریف کنید، کمترین ستون و Scope لازم را جمع کنید، Timestamp UTC و شناسه Incident بسازید و اقدام مخرب را از جمعآوری شواهد جدا نگه دارید. Runbook باید مرحله تأیید هویت Session، اثر Rollback، تماس با مالک سرویس و معیار پایان Incident را روشن کند.
پرسش 10: xml_deadlock_report Extended Event در کدام نسخههای SQL Server قابل استفاده است؟
جزئیات ستون، مجوز و Eventها با نسخه و Azure SQL تفاوت دارد؛ بنابراین metadata و مستندات همان نسخه باید مرجع نهایی باشد. ایجاد و مدیریت Session به ALTER ANY EVENT SESSION یا مجوز متناظر نسخه نیاز دارد. در ارتقا، Queryها را روی محیط Stage اجرا کنید و بهویژه قابلیتهای Undocumented یا Deprecated را با جایگزین مستند عوض کنید.