آموزش Blocked Process Report در SQL Server؛ تحلیل گزارش فرایند مسدودشده

مقدمه

Blocked Process Report یک سند XML است که پس از عبور Blocking از آستانه تنظیم‌شده تولید می‌شود و اطلاعات Blocked، Blocker، منبع انتظار و Input Buffer را ثبت می‌کند. در عیب‌یابی Blocking و Deadlock، ارزش داده زمانی بیشتر می‌شود که آن را با یک Timeline دقیق، مشخصات Client و وضعیت Transaction مرتبط کنیم. این مقاله از خواندن پایه شروع می‌کند و تا الگوهای امن Production، خطاهای رایج و ملاحظات کارایی پیش می‌رود.

برای دیدن جایگاه این ابزار در کل فرایند، راهنمای جامع پایش Blocking و Deadlock در SQL Server را نیز مطالعه کنید. لینک‌ها Root-relative هستند و مقاله حاضر مستقل از دامنه قابل انتشار است.

دسترسی سریع

تعریف، Syntax و مجوزهای مورد نیاز
پارامترها، ستون‌ها و نوع خروجی
ده مثال مستقل از مقدماتی تا Production
خطاهای رایج، Performance و Best Practice
ده پرسش متداول، سؤالات مصاحبه و چک‌لیست

تعریف Blocked Process Report و جایگاه آن

Blocked Process Report یک سند XML است که پس از عبور Blocking از آستانه تنظیم‌شده تولید می‌شود و اطلاعات Blocked، Blocker، منبع انتظار و Input Buffer را ثبت می‌کند. این داده نباید به شکل جدا از Context تفسیر شود؛ Session ID تنها یک شناسه موقت است و بدون Login، Host، زمان اتصال، Database و متن فرمان می‌تواند تحلیل را منحرف کند.

برخلاف Snapshot لحظه‌ای DMV، گزارش پس از گذشت آستانه ساخته می‌شود و شواهد تاریخی قابل نگهداری از دو سوی Blocking می‌دهد.

در فرایند حرفه‌ای، مرحله نخست مشاهده و ثبت شواهد است، مرحله دوم تعیین اثر بر SLA، و مرحله سوم انتخاب اصلاح پایدار. اقداماتی مانند KILL، تغییر Threshold یا ساخت Event Session باید از Queryهای فقط‌خواندنی جدا و تحت Change یا Incident ثبت شوند.

Syntax

قالب پایه زیر نقطه شروع است. نام ستون‌ها یا گزینه‌ها را مطابق نسخه مقصد و مجوز حساب مانیتورینگ کنترل کنید.

EXEC sys.sp_configure N'blocked process threshold (s)', 5;
    RECONFIGURE;

پارامترها و اجزای ورودی

blocked process threshold (s): آستانه سطح سرور بر حسب ثانیه؛ صفر یعنی غیرفعال.
Blocked و Blocking Process دو شاخه اصلی XML هستند و هر کدام مشخصات Session و Input Buffer دارند.
Wait Resource، Lock Mode و Timestamp باید همراه Context پایگاه داده تحلیل شوند.

در تمام حالت‌ها از مقدار هدف صریح استفاده کنید و از حلقه‌ای که بدون فیلتر همه Sessionها، Planها یا XMLها را می‌خواند بپرهیزید. مقدارهای ورودی را پیش از ساخت SQL پویا اعتبارسنجی کنید.

نوع خروجی و ستون‌های مهم

رویداد XML که از Extended Events، Profiler قدیمی یا ابزار مانیتورینگ جمع‌آوری می‌شود. به همین دلیل خروجی باید همراه Timestamp ثبت شود و نتیجه قدیمی برای تصمیم مخرب دوباره اعتبارسنجی گردد.

ستون یا بخش	معنا و کاربرد
blocked-process	Session منتظر و Request آن
blocking-process	Session نگه‌دارنده منبع
waitresource / lockMode	منبع و Mode درخواستی
inputbuf	آخرین Batch دو سمت

مجوزها و ملاحظات امنیتی

تنظیم آستانه به مجوز سطح سرور و جمع‌آوری Extended Events به مجوزهای مربوط نیاز دارد. متن Batch، نام Login و Host می‌تواند داده حساس باشد؛ دسترسی به آرشیو مانیتورینگ را محدود، دوره نگهداری را مشخص و خروجی ارسالی به Ticket را پالایش کنید.

