مثالهای عملی
مثال 1: فهرست نشستهای کاربری
در این سناریو هدف، تهیه موجودی پایه از Sessionهای کاربر و مبدأ اتصال است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id, login_name, status, host_name, program_name
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
ORDER BY session_id;
| خروجی نمونه | تفسیر |
|---|
| 57 | app_user | sleeping | WEB-02 | OrderApi | نتیجه نمایشی مثال 1؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
Connection Pool میتواند تعداد زیادی Session Sleeping سالم ایجاد کند؛ الگو را با Baseline مقایسه کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 2: گروهبندی اتصالها بر اساس برنامه
در این سناریو هدف، تشخیص Applicationی است که بیشترین Connection را باز کرده است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
COALESCE(program_name, N'(unknown)') AS program_name,
COUNT_BIG(*) AS session_count
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
GROUP BY program_name
ORDER BY session_count DESC;
| خروجی نمونه | تفسیر |
|---|
| OrderApi | 84 | نتیجه نمایشی مثال 2؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
نام برنامه توسط Client ارسال میشود و کنترل امنیتی نیست؛ برای انتساب قطعی از Login و شبکه نیز کمک بگیرید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 3: یافتن نشست خواب با تراکنش باز
در این سناریو هدف، یافتن یکی از مهمترین الگوهای Head Blocker پنهان است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id,
login_name,
status,
open_transaction_count,
last_request_end_time
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
AND status = N'sleeping'
AND open_transaction_count > 0;
| خروجی نمونه | تفسیر |
|---|
| 57 | app_user | sleeping | 1 | 2026-07-22 05:11 | نتیجه نمایشی مثال 3؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
ابتدا Input Buffer، مالک برنامه و سن تراکنش را بررسی کنید؛ Sleeping بودن به تنهایی دستور KILL نیست. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 4: رتبهبندی مصرف تجمعی Session
در این سناریو هدف، بررسی مصرف تجمعی در طول عمر Session است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT TOP (20)
session_id,
login_name,
cpu_time,
memory_usage,
reads,
writes,
logical_reads
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
ORDER BY cpu_time DESC;
| خروجی نمونه | تفسیر |
|---|
| 63 | report_user | 94520 | 48 | 1200 | 82 | 4500200 | نتیجه نمایشی مثال 4؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
برای Connectionهای بسیار قدیمی اعداد بزرگ طبیعیاند؛ نرخ تغییر و Request جاری را هم بسنجید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 5: اتصال Session به Connection
در این سناریو هدف، افزودن IP، نوع Transport و وضعیت Encryption به تحلیل Session است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
s.session_id,
s.login_name,
c.client_net_address,
c.net_transport,
c.encrypt_option,
c.connect_time
FROM sys.dm_exec_sessions AS s
JOIN sys.dm_exec_connections AS c
ON c.session_id = s.session_id
WHERE s.is_user_process = 1;
| خروجی نمونه | تفسیر |
|---|
| 57 | app_user | 10.20.4.18 | TCP | TRUE | 2026-07-22 04:58 | نتیجه نمایشی مثال 5؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
در اتصال محلی یا برخی معماریها client_net_address میتواند NULL باشد؛ NULL را جعل نکنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 6: بررسی هویت اصلی و جاری
در این سناریو هدف، تشخیص تغییر Context با EXECUTE AS یا لایه واسط است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id,
login_name,
original_login_name,
nt_user_name,
security_id
FROM sys.dm_exec_sessions
WHERE is_user_process = 1;
| خروجی نمونه | تفسیر |
|---|
| 57 | proxy_login | app_login | NULL | 0x01... | نتیجه نمایشی مثال 6؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
original_login_name برای ممیزی مفید است ولی جای Audit و Correlation ID برنامه را نمیگیرد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 7: نشستهای بدون درخواست اخیر
در این سناریو هدف، ساخت گزارش Idle با آستانه قابل تنظیم است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
DECLARE @IdleMinutes int = 30;
SELECT
session_id,
login_name,
status,
last_request_end_time,
DATEDIFF(minute, last_request_end_time, SYSDATETIME()) AS idle_minutes
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
AND status = N'sleeping'
AND last_request_end_time < DATEADD(minute, -@IdleMinutes, SYSDATETIME());
| خروجی نمونه | تفسیر |
|---|
| 71 | batch_user | sleeping | 2026-07-22 04:01 | 89 | نتیجه نمایشی مثال 7؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
قبل از پاکسازی Sessionهای Idle، تنظیمات Pool و open_transaction_count را بررسی کنید. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 8: توزیع نشستها بر اساس Login و Host
در این سناریو هدف، کشف جهش Connection برای یک هویت و میزبان خاص است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
login_name,
COALESCE(host_name, N'(unknown)') AS host_name,
COUNT_BIG(*) AS session_count
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
GROUP BY login_name, host_name
HAVING COUNT_BIG(*) >= 5
ORDER BY session_count DESC;
| خروجی نمونه | تفسیر |
|---|
| app_user | WEB-02 | 42 | نتیجه نمایشی مثال 8؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
HAVING حجم گروههای کوچک را حذف میکند و هشدار را به الگوی غیرعادی متمرکز میسازد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 9: مدیریت مقادیر NULL مشخصات Client
در این سناریو هدف، نمایش صادقانه فیلدهایی است که Client ممکن است ارسال نکرده باشد. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
session_id,
COALESCE(host_name, N'(host not supplied)') AS host_name,
COALESCE(program_name, N'(program not supplied)') AS program_name,
COALESCE(client_interface_name, N'(interface unknown)') AS client_interface
FROM sys.dm_exec_sessions
WHERE is_user_process = 1;
| خروجی نمونه | تفسیر |
|---|
| 57 | WEB-02 | OrderApi | .Net SqlClient Data Provider | نتیجه نمایشی مثال 9؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
جایگزین نمایشی باید نامشخص بودن را حفظ کند و نباید مقدار ساختگی قابل اتکا در ممیزی بسازد. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
مثال 10: تفکیک Session و Request فعال
در این سناریو هدف، نشان دادن تفاوت عمر Session با فعالیت لحظهای Request است. Query زیر یک نمونه مستقل و قابل اجرا برای محیط مناسب ارائه میکند؛ فرمانهای تغییردهنده باید ابتدا در Lab و با مجوز کنترلشده آزموده شوند.
SELECT
s.session_id,
s.status AS session_status,
r.status AS request_status,
r.command,
r.wait_type
FROM sys.dm_exec_sessions AS s
LEFT JOIN sys.dm_exec_requests AS r
ON r.session_id = s.session_id
WHERE s.is_user_process = 1
AND s.session_id <> @@SPID;
| خروجی نمونه | تفسیر |
|---|
| 57 | sleeping | NULL | NULL | NULL | نتیجه نمایشی مثال 10؛ مقدار واقعی به بارکاری و نسخه سرور وابسته است. |
NULL بودن ستونهای Request برای Session خواب طبیعی است و نباید به خطای مانیتورینگ تعبیر شود. این نتیجه نمونه کمک میکند پیش از اجرا شکل خروجی را بشناسید، اما جای مشاهده داده واقعی همان Incident را نمیگیرد.
سؤالات متداول
پرسش 1: sys.dm_exec_sessions دقیقاً چه مسئلهای را در SQL Server حل میکند؟
نمای sys.dm_exec_sessions اطلاعات سطح Session مانند نام ورود، میزبان، برنامه، وضعیت، زمان آخرین درخواست، مصرف تجمعی CPU و تعداد تراکنش باز را نگه میدارد. ارزش اصلی آن زمانی آشکار میشود که سؤال عملیاتی مشخص باشد؛ مثلاً شناسایی Head Blocker، تعیین منبع انتظار یا حفظ شواهد Deadlock. خروجی باید کنار زمان رخداد و مشخصات Application نگهداری شود تا از یک Snapshot خام به پاسخ قابل اقدام برسیم.
پرسش 2: برای شروع کار با sys.dm_exec_sessions چه پیشنیازی لازم است؟
ابتدا در محیط آزمایش Syntax و ستونهای نسخه نصبشده را بررسی کنید، سپس مجوز حداقلی مشاهده وضعیت را در نظر بگیرید. مشاهده نشست خود محدودیت کمتری دارد؛ دیدن همه نشستها به مجوز مشاهده وضعیت سرور نیاز دارد. اجرای Query با حساب Production پرقدرت راهحل مناسبی نیست و بهتر است نقش مانیتورینگ مشخص و ممیزیشده ساخته شود.
پرسش 3: استفاده از sys.dm_exec_sessions چه ارزش تجاری برای سامانه پرتراکنش دارد؟
کاهش زمان تشخیص Incident، جلوگیری از تصمیم عجولانه و کوتاهشدن اختلال مستقیمترین ارزشها هستند. وقتی داده این ابزار با SLA و مالک سرویس پیوند بخورد، تیم میتواند بین کندی عادی، Blocking زیانآور و Deadlock تکرارشونده تفاوت بگذارد و هزینه توقف را کم کند.
پرسش 4: چه زمانی برای پیادهسازی مانیتورینگ sys.dm_exec_sessions به مشاوره تخصصی نیاز داریم؟
اگر رخدادها تکراری، چندپایگاهدادهای، حساس به امنیت یا دارای حجم Event بالا هستند، طراحی Baseline، Retention و Runbook تخصصی مفید است. مشاوره SQL Server باید در کنار جمعآوری داده، Query Plan، تراکنش، ایندکس و رفتار کد Application را نیز بررسی کند؛ خرید ابزار بدون فرایند پاسخگویی کافی نیست.
پرسش 5: تفاوت sys.dm_exec_sessions با ابزار نزدیک آن چیست؟
یک نشست میتواند در طول عمر خود چند Request متوالی داشته باشد؛ به همین دلیل دادههای تجمعی این DMV با اندازهگیری لحظهای dm_exec_requests یکسان نیست. انتخاب درست به این بستگی دارد که داده لحظهای، تاریخچه XML، مشخصات Session یا امکان اقدام مدیریتی لازم باشد. در عیبیابی حرفهای معمولاً چند منبع مکمل کنار هم استفاده میشوند، نه اینکه یک خروجی به تنهایی حقیقت کامل فرض شود.
پرسش 6: آیا میتوان پیادهسازی داشبورد یا پروژه sys.dm_exec_sessions را به تیم متخصص سپرد؟
بله؛ تحویل حرفهای باید شامل تعریف نیاز، Queryهای کمهزینه، کنترل مجوز، ذخیره UTC، سیاست Retention، هشدار قابل تنظیم، داشبورد و Runbook اعتبارسنجیشده باشد. پیش از پذیرش پروژه، اثر مانیتورینگ روی Production و روش تست خطا نیز باید مستند شود.
پرسش 7: رایجترین خطا هنگام تحلیل sys.dm_exec_sessions چیست؟
Sleeping بودن بهتنهایی دلیل امنی برای KILL نیست؛ نشست خواب ممکن است تراکنش باز داشته یا متعلق به Connection Pool باشد. خطای دوم تصمیمگیری از روی یک Snapshot بدون Baseline است. زمان رخداد، Login، Host، Database، Transaction و Query متناظر را کنار هم قرار دهید و هر مقدار NULL یا نامشخص را صادقانه حفظ کنید.
پرسش 8: آیا Query گرفتن از sys.dm_exec_sessions روی Performance اثر میگذارد؟
برای داشبوردها روی is_user_process و session_id فیلتر کنید و گروهبندی را با دوره نمونهبرداری معقول انجام دهید. خود مشاهده نیز رایگان نیست، بهویژه وقتی XML، Plan یا Text برای تعداد زیادی Session استخراج شود. Period نمونهبرداری، فیلتر، سقف نگهداری و مانیتور Dropped Event باید بخشی از طراحی باشد.
پرسش 9: بهترین روش استفاده Production از sys.dm_exec_sessions چیست؟
پرسش عملیاتی را از قبل تعریف کنید، کمترین ستون و Scope لازم را جمع کنید، Timestamp UTC و شناسه Incident بسازید و اقدام مخرب را از جمعآوری شواهد جدا نگه دارید. Runbook باید مرحله تأیید هویت Session، اثر Rollback، تماس با مالک سرویس و معیار پایان Incident را روشن کند.
پرسش 10: sys.dm_exec_sessions در کدام نسخههای SQL Server قابل استفاده است؟
جزئیات ستون، مجوز و Eventها با نسخه و Azure SQL تفاوت دارد؛ بنابراین metadata و مستندات همان نسخه باید مرجع نهایی باشد. مشاهده نشست خود محدودیت کمتری دارد؛ دیدن همه نشستها به مجوز مشاهده وضعیت سرور نیاز دارد. در ارتقا، Queryها را روی محیط Stage اجرا کنید و بهویژه قابلیتهای Undocumented یا Deprecated را با جایگزین مستند عوض کنید.