مثالهای عملی
مثال 1: خواندن Input Buffer نشست جاری
در این سناریو هدف، آشنایی بدون نیاز به دانستن SPID دیگر یا مجوز گسترده است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT event_type, parameters, event_info
FROM sys.dm_exec_input_buffer(@@SPID, 0);
| خروجی نمونه | تفسیر |
|---|
| Language Event | 0 | SELECT event_type ... | نتیجه نمایشی مثال 1؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
خروجی معمولاً Batch جاری را نشان میدهد و برای تمرین امن مناسب است. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 2: خواندن فرمان یک Session مشخص
در این سناریو هدف، بازیابی آخرین ورودی Session هدف با Request پیشفرض است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
DECLARE @SessionId smallint = 57;
SELECT event_type, parameters, event_info
FROM sys.dm_exec_input_buffer(@SessionId, NULL);
| خروجی نمونه | تفسیر |
|---|
| RPC Event | 1 | ProcName;1 | نتیجه نمایشی مثال 2؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
پیش از نتیجهگیری بررسی کنید SPID هنوز متعلق به همان اتصال باشد، چون شناسهها پس از پایان قابل استفاده مجددند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 3: ورودی تمام درخواستهای فعال
در این سناریو هدف، جمعآوری ورودی برای Requestهای فعال کاربری است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
r.session_id,
r.request_id,
ib.event_type,
ib.event_info
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_input_buffer(r.session_id, r.request_id) AS ib
WHERE r.session_id > 50
AND r.session_id <> @@SPID;
| خروجی نمونه | تفسیر |
|---|
| 63 | 0 | Language Event | SELECT ... | نتیجه نمایشی مثال 3؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
فیلتر Requestها پیش از APPLY تعداد فراخوانی تابع و هزینه مانیتورینگ را محدود میکند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 4: نمایش Input Buffer نشستهای Blocked
در این سناریو هدف، مشاهده فرمان سمت Blocked برای فهم منبع مورد تقاضا است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
r.session_id AS blocked_session_id,
r.blocking_session_id,
r.wait_type,
ib.event_info AS blocked_input
FROM sys.dm_exec_requests AS r
OUTER APPLY sys.dm_exec_input_buffer(r.session_id, r.request_id) AS ib
WHERE r.blocking_session_id > 0;
| خروجی نمونه | تفسیر |
|---|
| 64 | 57 | LCK_M_X | UPDATE dbo.Orders ... | نتیجه نمایشی مثال 4؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
برای علت ریشهای، Input Buffer نشست Blocker را نیز با APPLY دوم استخراج کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 5: یافتن فرمان Head Blocker خواب
در این سناریو هدف، آشکارکردن آخرین Batch نشست خواب دارای تراکنش باز است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
s.session_id,
s.login_name,
s.status,
s.open_transaction_count,
ib.event_info AS last_input
FROM sys.dm_exec_sessions AS s
OUTER APPLY sys.dm_exec_input_buffer(s.session_id, NULL) AS ib
WHERE s.is_user_process = 1
AND s.status = N'sleeping'
AND s.open_transaction_count > 0;
| خروجی نمونه | تفسیر |
|---|
| 57 | app_user | sleeping | 1 | UPDATE dbo.Orders ... | نتیجه نمایشی مثال 5؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
آخرین Batch ممکن است شامل چند Statement باشد؛ Transaction log و برنامه را نیز بررسی کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 6: تفسیر نوع Event و پارامترها
در این سناریو هدف، تفکیک Language Event از RPC و محدودکردن متن نمایشی است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
s.session_id,
ib.event_type,
ib.parameters,
LEFT(ib.event_info, 4000) AS event_info
FROM sys.dm_exec_sessions AS s
OUTER APPLY sys.dm_exec_input_buffer(s.session_id, NULL) AS ib
WHERE s.is_user_process = 1;
| خروجی نمونه | تفسیر |
|---|
| 57 | RPC Event | 1 | dbo.UpdateOrder;1 | نتیجه نمایشی مثال 6؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
parameters تعداد پارامترها یا جزئیات رخداد است و معنای آن را باید همراه event_type خواند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 7: ترکیب Input Buffer با مشخصات Client
در این سناریو هدف، ساخت رکورد قابل ارجاع برای تیم Application است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
s.session_id,
s.login_name,
s.host_name,
s.program_name,
ib.event_info
FROM sys.dm_exec_sessions AS s
OUTER APPLY sys.dm_exec_input_buffer(s.session_id, NULL) AS ib
WHERE s.is_user_process = 1
AND s.session_id <> @@SPID;
| خروجی نمونه | تفسیر |
|---|
| 57 | app_user | WEB-02 | OrderApi | EXEC dbo.UpdateOrder ... | نتیجه نمایشی مثال 7؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
host_name و program_name داده Client هستند؛ برای ممیزی قطعی Correlation ID و Login اختصاصی نیز لازم است. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 8: مقایسه با DBCC INPUTBUFFER
در این سناریو هدف، نشان دادن جایگزین ساختیافته DMV برای فرمان قدیمی DBCC است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
DECLARE @SessionId smallint = @@SPID;
DBCC INPUTBUFFER(@SessionId) WITH NO_INFOMSGS;
SELECT event_type, parameters, event_info
FROM sys.dm_exec_input_buffer(@SessionId, NULL);
| خروجی نمونه | تفسیر |
|---|
| هر دو خروجی آخرین Batch نشست جاری را نشان میدهند | نتیجه نمایشی مثال 8؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
تابع جدید را میتوان APPLY و فیلتر کرد؛ DBCC خروجی قدیمیتری برای بررسی دستی دارد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 9: مدیریت Event Info تهی
در این سناریو هدف، نمایش صریح نبود داده به جای حذف Session از گزارش است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
s.session_id,
COALESCE(NULLIF(ib.event_info, N''), N'(input buffer unavailable)') AS event_info
FROM sys.dm_exec_sessions AS s
OUTER APPLY sys.dm_exec_input_buffer(s.session_id, NULL) AS ib
WHERE s.is_user_process = 1;
| خروجی نمونه | تفسیر |
|---|
| 71 | (input buffer unavailable) | نتیجه نمایشی مثال 9؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
OUTER APPLY نشست را نگه میدارد؛ CROSS APPLY ممکن است در نبود خروجی ردیف را حذف کند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 10: الگوی کمهزینه برای فقط Blockerها
در این سناریو هدف، فراخوانی تابع فقط برای Blockerهای یکتا به جای همه Sessionها است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
;WITH blockers AS
(
SELECT DISTINCT blocking_session_id AS session_id
FROM sys.dm_exec_requests
WHERE blocking_session_id > 0
)
SELECT
b.session_id,
ib.event_type,
ib.event_info
FROM blockers AS b
OUTER APPLY sys.dm_exec_input_buffer(b.session_id, NULL) AS ib;
| خروجی نمونه | تفسیر |
|---|
| 57 | Language Event | BEGIN TRAN; UPDATE ... | نتیجه نمایشی مثال 10؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
DISTINCT از تکرار Input Buffer یک Head Blocker با چندین قربانی جلوگیری میکند. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
سؤالات متداول
پرسش 1: sys.dm_exec_input_buffer دقیقاً چه مسئلهای را در SQL Server حل میکند؟
تابع مدیریتی sys.dm_exec_input_buffer متن آخرین Batch یا RPC ارسالشده برای یک Session و Request را برمیگرداند و به شناسایی فرمان Blocker حتی در حالت Sleeping کمک میکند. ارزش اصلی آن زمانی آشکار میشود که سؤال عملیاتی مشخص باشد؛ مثلاً شناسایی Head Blocker، تعیین منبع انتظار یا حفظ شواهد Deadlock. خروجی باید کنار زمان رخداد و مشخصات Application نگهداری شود تا از یک Snapshot خام به پاسخ قابل اقدام برسیم.
پرسش 2: برای شروع کار با sys.dm_exec_input_buffer چه پیشنیازی لازم است؟
ابتدا در محیط آزمایش Syntax و ستونهای نسخه نصبشده را بررسی کنید، سپس مجوز حداقلی مشاهده وضعیت را در نظر بگیرید. سطح دسترسی به نسخه SQL Server و مالک Session بستگی دارد؛ برای مشاهده نشستهای دیگر مجوز وضعیت سرور لازم میشود. اجرای Query با حساب Production پرقدرت راهحل مناسبی نیست و بهتر است نقش مانیتورینگ مشخص و ممیزیشده ساخته شود.
پرسش 3: استفاده از sys.dm_exec_input_buffer چه ارزش تجاری برای سامانه پرتراکنش دارد؟
کاهش زمان تشخیص Incident، جلوگیری از تصمیم عجولانه و کوتاهشدن اختلال مستقیمترین ارزشها هستند. وقتی داده این ابزار با SLA و مالک سرویس پیوند بخورد، تیم میتواند بین کندی عادی، Blocking زیانآور و Deadlock تکرارشونده تفاوت بگذارد و هزینه توقف را کم کند.
پرسش 4: چه زمانی برای پیادهسازی مانیتورینگ sys.dm_exec_input_buffer به مشاوره تخصصی نیاز داریم؟
اگر رخدادها تکراری، چندپایگاهدادهای، حساس به امنیت یا دارای حجم Event بالا هستند، طراحی Baseline، Retention و Runbook تخصصی مفید است. مشاوره SQL Server باید در کنار جمعآوری داده، Query Plan، تراکنش، ایندکس و رفتار کد Application را نیز بررسی کند؛ خرید ابزار بدون فرایند پاسخگویی کافی نیست.
پرسش 5: تفاوت sys.dm_exec_input_buffer با ابزار نزدیک آن چیست؟
این تابع جایگزین ساختیافته و قابل اتصال DBCC INPUTBUFFER است و برخلاف dm_exec_sql_text میتواند آخرین ورودی یک نشست Sleeping را نیز نشان دهد. انتخاب درست به این بستگی دارد که داده لحظهای، تاریخچه XML، مشخصات Session یا امکان اقدام مدیریتی لازم باشد. در عیبیابی حرفهای معمولاً چند منبع مکمل کنار هم استفاده میشوند، نه اینکه یک خروجی به تنهایی حقیقت کامل فرض شود.
پرسش 6: آیا میتوان پیادهسازی داشبورد یا پروژه sys.dm_exec_input_buffer را به تیم متخصص سپرد؟
بله؛ تحویل حرفهای باید شامل تعریف نیاز، Queryهای کمهزینه، کنترل مجوز، ذخیره UTC، سیاست Retention، هشدار قابل تنظیم، داشبورد و Runbook اعتبارسنجیشده باشد. پیش از پذیرش پروژه، اثر مانیتورینگ روی Production و روش تست خطا نیز باید مستند شود.
پرسش 7: رایجترین خطا هنگام تحلیل sys.dm_exec_input_buffer چیست؟
event_info لزوماً Statement دقیق در حال اجرا نیست؛ ممکن است کل Batch یا نام RPC را نشان دهد و برای Request فعال باید با offsets تکمیل شود. خطای دوم تصمیمگیری از روی یک Snapshot بدون Baseline است. زمان رخداد، Login، Host، Database، Transaction و Query متناظر را کنار هم قرار دهید و هر مقدار NULL یا نامشخص را صادقانه حفظ کنید.
پرسش 8: آیا Query گرفتن از sys.dm_exec_input_buffer روی Performance اثر میگذارد؟
ابتدا Sessionهای هدف را محدود کنید و سپس APPLY بزنید؛ فراخوانی تابع برای همه Sessionها در حلقه سریع ضرورتی ندارد. خود مشاهده نیز رایگان نیست، بهویژه وقتی XML، Plan یا Text برای تعداد زیادی Session استخراج شود. Period نمونهبرداری، فیلتر، سقف نگهداری و مانیتور Dropped Event باید بخشی از طراحی باشد.
پرسش 9: بهترین روش استفاده Production از sys.dm_exec_input_buffer چیست؟
پرسش عملیاتی را از قبل تعریف کنید، کمترین ستون و Scope لازم را جمع کنید، Timestamp UTC و شناسه Incident بسازید و اقدام مخرب را از جمعآوری شواهد جدا نگه دارید. Runbook باید مرحله تأیید هویت Session، اثر Rollback، تماس با مالک سرویس و معیار پایان Incident را روشن کند.
پرسش 10: sys.dm_exec_input_buffer در کدام نسخههای SQL Server قابل استفاده است؟
جزئیات ستون، مجوز و Eventها با نسخه و Azure SQL تفاوت دارد؛ بنابراین metadata و مستندات همان نسخه باید مرجع نهایی باشد. سطح دسترسی به نسخه SQL Server و مالک Session بستگی دارد؛ برای مشاهده نشستهای دیگر مجوز وضعیت سرور لازم میشود. در ارتقا، Queryها را روی محیط Stage اجرا کنید و بهویژه قابلیتهای Undocumented یا Deprecated را با جایگزین مستند عوض کنید.