اصل Least Privilege یعنی حساب مشاهده‌گر به طور پیش‌فرض حق خاتمه Session، تغییر تنظیمات سرور یا حذف فایل Event را نداشته باشد. اختیار اقدام اضطراری باید جدا، زمان‌دار و ممیزی‌پذیر باشد.

مثال‌های عملی

مثال 1: مشاهده آستانه فعلی Blocking

در این سناریو هدف، بررسی وضعیت واقعی threshold پیش از هر تغییر است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

SELECT
        name,
        value,
        value_in_use,
        is_advanced
    FROM sys.configurations
    WHERE name = N'blocked process threshold (s)';

خروجی نمونه	تفسیر
blocked process threshold (s) \| 5 \| 5 \| 1	نتیجه نمایشی مثال 1؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

value_in_use مقدار مؤثر است؛ صفر یعنی تولید Blocked Process Report غیرفعال است. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

مثال 2: فعال‌سازی آستانه پنج ثانیه‌ای

در این سناریو هدف، تنظیم آستانه نمونه برای محیطی است که SLA کوتاه دارد. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

EXEC sys.sp_configure N'show advanced options', 1;
    RECONFIGURE;
    EXEC sys.sp_configure N'blocked process threshold (s)', 5;
    RECONFIGURE;
    
    SELECT value_in_use
    FROM sys.configurations
    WHERE name = N'blocked process threshold (s)';

خروجی نمونه	تفسیر
5	نتیجه نمایشی مثال 2؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

این تغییر سطح سرور است؛ مقدار را با تیم عملیات، نرخ تراکنش و حجم Event هماهنگ کنید. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

مثال 3: غیرفعال‌سازی کنترل‌شده گزارش

در این سناریو هدف، بازگرداندن تنظیم به حالت غیرفعال در محیط آزمایش است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

EXEC sys.sp_configure N'show advanced options', 1;
    RECONFIGURE;
    EXEC sys.sp_configure N'blocked process threshold (s)', 0;
    RECONFIGURE;

خروجی نمونه	تفسیر
Configuration option changed from 5 to 0	نتیجه نمایشی مثال 3؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

در Production پیش از خاموش‌کردن مطمئن شوید سامانه دیگری برای مشاهده Blocking وجود دارد. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

مثال 4: ساخت مقصد Ring Buffer برای گزارش

در این سناریو هدف، ایجاد یک Collector حداقلی برای دریافت XML Report است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = N'Capture_BlockedProcess')
        DROP EVENT SESSION [Capture_BlockedProcess] ON SERVER;
    -- مرز Batch اختیاری است؛ در اجرای جداگانه می‌توان از GO استفاده کرد.
    CREATE EVENT SESSION [Capture_BlockedProcess] ON SERVER
    ADD EVENT sqlserver.blocked_process_report
    ADD TARGET package0.ring_buffer
    (
        SET max_memory = 4096
    );
    -- مرز Batch اختیاری است؛ در اجرای جداگانه می‌توان از GO استفاده کرد.
    ALTER EVENT SESSION [Capture_BlockedProcess] ON SERVER STATE = START;
    -- مرز Batch اختیاری است؛ در اجرای جداگانه می‌توان از GO استفاده کرد.

خروجی نمونه	تفسیر
Session Capture_BlockedProcess در وضعیت Started قرار می‌گیرد	نتیجه نمایشی مثال 4؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

Ring Buffer محدود است و برای آرشیو طولانی Event File با Rollover مناسب‌تر خواهد بود. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

مثال 5: کنترل Started بودن Collector

در این سناریو هدف، تأیید هم‌زمان تعریف Session و وضعیت Runtime آن است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

SELECT
        ses.name,
        CASE WHEN dxs.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 dxs ON dxs.name = ses.name
    WHERE ses.name = N'Capture_BlockedProcess';

خروجی نمونه	تفسیر
Capture_BlockedProcess \| STARTED \| 0	نتیجه نمایشی مثال 5؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

وجود metadata به‌تنهایی به معنای Started بودن نیست؛ threshold نیز باید غیرصفر باشد. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

مثال 6: خواندن رخدادهای خام Ring Buffer

در این سناریو هدف، تبدیل Target XML به یک ردیف برای هر Event است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

;WITH target_data 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_BlockedProcess'
          AND t.target_name = N'ring_buffer'
    )
    SELECT
        n.e.value('@timestamp', 'datetime2') AS event_utc,
        n.e.query('.') AS event_xml
    FROM target_data AS td
    CROSS APPLY td.target_xml.nodes('/RingBufferTarget/event') AS n(e)
    ORDER BY event_utc DESC;

