مثالهای عملی
مثال 1: فهرست درخواستهای کاربری فعال
در این سناریو هدف، جداکردن فعالیت کاربری از Requestهای داخلی و Session مانیتور است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id, status, command, start_time
FROM sys.dm_exec_requests
WHERE session_id > 50
AND session_id <> @@SPID
ORDER BY start_time;
| خروجی نمونه | تفسیر |
|---|
| 57 | running | SELECT | 2026-07-22 05:20 | نتیجه نمایشی مثال 1؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
قدیمیترین start_time نقطه شروع بررسی است، نه مجوز خودکار برای پایان دادن Session. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 2: رتبهبندی CPU و خواندنها
در این سناریو هدف، یافتن Requestهای پرمصرف در Snapshot جاری است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT TOP (20)
session_id,
cpu_time,
logical_reads,
reads,
writes,
total_elapsed_time
FROM sys.dm_exec_requests
WHERE session_id > 50
ORDER BY cpu_time DESC, logical_reads DESC;
| خروجی نمونه | تفسیر |
|---|
| 63 | 18420 | 950331 | 320 | 12 | 22150 | نتیجه نمایشی مثال 2؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
مقادیر تجمعی از شروع Request هستند؛ نرخ مصرف را با دو Snapshot فاصلهدار دقیقتر بسنجید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 3: مشاهده نشستهای Blocked
در این سناریو هدف، ساخت سریع صف Blockedها و شناسه Blocker مستقیم است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id AS blocked_session_id,
blocking_session_id,
wait_type,
wait_time,
wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id > 0
ORDER BY wait_time DESC;
| خروجی نمونه | تفسیر |
|---|
| 64 | 57 | LCK_M_X | 8120 | KEY: 7:7205... | نتیجه نمایشی مثال 3؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Blocker ریشهای ممکن است خودش توسط Session دیگری Block شده باشد؛ زنجیره را تا Head Blocker دنبال کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 4: تحلیل Wait جاری هر Request
در این سناریو هدف، تفکیک Blocking قفل از انتظارهای ذخیرهسازی و سایر منابع است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id,
status,
wait_type,
last_wait_type,
wait_time,
wait_resource
FROM sys.dm_exec_requests
WHERE session_id > 50
AND wait_type IS NOT NULL;
| خروجی نمونه | تفسیر |
|---|
| 72 | suspended | PAGEIOLATCH_SH | PAGEIOLATCH_SH | 240 | 7:1:4852 | نتیجه نمایشی مثال 4؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Wait کوتاه طبیعی است؛ مدت، تکرار و اثر روی SLA باید کنار نوع Wait دیده شود. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 5: پایش درصد پیشرفت عملیات طولانی
در این سناریو هدف، پایش Backup، Restore، Rollback و برخی عملیات دارای progress است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id,
command,
percent_complete,
estimated_completion_time / 1000.0 AS estimated_seconds,
total_elapsed_time / 1000.0 AS elapsed_seconds
FROM sys.dm_exec_requests
WHERE percent_complete > 0;
| خروجی نمونه | تفسیر |
|---|
| 81 | BACKUP DATABASE | 62.50 | 95.2 | 158.7 | نتیجه نمایشی مثال 5؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
برای بیشتر SELECTها percent_complete صفر است و صفر را نباید به معنای گیرکردن عملیات دانست. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 6: استخراج Statement جاری از Batch
در این سناریو هدف، نمایش فقط Statement فعال به جای کل Stored Procedure یا Batch است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
r.session_id,
SUBSTRING(
st.text,
(r.statement_start_offset / 2) + 1,
((CASE r.statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE r.statement_end_offset
END - r.statement_start_offset) / 2) + 1
) AS current_statement
FROM sys.dm_exec_requests AS r
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) AS st
WHERE r.session_id > 50;
| خروجی نمونه | تفسیر |
|---|
| 63 | UPDATE dbo.Invoice SET Status = 2 WHERE InvoiceId = 9001 | نتیجه نمایشی مثال 6؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Offsetها بر حسب Byte هستند؛ تقسیم بر دو برای متن Unicode ضروری است. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 7: دریافت Execution Plan نامزد محدود
در این سناریو هدف، گرفتن Plan فقط برای پنج Request طولانیتر است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT TOP (5)
r.session_id,
r.total_elapsed_time,
qp.query_plan
FROM sys.dm_exec_requests AS r
OUTER APPLY sys.dm_exec_query_plan(r.plan_handle) AS qp
WHERE r.session_id > 50
ORDER BY r.total_elapsed_time DESC;
| خروجی نمونه | تفسیر |
|---|
| 63 | 22150 | XML ShowPlan | نتیجه نمایشی مثال 7؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Plan XML حجیم است؛ آن را در Polling سریع برای همه درخواستها استخراج نکنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 8: یافتن Queryهای طولانیتر از سی ثانیه
در این سناریو هدف، اعمال آستانه عملیاتی برای کاهش نویز داشبورد است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id,
command,
total_elapsed_time / 1000.0 AS elapsed_seconds,
cpu_time / 1000.0 AS cpu_seconds,
logical_reads
FROM sys.dm_exec_requests
WHERE session_id > 50
AND total_elapsed_time >= 30000
ORDER BY total_elapsed_time DESC;
| خروجی نمونه | تفسیر |
|---|
| 63 | SELECT | 42.8 | 18.4 | 950331 | نتیجه نمایشی مثال 8؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
آستانه را بر اساس نوع سرویس تنظیم کنید؛ سی ثانیه برای OLTP زیاد و برای ETL شاید عادی باشد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 9: بررسی مصرف TempDB توسط Request
در این سناریو هدف، پیوند Request فعال به تخصیص Task در TempDB است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
r.session_id,
r.request_id,
(tsu.user_objects_alloc_page_count - tsu.user_objects_dealloc_page_count) * 8 AS user_kb,
(tsu.internal_objects_alloc_page_count - tsu.internal_objects_dealloc_page_count) * 8 AS internal_kb
FROM sys.dm_exec_requests AS r
JOIN sys.dm_db_task_space_usage AS tsu
ON tsu.session_id = r.session_id
AND tsu.request_id = r.request_id
WHERE r.session_id > 50;
| خروجی نمونه | تفسیر |
|---|
| 63 | 0 | 2048 | 65536 | نتیجه نمایشی مثال 9؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
در Query موازی چند Task وجود دارد؛ برای عدد Request باید ردیفها را SUM و GROUP BY کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 10: Snapshot سبک برای سامانه مانیتورینگ
در این سناریو هدف، ثبت فقط Requestهای Blocked یا طولانی برای کنترل حجم داده است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id,
status,
command,
blocking_session_id,
wait_type,
total_elapsed_time
FROM sys.dm_exec_requests
WHERE session_id > 50
AND session_id <> @@SPID
AND (blocking_session_id > 0 OR total_elapsed_time >= 5000);
| خروجی نمونه | تفسیر |
|---|
| 64 | suspended | UPDATE | 57 | LCK_M_X | 8120 | نتیجه نمایشی مثال 10؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
فیلتر قبل از APPLY متن و Plan، هزینه جمعآوری و اندازه آرشیو را کاهش میدهد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
سؤالات متداول
پرسش 1: sys.dm_exec_requests دقیقاً چه مسئلهای را در SQL Server حل میکند؟
نمای sys.dm_exec_requests هر درخواست فعال در SQL Server را با وضعیت اجرا، زمان CPU، خواندنها، Wait جاری، نشست مسدودکننده و درصد پیشرفت عملیات طولانی نشان میدهد. ارزش اصلی آن زمانی آشکار میشود که سؤال عملیاتی مشخص باشد؛ مثلاً شناسایی Head Blocker، تعیین منبع انتظار یا حفظ شواهد Deadlock. خروجی باید کنار زمان رخداد و مشخصات Application نگهداری شود تا از یک Snapshot خام به پاسخ قابل اقدام برسیم.
پرسش 2: برای شروع کار با sys.dm_exec_requests چه پیشنیازی لازم است؟
ابتدا در محیط آزمایش Syntax و ستونهای نسخه نصبشده را بررسی کنید، سپس مجوز حداقلی مشاهده وضعیت را در نظر بگیرید. برای مشاهده درخواستهای دیگران به مجوزهای مشاهده وضعیت سرور متناسب با نسخه نیاز است. اجرای Query با حساب Production پرقدرت راهحل مناسبی نیست و بهتر است نقش مانیتورینگ مشخص و ممیزیشده ساخته شود.
پرسش 3: استفاده از sys.dm_exec_requests چه ارزش تجاری برای سامانه پرتراکنش دارد؟
کاهش زمان تشخیص Incident، جلوگیری از تصمیم عجولانه و کوتاهشدن اختلال مستقیمترین ارزشها هستند. وقتی داده این ابزار با SLA و مالک سرویس پیوند بخورد، تیم میتواند بین کندی عادی، Blocking زیانآور و Deadlock تکرارشونده تفاوت بگذارد و هزینه توقف را کم کند.
پرسش 4: چه زمانی برای پیادهسازی مانیتورینگ sys.dm_exec_requests به مشاوره تخصصی نیاز داریم؟
اگر رخدادها تکراری، چندپایگاهدادهای، حساس به امنیت یا دارای حجم Event بالا هستند، طراحی Baseline، Retention و Runbook تخصصی مفید است. مشاوره SQL Server باید در کنار جمعآوری داده، Query Plan، تراکنش، ایندکس و رفتار کد Application را نیز بررسی کند؛ خرید ابزار بدون فرایند پاسخگویی کافی نیست.
پرسش 5: تفاوت sys.dm_exec_requests با ابزار نزدیک آن چیست؟
sys.dm_exec_sessions عمر یک نشست را توصیف میکند، اما sys.dm_exec_requests فقط کار فعال همان لحظه را نشان میدهد؛ اتصال این دو نمای کاملتری میسازد. انتخاب درست به این بستگی دارد که داده لحظهای، تاریخچه XML، مشخصات Session یا امکان اقدام مدیریتی لازم باشد. در عیبیابی حرفهای معمولاً چند منبع مکمل کنار هم استفاده میشوند، نه اینکه یک خروجی به تنهایی حقیقت کامل فرض شود.
پرسش 6: آیا میتوان پیادهسازی داشبورد یا پروژه sys.dm_exec_requests را به تیم متخصص سپرد؟
بله؛ تحویل حرفهای باید شامل تعریف نیاز، Queryهای کمهزینه، کنترل مجوز، ذخیره UTC، سیاست Retention، هشدار قابل تنظیم، داشبورد و Runbook اعتبارسنجیشده باشد. پیش از پذیرش پروژه، اثر مانیتورینگ روی Production و روش تست خطا نیز باید مستند شود.
پرسش 7: رایجترین خطا هنگام تحلیل sys.dm_exec_requests چیست؟
صفر بودن blocking_session_id به معنای نبود هر نوع انتظار نیست؛ درخواست میتواند روی I/O، حافظه، CPU یا Latch منتظر باشد. خطای دوم تصمیمگیری از روی یک Snapshot بدون Baseline است. زمان رخداد، Login، Host، Database، Transaction و Query متناظر را کنار هم قرار دهید و هر مقدار NULL یا نامشخص را صادقانه حفظ کنید.
پرسش 8: آیا Query گرفتن از sys.dm_exec_requests روی Performance اثر میگذارد؟
ستونهای پرهزینه مانند Plan XML را فقط برای نامزدهای فیلترشده دریافت کنید و از CROSS APPLY بدون شرط روی همه درخواستها در نمونهبرداری سریع بپرهیزید. خود مشاهده نیز رایگان نیست، بهویژه وقتی XML، Plan یا Text برای تعداد زیادی Session استخراج شود. Period نمونهبرداری، فیلتر، سقف نگهداری و مانیتور Dropped Event باید بخشی از طراحی باشد.
پرسش 9: بهترین روش استفاده Production از sys.dm_exec_requests چیست؟
پرسش عملیاتی را از قبل تعریف کنید، کمترین ستون و Scope لازم را جمع کنید، Timestamp UTC و شناسه Incident بسازید و اقدام مخرب را از جمعآوری شواهد جدا نگه دارید. Runbook باید مرحله تأیید هویت Session، اثر Rollback، تماس با مالک سرویس و معیار پایان Incident را روشن کند.
پرسش 10: sys.dm_exec_requests در کدام نسخههای SQL Server قابل استفاده است؟
جزئیات ستون، مجوز و Eventها با نسخه و Azure SQL تفاوت دارد؛ بنابراین metadata و مستندات همان نسخه باید مرجع نهایی باشد. برای مشاهده درخواستهای دیگران به مجوزهای مشاهده وضعیت سرور متناسب با نسخه نیاز است. در ارتقا، Queryها را روی محیط Stage اجرا کنید و بهویژه قابلیتهای Undocumented یا Deprecated را با جایگزین مستند عوض کنید.