مثالهای عملی
مثال 1: تأیید فعال بودن Threshold
در این سناریو هدف، بررسی پیششرط اصلی Event پیش از عیبیابی Collector است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT value_in_use AS blocked_threshold_seconds
FROM sys.configurations
WHERE name = N'blocked process threshold (s)';
| خروجی نمونه | تفسیر |
|---|
| 5 | نتیجه نمایشی مثال 1؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
مقدار صفر یعنی حتی Session Started نیز blocked_process_report دریافت نمیکند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 2: ساخت Session پایه blocked_process_report
در این سناریو هدف، ساخت Collector اختصاصی قابل مدیریت است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'Capture_Blocking_XE')
DROP EVENT SESSION [Capture_Blocking_XE] ON SERVER;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
CREATE EVENT SESSION [Capture_Blocking_XE] ON SERVER
ADD EVENT sqlserver.blocked_process_report
ADD TARGET package0.ring_buffer(SET max_memory = 4096)
WITH (STARTUP_STATE = ON);
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
| خروجی نمونه | تفسیر |
|---|
| Capture_Blocking_XE با Event و Target تعریف میشود | نتیجه نمایشی مثال 2؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
در Production پیش از DROP شواهد Target قبلی را نگه دارید و تغییر را بدون شکاف پوشش انجام دهید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 3: شروع و کنترل Session
در این سناریو هدف، اثبات وضعیت تعریف، Runtime و Startup در یک Query است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
ALTER EVENT SESSION [Capture_Blocking_XE] ON SERVER STATE = START;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
SELECT
ses.name,
CASE WHEN run.name IS NULL THEN N'STOPPED' ELSE N'STARTED' END AS runtime_state,
ses.startup_state
FROM sys.server_event_sessions AS ses
LEFT JOIN sys.dm_xe_sessions AS run ON run.name = ses.name
WHERE ses.name = N'Capture_Blocking_XE';
| خروجی نمونه | تفسیر |
|---|
| Capture_Blocking_XE | STARTED | 1 | نتیجه نمایشی مثال 3؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
سه شرط Event، Target و threshold غیرصفر باید همزمان برقرار باشند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 4: خواندن Event XML از Ring Buffer
در این سناریو هدف، نمایش هر Event بهصورت یک ردیف و حفظ Envelope کامل است. 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_Blocking_XE'
AND t.target_name = N'ring_buffer'
)
SELECT
e.n.value('@timestamp', 'datetime2') AS event_utc,
e.n.query('.') AS event_xml
FROM rb
CROSS APPLY target_xml.nodes('/RingBufferTarget/event[@name="blocked_process_report"]') AS e(n)
ORDER BY event_utc DESC;
| خروجی نمونه | تفسیر |
|---|
| 2026-07-22 03:31:04 | <event name="blocked_process_report" ...> | نتیجه نمایشی مثال 4؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Timestamp UTC را در ذخیرهسازی تغییر ندهید؛ نمایش محلی را در لایه گزارش انجام دهید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 5: استخراج Blocked و Blocker از Payload
در این سناریو هدف، ساخت Dataset ساختیافته برای هشدار و Dashboard است. 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_Blocking_XE' AND t.target_name = N'ring_buffer'
), events AS
(
SELECT e.n.query('.') AS event_xml
FROM rb CROSS APPLY target_xml.nodes('/RingBufferTarget/event[@name="blocked_process_report"]') AS e(n)
)
SELECT
event_xml.value('(event/data/value/blocked-process-report/blocked-process/process/@spid)[1]', 'int') AS blocked_spid,
event_xml.value('(event/data/value/blocked-process-report/blocking-process/process/@spid)[1]', 'int') AS blocker_spid,
event_xml.value('(event/data/value/blocked-process-report/blocked-process/process/@waitresource)[1]', 'nvarchar(256)') AS wait_resource
FROM events;
| خروجی نمونه | تفسیر |
|---|
| 64 | 57 | KEY: 7:7205... | نتیجه نمایشی مثال 5؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
مسیر Payload را با XML واقعی نسخه خود Validate کنید و در برابر مقدار تهی مقاوم بمانید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 6: افزودن Actionهای Client
در این سناریو هدف، کمک به مسیریابی رخداد برای تیم مالک Application است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'Capture_Blocking_Actions')
DROP EVENT SESSION [Capture_Blocking_Actions] ON SERVER;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
CREATE EVENT SESSION [Capture_Blocking_Actions] ON SERVER
ADD EVENT sqlserver.blocked_process_report
(
ACTION
(
sqlserver.client_app_name,
sqlserver.client_hostname,
sqlserver.database_name,
sqlserver.session_id
)
)
ADD TARGET package0.ring_buffer;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
| خروجی نمونه | تفسیر |
|---|
| Actionهای App، Host، Database و Session به Event افزوده میشوند | نتیجه نمایشی مثال 6؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
اطلاعات Client قابل جعل است؛ برای Audit از Login و Telemetry برنامه نیز استفاده کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 7: ساخت Event File محدود
در این سناریو هدف، فراهم کردن آرشیو دیسکی با سقف روشن است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'Capture_Blocking_File')
DROP EVENT SESSION [Capture_Blocking_File] ON SERVER;
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
CREATE EVENT SESSION [Capture_Blocking_File] ON SERVER
ADD EVENT sqlserver.blocked_process_report
ADD TARGET package0.event_file
(
SET filename = N'C:\XE\Blocking.xel',
max_file_size = 100,
max_rollover_files = 5
)
WITH (STARTUP_STATE = ON);
-- مرز Batch اختیاری است؛ در اجرای جداگانه میتوان از GO استفاده کرد.
| خروجی نمونه | تفسیر |
|---|
| پنج فایل حداکثر صد مگابایتی تعریف میشود | نتیجه نمایشی مثال 7؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
فضای Volume، ACL سرویس و فرآیند انتقال به مخزن مرکزی باید مانیتور شود. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 8: خواندن آرشیو Event File
در این سناریو هدف، خواندن تاریخچه Rollover Fileها برای تحلیل پس از رخداد است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
timestamp_utc,
object_name,
file_name,
CAST(event_data AS xml) AS event_xml
FROM sys.fn_xe_file_target_read_file
(
N'C:\XE\Blocking*.xel',
NULL,
NULL,
NULL
)
WHERE object_name = N'blocked_process_report'
ORDER BY timestamp_utc DESC;
| خروجی نمونه | تفسیر |
|---|
| 2026-07-22 03:31:04 | blocked_process_report | C:XEBlocking_0_*.xel | <event ...> | نتیجه نمایشی مثال 8؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Wildcard را محدود نگه دارید؛ خواندن فایلهای بسیار زیاد در هر Refresh هزینه I/O دارد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 9: ممیزی Drop و مصرف Target
در این سناریو هدف، مشاهده metadata Runtime برای ظرفیت و رخدادهای Target است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
s.name,
t.target_name,
CAST(t.target_data AS xml) AS target_data
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'Capture_Blocking_XE';
| خروجی نمونه | تفسیر |
|---|
| Capture_Blocking_XE | ring_buffer | <RingBufferTarget ... eventCount="28" ...> | نتیجه نمایشی مثال 9؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
ویژگیهای Target در نسخهها فرق میکند؛ Drop Count و Memory را از XML همان نسخه استخراج کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 10: Deployment Check یکپارچه
در این سناریو هدف، کنترل چهار پیششرط اصلی در یک Health Check قابل خودکارسازی است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
cfg.value_in_use AS threshold_seconds,
ses.startup_state,
CASE WHEN run.name IS NULL THEN 0 ELSE 1 END AS is_started,
CASE WHEN ev.event_session_id IS NULL THEN 0 ELSE 1 END AS has_blocked_event
FROM sys.configurations AS cfg
LEFT JOIN sys.server_event_sessions AS ses ON ses.name = N'Capture_Blocking_XE'
LEFT JOIN sys.dm_xe_sessions AS run ON run.name = ses.name
LEFT JOIN sys.server_event_session_events AS ev
ON ev.event_session_id = ses.event_session_id
AND ev.name = N'blocked_process_report'
WHERE cfg.name = N'blocked process threshold (s)';
| خروجی نمونه | تفسیر |
|---|
| 5 | 1 | 1 | 1 | نتیجه نمایشی مثال 10؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
به این Query کنترل Target و مسیر فایل را نیز متناسب با استاندارد سازمان اضافه کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
سؤالات متداول
پرسش 1: blocked_process_report Extended Event دقیقاً چه مسئلهای را در SQL Server حل میکند؟
رویداد sqlserver.blocked_process_report گزارش XML Blocking طولانیتر از آستانه سرور را در یک Session سبک Extended Events دریافت میکند. ارزش اصلی آن زمانی آشکار میشود که سؤال عملیاتی مشخص باشد؛ مثلاً شناسایی Head Blocker، تعیین منبع انتظار یا حفظ شواهد Deadlock. خروجی باید کنار زمان رخداد و مشخصات Application نگهداری شود تا از یک Snapshot خام به پاسخ قابل اقدام برسیم.
پرسش 2: برای شروع کار با blocked_process_report Extended Event چه پیشنیازی لازم است؟
ابتدا در محیط آزمایش Syntax و ستونهای نسخه نصبشده را بررسی کنید، سپس مجوز حداقلی مشاهده وضعیت را در نظر بگیرید. تنظیم blocked process threshold و ایجاد Session XE به مجوزهای مدیریتی مربوط نیاز دارد. اجرای Query با حساب Production پرقدرت راهحل مناسبی نیست و بهتر است نقش مانیتورینگ مشخص و ممیزیشده ساخته شود.
پرسش 3: استفاده از blocked_process_report Extended Event چه ارزش تجاری برای سامانه پرتراکنش دارد؟
کاهش زمان تشخیص Incident، جلوگیری از تصمیم عجولانه و کوتاهشدن اختلال مستقیمترین ارزشها هستند. وقتی داده این ابزار با SLA و مالک سرویس پیوند بخورد، تیم میتواند بین کندی عادی، Blocking زیانآور و Deadlock تکرارشونده تفاوت بگذارد و هزینه توقف را کم کند.
پرسش 4: چه زمانی برای پیادهسازی مانیتورینگ blocked_process_report Extended Event به مشاوره تخصصی نیاز داریم؟
اگر رخدادها تکراری، چندپایگاهدادهای، حساس به امنیت یا دارای حجم Event بالا هستند، طراحی Baseline، Retention و Runbook تخصصی مفید است. مشاوره SQL Server باید در کنار جمعآوری داده، Query Plan، تراکنش، ایندکس و رفتار کد Application را نیز بررسی کند؛ خرید ابزار بدون فرایند پاسخگویی کافی نیست.
پرسش 5: تفاوت blocked_process_report Extended Event با ابزار نزدیک آن چیست؟
Event با همین نام حامل گزارش است، درحالیکه Blocked Process Report خود ساختار XML و معنای تشخیصی داده را توصیف میکند. انتخاب درست به این بستگی دارد که داده لحظهای، تاریخچه XML، مشخصات Session یا امکان اقدام مدیریتی لازم باشد. در عیبیابی حرفهای معمولاً چند منبع مکمل کنار هم استفاده میشوند، نه اینکه یک خروجی به تنهایی حقیقت کامل فرض شود.
پرسش 6: آیا میتوان پیادهسازی داشبورد یا پروژه blocked_process_report Extended Event را به تیم متخصص سپرد؟
بله؛ تحویل حرفهای باید شامل تعریف نیاز، Queryهای کمهزینه، کنترل مجوز، ذخیره UTC، سیاست Retention، هشدار قابل تنظیم، داشبورد و Runbook اعتبارسنجیشده باشد. پیش از پذیرش پروژه، اثر مانیتورینگ روی Production و روش تست خطا نیز باید مستند شود.
پرسش 7: رایجترین خطا هنگام تحلیل blocked_process_report Extended Event چیست؟
اگر threshold صفر باشد، Session سالم و Started نیز هیچ رخدادی دریافت نمیکند؛ هر دو تنظیم را همزمان پایش کنید. خطای دوم تصمیمگیری از روی یک Snapshot بدون Baseline است. زمان رخداد، Login، Host، Database، Transaction و Query متناظر را کنار هم قرار دهید و هر مقدار NULL یا نامشخص را صادقانه حفظ کنید.
پرسش 8: آیا Query گرفتن از blocked_process_report Extended Event روی Performance اثر میگذارد؟
Threshold، مقصد Event File، max_file_size و max_rollover_files را طوری تنظیم کنید که حجم تکرار گزارش کنترل شود. خود مشاهده نیز رایگان نیست، بهویژه وقتی XML، Plan یا Text برای تعداد زیادی Session استخراج شود. Period نمونهبرداری، فیلتر، سقف نگهداری و مانیتور Dropped Event باید بخشی از طراحی باشد.
پرسش 9: بهترین روش استفاده Production از blocked_process_report Extended Event چیست؟
پرسش عملیاتی را از قبل تعریف کنید، کمترین ستون و Scope لازم را جمع کنید، Timestamp UTC و شناسه Incident بسازید و اقدام مخرب را از جمعآوری شواهد جدا نگه دارید. Runbook باید مرحله تأیید هویت Session، اثر Rollback، تماس با مالک سرویس و معیار پایان Incident را روشن کند.
پرسش 10: blocked_process_report Extended Event در کدام نسخههای SQL Server قابل استفاده است؟
جزئیات ستون، مجوز و Eventها با نسخه و Azure SQL تفاوت دارد؛ بنابراین metadata و مستندات همان نسخه باید مرجع نهایی باشد. تنظیم blocked process threshold و ایجاد Session XE به مجوزهای مدیریتی مربوط نیاز دارد. در ارتقا، Queryها را روی محیط Stage اجرا کنید و بهویژه قابلیتهای Undocumented یا Deprecated را با جایگزین مستند عوض کنید.