خروجی نمونه	تفسیر
2026-07-22 03:31:04 \| <event name="blocked_process_report" ...>	نتیجه نمایشی مثال 6؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

Timestamp رخداد XE معمولاً UTC است؛ Offset را هنگام نمایش محلی جداگانه اعمال و اصل UTC را حفظ کنید. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

مثال 7: استخراج SPIDهای Blocked و Blocker

در این سناریو هدف، استخراج دو شناسه اصلی از ساختار XML گزارش است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

;WITH events AS
    (
        SELECT n.e.query('.') AS event_xml
        FROM sys.dm_xe_session_targets AS t
        JOIN sys.dm_xe_sessions AS s ON s.address = t.event_session_address
        CROSS APPLY (SELECT CAST(t.target_data AS xml)) AS x(target_xml)
        CROSS APPLY x.target_xml.nodes('/RingBufferTarget/event[@name="blocked_process_report"]') AS n(e)
        WHERE s.name = N'Capture_BlockedProcess'
          AND t.target_name = N'ring_buffer'
    )
    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
    FROM events;

خروجی نمونه	تفسیر
64 \| 57	نتیجه نمایشی مثال 7؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

مسیر XML را با یک نمونه واقعی نسخه خود کنترل کنید؛ برخی ابزارها Wrapper متفاوتی نمایش می‌دهند. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

مثال 8: استخراج Wait Resource و Input Buffer

در این سناریو هدف، تبدیل XML به شواهد قابل جست‌وجو درباره منبع و دو Batch است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

;WITH events AS
    (
        SELECT n.e.query('.') AS event_xml
        FROM sys.dm_xe_session_targets AS t
        JOIN sys.dm_xe_sessions AS s ON s.address = t.event_session_address
        CROSS APPLY (SELECT CAST(t.target_data AS xml)) AS x(target_xml)
        CROSS APPLY x.target_xml.nodes('/RingBufferTarget/event[@name="blocked_process_report"]') AS n(e)
        WHERE s.name = N'Capture_BlockedProcess'
          AND t.target_name = N'ring_buffer'
    )
    SELECT
        event_xml.value('(event/data/value/blocked-process-report/blocked-process/process/@waitresource)[1]', 'nvarchar(256)') AS wait_resource,
        event_xml.value('(event/data/value/blocked-process-report/blocked-process/process/@lockMode)[1]', 'nvarchar(30)') AS requested_lock,
        event_xml.value('(event/data/value/blocked-process-report/blocked-process/process/inputbuf/text())[1]', 'nvarchar(4000)') AS blocked_input,
        event_xml.value('(event/data/value/blocked-process-report/blocking-process/process/inputbuf/text())[1]', 'nvarchar(4000)') AS blocker_input
    FROM events;

خروجی نمونه	تفسیر
KEY: 7:7205... \| X \| UPDATE dbo.Orders ... \| UPDATE dbo.Customers ...	نتیجه نمایشی مثال 8؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

Input Buffer ممکن است کل Batch باشد؛ Statement دقیق را در زمان رخداد از Actionهای XE یا Query Store تکمیل کنید. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

مثال 9: آزمایش Blocking در دو پنجره

در این سناریو هدف، بازسازی کنترل‌شده Blocking روی یک جدول آزمایش اختصاصی در دو اتصال است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

-- Window A
    BEGIN TRANSACTION;
    UPDATE dbo.BlockingLab
    SET ValueText = N'held by A'
    WHERE Id = 1;
    -- COMMIT را پس از مشاهده گزارش اجرا کنید.
    
    -- Window B (در اتصال جداگانه)
    -- UPDATE dbo.BlockingLab
    -- SET ValueText = N'waiting in B'
    -- WHERE Id = 1;

خروجی نمونه	تفسیر
پس از عبور از threshold، یک blocked_process_report تولید می‌شود	نتیجه نمایشی مثال 9؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

این سناریو را هرگز روی جدول کسب‌وکار اجرا نکنید و Transaction پنجره A را در پایان Commit یا Rollback کنید. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

مثال 10: برآورد نرخ رخداد و خطر Event Storm

در این سناریو هدف، اندازه‌گیری حجم Event موجود برای بازنگری threshold و Retention است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه می‌کند؛ فرمان‌های تغییردهنده باید ابتدا در Lab و با مجوز کنترل‌شده آزموده شوند.

