مثالهای عملی
مثال 1: کنترل تعریف و Startup State
در این سناریو هدف، دیدن تنظیمات ثبتشده Session پیشفرض است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
name,
event_retention_mode_desc,
max_memory,
startup_state
FROM sys.server_event_sessions
WHERE name = N'system_health';
| خروجی نمونه | تفسیر |
|---|
| system_health | ALLOW_SINGLE_EVENT_LOSS | 4096 | 1 | نتیجه نمایشی مثال 1؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
تنظیمات ممکن است بین نسخهها فرق کند؛ system_health را تغییر ندهید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 2: کنترل Started بودن system_health
در این سناریو هدف، بررسی Runtime و Dropped Event Session است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
name,
create_time,
total_buffer_size,
dropped_event_count
FROM sys.dm_xe_sessions
WHERE name = N'system_health';
| خروجی نمونه | تفسیر |
|---|
| system_health | 2026-07-20 10:00 | 4227072 | 0 | نتیجه نمایشی مثال 2؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
نبود ردیف غیرعادی است؛ علت توقف را بررسی کنید و بدون Change کنترلشده Session داخلی را دستکاری نکنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 3: فهرست Eventهای تعریفشده
در این سناریو هدف، شناخت پوشش واقعی system_health در نسخه نصبشده است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
e.name AS event_name,
e.predicate
FROM sys.server_event_sessions AS s
JOIN sys.server_event_session_events AS e
ON e.event_session_id = s.event_session_id
WHERE s.name = N'system_health'
ORDER BY e.name;
| خروجی نمونه | تفسیر |
|---|
| xml_deadlock_report | NULL | نتیجه نمایشی مثال 3؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
به فهرست حفظشده از نسخه دیگر تکیه نکنید؛ metadata سرور مقصد مرجع است. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 4: خواندن Ring Buffer خام
در این سناریو هدف، مشاهده همه Eventهای موجود در حافظه با Timestamp است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
;WITH sh 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'system_health'
AND t.target_name = N'ring_buffer'
)
SELECT
e.n.value('@name', 'sysname') AS event_name,
e.n.value('@timestamp', 'datetime2') AS event_utc,
e.n.query('.') AS event_xml
FROM sh
CROSS APPLY target_xml.nodes('/RingBufferTarget/event') AS e(n)
ORDER BY event_utc DESC;
| خروجی نمونه | تفسیر |
|---|
| xml_deadlock_report | 2026-07-22 03:31:04 | <event ...> | نتیجه نمایشی مثال 4؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Ring Buffer محدود است؛ Query را روی Event مورد نیاز فیلتر کنید و خروجی عظیم را مرتب Refresh نکنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 5: استخراج Deadlockهای اخیر
در این سناریو هدف، استفاده فوری از Collector پیشفرض برای Deadlock است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
;WITH sh 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'system_health' 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 sh
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> | نتیجه نمایشی مثال 5؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
برای نگهداری طولانی Session اختصاصی Event File بسازید و system_health را بهعنوان منبع پشتیبان حفظ کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 6: دیدن Targetهای Runtime
در این سناریو هدف، شناخت Ring Buffer و Event File فعال در نسخه جاری است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
s.name,
t.target_name,
t.execution_count,
t.execution_duration_ms
FROM sys.dm_xe_sessions AS s
JOIN sys.dm_xe_session_targets AS t
ON t.event_session_address = s.address
WHERE s.name = N'system_health';
| خروجی نمونه | تفسیر |
|---|
| system_health | event_file | 128 | 42 | نتیجه نمایشی مثال 6؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
وجود Target ثبتشده را از Runtime بررسی کنید؛ مسیر و ویژگیها ممکن است با نسخه عوض شوند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 7: گرفتن مسیر Event File از Target Data
در این سناریو هدف، کشف مسیر واقعی به جای حدس زدن Instance Directory است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
CAST(t.target_data AS xml).value('(EventFileTarget/File/@name)[1]', 'nvarchar(4000)') AS current_file_name
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'system_health'
AND t.target_name = N'event_file';
| خروجی نمونه | تفسیر |
|---|
| C:Program FilesMicrosoft SQL Server...system_health_0_*.xel | نتیجه نمایشی مثال 7؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
مسیر از دید Host و Service SQL Server است؛ آن را در پاسخ عمومی یا Log ناامن افشا نکنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 8: خواندن فایل با مسیر کشفشده
در این سناریو هدف، استفاده از مسیر metadata برای خواندن فایل جاری است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
DECLARE @FileName nvarchar(4000);
SELECT @FileName = CAST(t.target_data AS xml).value('(EventFileTarget/File/@name)[1]', 'nvarchar(4000)')
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'system_health'
AND t.target_name = N'event_file';
SELECT TOP (100)
timestamp_utc,
object_name,
CAST(event_data AS xml) AS event_xml
FROM sys.fn_xe_file_target_read_file(@FileName, NULL, NULL, NULL)
ORDER BY timestamp_utc DESC;
| خروجی نمونه | تفسیر |
|---|
| آخرین ۱۰۰ Event فایل system_health برمیگردد | نتیجه نمایشی مثال 8؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
فایلهای Rollover قدیمی ممکن است با یک نام دقیق پوشش داده نشوند؛ الگوی Wildcard را کنترلشده بسازید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 9: فیلتر خطاهای شدید از Ring Buffer
در این سناریو هدف، استخراج ساختیافته Errorهای ثبتشده در نسخه دارای این Event است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
;WITH sh 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'system_health' AND t.target_name = N'ring_buffer'
)
SELECT
e.n.value('@timestamp', 'datetime2') AS event_utc,
e.n.value('(data[@name="error_number"]/value)[1]', 'int') AS error_number,
e.n.value('(data[@name="severity"]/value)[1]', 'int') AS severity,
e.n.value('(data[@name="message"]/value)[1]', 'nvarchar(4000)') AS message
FROM sh
CROSS APPLY target_xml.nodes('/RingBufferTarget/event[@name="error_reported"]') AS e(n)
ORDER BY event_utc DESC;
| خروجی نمونه | تفسیر |
|---|
| 2026-07-22 03:25 | 824 | 24 | SQL Server detected a logical consistency... | نتیجه نمایشی مثال 9؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Predicate system_health تعیین میکند چه Errorهایی حاضرند؛ این خروجی جای SQL Error Log و Alert را نمیگیرد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 10: طراحی Collector اختصاصی بدون تغییر system_health
در این سناریو هدف، گسترش Retention با Session خودمان و حفظ Session داخلی است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
IF NOT EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'Ops_Deadlocks')
BEGIN
CREATE EVENT SESSION [Ops_Deadlocks] ON SERVER
ADD EVENT sqlserver.xml_deadlock_report
ADD TARGET package0.event_file
(
SET filename = N'C:\XE\Ops_Deadlocks.xel',
max_file_size = 100,
max_rollover_files = 5
)
WITH (STARTUP_STATE = ON);
END;
| خروجی نمونه | تفسیر |
|---|
| Ops_Deadlocks فقط در صورت نبودن ایجاد میشود | نتیجه نمایشی مثال 10؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
مسیر، مجوز، فضای Disk و Startup را پیش از اجرا در Change سازمانی اعتبارسنجی کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
سؤالات متداول
پرسش 1: system_health Extended Events Session دقیقاً چه مسئلهای را در SQL Server حل میکند؟
system_health یک Extended Events Session داخلی و پیشفرض است که شواهد مهمی مانند Deadlock، خطاهای شدید، مشکلات Scheduler و فشار حافظه را با هزینه کم جمع میکند. ارزش اصلی آن زمانی آشکار میشود که سؤال عملیاتی مشخص باشد؛ مثلاً شناسایی Head Blocker، تعیین منبع انتظار یا حفظ شواهد Deadlock. خروجی باید کنار زمان رخداد و مشخصات Application نگهداری شود تا از یک Snapshot خام به پاسخ قابل اقدام برسیم.
پرسش 2: برای شروع کار با system_health Extended Events Session چه پیشنیازی لازم است؟
ابتدا در محیط آزمایش Syntax و ستونهای نسخه نصبشده را بررسی کنید، سپس مجوز حداقلی مشاهده وضعیت را در نظر بگیرید. خواندن metadata و targetها به مجوز مشاهده وضعیت سرور یا مجوزهای جدید XE نیاز دارد. اجرای Query با حساب Production پرقدرت راهحل مناسبی نیست و بهتر است نقش مانیتورینگ مشخص و ممیزیشده ساخته شود.
پرسش 3: استفاده از system_health Extended Events Session چه ارزش تجاری برای سامانه پرتراکنش دارد؟
کاهش زمان تشخیص Incident، جلوگیری از تصمیم عجولانه و کوتاهشدن اختلال مستقیمترین ارزشها هستند. وقتی داده این ابزار با SLA و مالک سرویس پیوند بخورد، تیم میتواند بین کندی عادی، Blocking زیانآور و Deadlock تکرارشونده تفاوت بگذارد و هزینه توقف را کم کند.
پرسش 4: چه زمانی برای پیادهسازی مانیتورینگ system_health Extended Events Session به مشاوره تخصصی نیاز داریم؟
اگر رخدادها تکراری، چندپایگاهدادهای، حساس به امنیت یا دارای حجم Event بالا هستند، طراحی Baseline، Retention و Runbook تخصصی مفید است. مشاوره SQL Server باید در کنار جمعآوری داده، Query Plan، تراکنش، ایندکس و رفتار کد Application را نیز بررسی کند؛ خرید ابزار بدون فرایند پاسخگویی کافی نیست.
پرسش 5: تفاوت system_health Extended Events Session با ابزار نزدیک آن چیست؟
system_health نقطه شروع فوری است، اما برای SLA و نگهداری بلندمدت جای Session اختصاصی با سیاست Retention را نمیگیرد. انتخاب درست به این بستگی دارد که داده لحظهای، تاریخچه XML، مشخصات Session یا امکان اقدام مدیریتی لازم باشد. در عیبیابی حرفهای معمولاً چند منبع مکمل کنار هم استفاده میشوند، نه اینکه یک خروجی به تنهایی حقیقت کامل فرض شود.
پرسش 6: آیا میتوان پیادهسازی داشبورد یا پروژه system_health Extended Events Session را به تیم متخصص سپرد؟
بله؛ تحویل حرفهای باید شامل تعریف نیاز، Queryهای کمهزینه، کنترل مجوز، ذخیره UTC، سیاست Retention، هشدار قابل تنظیم، داشبورد و Runbook اعتبارسنجیشده باشد. پیش از پذیرش پروژه، اثر مانیتورینگ روی Production و روش تست خطا نیز باید مستند شود.
پرسش 7: رایجترین خطا هنگام تحلیل system_health Extended Events Session چیست؟
Ring Buffer و فایلها دائمی نیستند و با Restart یا Rollover داده قدیمی حذف میشود؛ شواهد لازم را به مخزن جدا منتقل کنید. خطای دوم تصمیمگیری از روی یک Snapshot بدون Baseline است. زمان رخداد، Login، Host، Database، Transaction و Query متناظر را کنار هم قرار دهید و هر مقدار NULL یا نامشخص را صادقانه حفظ کنید.
پرسش 8: آیا Query گرفتن از system_health Extended Events Session روی Performance اثر میگذارد؟
Session را دستکاری یا متوقف نکنید؛ Query خواندن را به Eventهای هدف و بازه زمانی لازم محدود کنید. خود مشاهده نیز رایگان نیست، بهویژه وقتی XML، Plan یا Text برای تعداد زیادی Session استخراج شود. Period نمونهبرداری، فیلتر، سقف نگهداری و مانیتور Dropped Event باید بخشی از طراحی باشد.
پرسش 9: بهترین روش استفاده Production از system_health Extended Events Session چیست؟
پرسش عملیاتی را از قبل تعریف کنید، کمترین ستون و Scope لازم را جمع کنید، Timestamp UTC و شناسه Incident بسازید و اقدام مخرب را از جمعآوری شواهد جدا نگه دارید. Runbook باید مرحله تأیید هویت Session، اثر Rollback، تماس با مالک سرویس و معیار پایان Incident را روشن کند.
پرسش 10: system_health Extended Events Session در کدام نسخههای SQL Server قابل استفاده است؟
جزئیات ستون، مجوز و Eventها با نسخه و Azure SQL تفاوت دارد؛ بنابراین metadata و مستندات همان نسخه باید مرجع نهایی باشد. خواندن metadata و targetها به مجوز مشاهده وضعیت سرور یا مجوزهای جدید XE نیاز دارد. در ارتقا، Queryها را روی محیط Stage اجرا کنید و بهویژه قابلیتهای Undocumented یا Deprecated را با جایگزین مستند عوض کنید.