;WITH target_data 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_BlockedProcess'
          AND t.target_name = N'ring_buffer'
    )
    SELECT COUNT_BIG(*) AS captured_event_count
    FROM target_data AS td
    CROSS APPLY td.target_xml.nodes('/RingBufferTarget/event[@name="blocked_process_report"]') AS n(e);

خروجی نمونه	تفسیر
captured_event_count = 28	نتیجه نمایشی مثال 10؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است.

یک Blocking طولانی می‌تواند گزارش‌های تکراری بسازد؛ Count را با مدت Session و Drop Count هدف مقایسه کنید. این نتیجه نمونه کمک می‌کند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمی‌گیرد.

خطاهای رایج

تنظیم threshold بدون Session جمع‌آوری هیچ آرشیوی ایجاد نمی‌کند؛ ابتدا مقصد، Retention و فرایند پاک‌سازی را طراحی کنید.
نتیجه‌گیری از یک Snapshot بدون Timestamp، Baseline یا تکرار رخداد.
اشتباه گرفتن Session خواب، Wait طبیعی یا Victim با علت ریشه‌ای.
اجرای Query سنگین متن و Plan برای تمام Sessionها با فاصله بسیار کوتاه.
ثبت نکردن نسخه SQL Server، مجوز حساب و تنظیمات Collector در گزارش Incident.

اگر خروجی خالی بود، ابتدا مجوز، Scope، Started بودن Session و زمان نمونه‌برداری را بررسی کنید. خالی بودن یک DMV یا Target دلیل قطعی نبود مشکل در چند دقیقه قبل نیست.

ملاحظات Performance

آستانه بسیار پایین در بارکاری پرتراکنش Event Storm ایجاد می‌کند؛ معمولاً مقدار ۵ ثانیه یا بیشتر با توجه به SLA انتخاب می‌شود. برای Collector، مدت اجرای خود Query، تعداد ردیف، اندازه XML و تعداد رخداد ازدست‌رفته را نیز به‌عنوان Telemetry ثبت کنید.

ابتدا روی داده‌های ارزان مانند Session ID، زمان و Wait فیلتر کنید و سپس برای نامزدهای محدود متن SQL، Input Buffer یا Query Plan را بگیرید. این الگو هم سربار را کم می‌کند و هم اطلاعات حساس غیرمرتبط را وارد آرشیو نمی‌کند.

بهترین روش‌ها در محیط واقعی

برای هر هشدار سؤال و آستانه‌ای مرتبط با SLA تعریف کنید.
Timestamp را در UTC یا datetimeoffset ذخیره و زمان محلی را فقط برای نمایش تبدیل کنید.
شناسه Session را با Login، Host، Program، Database و زمان اتصال تثبیت کنید.
قبل از KILL یا تغییر تنظیمات، Transaction و هزینه Rollback را بسنجید.
شواهد خام را حفظ و تفسیر و تصمیم را جداگانه در Incident ثبت کنید.
Query جمع‌آوری را Load Test و Retention و پاک‌سازی را خودکار کنید.

هدف نهایی حذف کورکورانه Wait نیست؛ باید تراکنش کوتاه‌تر، ترتیب دسترسی ثابت‌تر، ایندکس مناسب‌تر یا Retry محدود در لایه درست ایجاد شود. مشاهده دقیق تنها راه رسیدن به چنین اصلاح پایداری است.

کاربرد سازمانی و سناریوی واقعی

فرض کنید API سفارش در ساعت اوج با Timeout روبه‌رو شده است. تیم ابتدا با Blocked Process Report شواهد مرتبط را می‌گیرد، آن را به Correlation ID و مالک سرویس متصل می‌کند و اثر روی تعداد درخواست‌های مشتری را می‌سنجد. اگر Head Blocker یا Deadlock اثبات شد، اقدام کوتاه‌مدت کنترل‌شده و سپس اصلاح کد یا Index در Backlog قرار می‌گیرد.

در گزارش نهایی باید زمان شروع و پایان، Database، Query Hash در صورت دسترس، تعداد کاربران متأثر، تصمیم‌ها، مجوز اقدام و نتیجه Deploy ثبت شود. این ساختار داده فنی را به زبان قابل فهم برای عملیات و کسب‌وکار تبدیل می‌کند.

سؤالات متداول

پرسش 1: Blocked Process Report دقیقاً چه مسئله‌ای را در SQL Server حل می‌کند؟

Blocked Process Report یک سند XML است که پس از عبور Blocking از آستانه تنظیم‌شده تولید می‌شود و اطلاعات Blocked، Blocker، منبع انتظار و Input Buffer را ثبت می‌کند. ارزش اصلی آن زمانی آشکار می‌شود که سؤال عملیاتی مشخص باشد؛ مثلاً شناسایی Head Blocker، تعیین منبع انتظار یا حفظ شواهد Deadlock. خروجی باید کنار زمان رخداد و مشخصات Application نگهداری شود تا از یک Snapshot خام به پاسخ قابل اقدام برسیم.

پرسش 2: برای شروع کار با Blocked Process Report چه پیش‌نیازی لازم است؟

ابتدا در محیط آزمایش Syntax و ستون‌های نسخه نصب‌شده را بررسی کنید، سپس مجوز حداقلی مشاهده وضعیت را در نظر بگیرید. تنظیم آستانه به مجوز سطح سرور و جمع‌آوری Extended Events به مجوزهای مربوط نیاز دارد. اجرای Query با حساب Production پرقدرت راه‌حل مناسبی نیست و بهتر است نقش مانیتورینگ مشخص و ممیزی‌شده ساخته شود.

پرسش 3: استفاده از Blocked Process Report چه ارزش تجاری برای سامانه پرتراکنش دارد؟

کاهش زمان تشخیص Incident، جلوگیری از تصمیم عجولانه و کوتاه‌شدن اختلال مستقیم‌ترین ارزش‌ها هستند. وقتی داده این ابزار با SLA و مالک سرویس پیوند بخورد، تیم می‌تواند بین کندی عادی، Blocking زیان‌آور و Deadlock تکرارشونده تفاوت بگذارد و هزینه توقف را کم کند.

پرسش 4: چه زمانی برای پیاده‌سازی مانیتورینگ Blocked Process Report به مشاوره تخصصی نیاز داریم؟

اگر رخدادها تکراری، چندپایگاه‌داده‌ای، حساس به امنیت یا دارای حجم Event بالا هستند، طراحی Baseline، Retention و Runbook تخصصی مفید است. مشاوره SQL Server باید در کنار جمع‌آوری داده، Query Plan، تراکنش، ایندکس و رفتار کد Application را نیز بررسی کند؛ خرید ابزار بدون فرایند پاسخ‌گویی کافی نیست.

پرسش 5: تفاوت Blocked Process Report با ابزار نزدیک آن چیست؟

برخلاف Snapshot لحظه‌ای DMV، گزارش پس از گذشت آستانه ساخته می‌شود و شواهد تاریخی قابل نگهداری از دو سوی Blocking می‌دهد. انتخاب درست به این بستگی دارد که داده لحظه‌ای، تاریخچه XML، مشخصات Session یا امکان اقدام مدیریتی لازم باشد. در عیب‌یابی حرفه‌ای معمولاً چند منبع مکمل کنار هم استفاده می‌شوند، نه اینکه یک خروجی به تنهایی حقیقت کامل فرض شود.

پرسش 6: آیا می‌توان پیاده‌سازی داشبورد یا پروژه Blocked Process Report را به تیم متخصص سپرد؟

بله؛ تحویل حرفه‌ای باید شامل تعریف نیاز، Queryهای کم‌هزینه، کنترل مجوز، ذخیره UTC، سیاست Retention، هشدار قابل تنظیم، داشبورد و Runbook اعتبارسنجی‌شده باشد. پیش از پذیرش پروژه، اثر مانیتورینگ روی Production و روش تست خطا نیز باید مستند شود.

پرسش 7: رایج‌ترین خطا هنگام تحلیل Blocked Process Report چیست؟

تنظیم threshold بدون Session جمع‌آوری هیچ آرشیوی ایجاد نمی‌کند؛ ابتدا مقصد، Retention و فرایند پاک‌سازی را طراحی کنید. خطای دوم تصمیم‌گیری از روی یک Snapshot بدون Baseline است. زمان رخداد، Login، Host، Database، Transaction و Query متناظر را کنار هم قرار دهید و هر مقدار NULL یا نامشخص را صادقانه حفظ کنید.

پرسش 8: آیا Query گرفتن از Blocked Process Report روی Performance اثر می‌گذارد؟

آستانه بسیار پایین در بارکاری پرتراکنش Event Storm ایجاد می‌کند؛ معمولاً مقدار ۵ ثانیه یا بیشتر با توجه به SLA انتخاب می‌شود. خود مشاهده نیز رایگان نیست، به‌ویژه وقتی XML، Plan یا Text برای تعداد زیادی Session استخراج شود. Period نمونه‌برداری، فیلتر، سقف نگهداری و مانیتور Dropped Event باید بخشی از طراحی باشد.

پرسش 9: بهترین روش استفاده Production از Blocked Process Report چیست؟

پرسش عملیاتی را از قبل تعریف کنید، کمترین ستون و Scope لازم را جمع کنید، Timestamp UTC و شناسه Incident بسازید و اقدام مخرب را از جمع‌آوری شواهد جدا نگه دارید. Runbook باید مرحله تأیید هویت Session، اثر Rollback، تماس با مالک سرویس و معیار پایان Incident را روشن کند.

پرسش 10: Blocked Process Report در کدام نسخه‌های SQL Server قابل استفاده است؟

جزئیات ستون، مجوز و Eventها با نسخه و Azure SQL تفاوت دارد؛ بنابراین metadata و مستندات همان نسخه باید مرجع نهایی باشد. تنظیم آستانه به مجوز سطح سرور و جمع‌آوری Extended Events به مجوزهای مربوط نیاز دارد. در ارتقا، Queryها را روی محیط Stage اجرا کنید و به‌ویژه قابلیت‌های Undocumented یا Deprecated را با جایگزین مستند عوض کنید.

سؤالات مصاحبه تخصصی

سؤال 1: چگونه با Blocked Process Report بین علامت و علت ریشه‌ای تفاوت می‌گذارید؟

ابتدا داده آن را با Request، Session، Transaction و Timeline مرتبط می‌کنم؛ سپس Head Blocker یا چرخه Resource را اثبات و فقط پس از آن راهکار ایندکس، ترتیب دسترسی یا کنترل Transaction پیشنهاد می‌دهم.

سؤال 2: چرا یک Snapshot از Blocked Process Report کافی نیست؟

زیرا وضعیت قفل و Wait پویاست. حداقل دو نمونه زمان‌دار، شواهد تاریخی Extended Events و Context برنامه برای تشخیص تداوم، نرخ و اثر لازم است.

سؤال 3: چه کنترل امنیتی برای Blocked Process Report تعریف می‌کنید؟

نقش Read-only با کمترین مجوز، ثبت اجرا، محدودکردن دسترسی به متن Query و جداکردن اختیار KILL یا ALTER EVENT SESSION از مشاهده معمول را در نظر می‌گیرم.

سؤال 4: در طراحی Collector برای Blocked Process Report چه معیارهایی دارید؟

هزینه Query، دوره نمونه‌برداری، حداکثر حجم، Retention، Dropped Event، Timestamp UTC، حذف داده حساس و امکان Correlation با Incident را اندازه می‌گیرم.

سؤال 5: اگر خروجی Blocked Process Report NULL یا خالی باشد چه می‌کنید؟

خالی بودن را به نبود مشکل تعمیم نمی‌دهم؛ مجوز، Started بودن Collector، threshold، زمان Snapshot و منبع مکمل مانند system_health یا Query Store را بررسی می‌کنم.

چک‌لیست نهایی

هدف Query و Scope پایگاه داده مشخص است.
نسخه SQL Server و مجوز لازم تأیید شده است.
Timestamp UTC، Session، Login، Host و Program ثبت می‌شود.
خروجی با DMV یا Event مکمل اعتبارسنجی شده است.
اقدام مخرب از مشاهده جدا و دارای تأیید است.
هزینه Collector، Retention و Dropped Event پایش می‌شود.
علت ریشه‌ای و اصلاح دائمی در Incident مستند شده است.

جمع‌بندی

Blocked Process Report زمانی بیشترین ارزش را دارد که با پرسش درست، فیلتر هدفمند و Timeline قابل اعتماد استفاده شود. Blocked Process Report یک سند XML است که پس از عبور Blocking از آستانه تنظیم‌شده تولید می‌شود و اطلاعات Blocked، Blocker، منبع انتظار و Input Buffer را ثبت می‌کند. با این حال خروجی لحظه‌ای جای تحلیل Transaction، Query Plan و رفتار Application را نمی‌گیرد.

برای مرور ابزارهای مکمل، مسیر تشخیص و لینک همه مقاله‌ها به مقاله مادر پایش Blocking و Deadlock در SQL Server بازگردید. در Production ابتدا شواهد را حفظ کنید، سپس اثر اقدام را بسنجید و اصلاح پایدار را به جای درمان موقت در اولویت بگذارید.

Blocked Process Report در SQL Server؛ آموزش کامل، مثال و نکات Performance