مثالهای عملی و قابل اجرا
مثال 1: توزیع Taskها بر اساس State
Task واحد کاری SQLOS است و میتواند PENDING، RUNNABLE، RUNNING، SUSPENDED یا DONE باشد. شمارش وضعیتها یک نمای سریع از ترکیب بار جاری فراهم میکند، ولی باید Taskهای سیستمی و کاربری از هم تفکیک شوند.
SELECT task_state, COUNT_BIG(*) AS task_count
FROM sys.dm_os_tasks
GROUP BY task_state
ORDER BY task_count DESC;
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 1 | SUSPENDED=96، RUNNABLE=3، RUNNING=8 | SUSPENDED معمولاً به معنی انتظار برای یک منبع یا رخداد است. برای یافتن علت، Task را با Worker، Request و اطلاعات Wait پیوند دهید. |
SUSPENDED معمولاً به معنی انتظار برای یک منبع یا رخداد است. برای یافتن علت، Task را با Worker، Request و اطلاعات Wait پیوند دهید.
مثال 2: نمایش Taskهای Sessionهای کاربری
فیلتر session_id بزرگتر از ۵۰ یک تقریب رایج برای تمرکز روی Sessionهای کاربر در SQL Server است. این کوئری Task، Request، Execution Context و Scheduler را کنار هم میآورد.
SELECT session_id, request_id, exec_context_id,
task_state, scheduler_id, worker_address
FROM sys.dm_os_tasks
WHERE session_id > 50
ORDER BY session_id, request_id, exec_context_id;
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 2 | Session 68؛ Request 0؛ Context 2؛ RUNNABLE | در Query موازی ممکن است برای یک Request چند Execution Context و چند Task دیده شود. بنابراین شمار ردیفها را معادل شمار Sessionها نگیرید. |
در Query موازی ممکن است برای یک Request چند Execution Context و چند Task دیده شود. بنابراین شمار ردیفها را معادل شمار Sessionها نگیرید.
مثال 3: پیوند Task با Request فعال
ترکیب session_id و request_id اجازه میدهد وضعیت Taskهای یک Request با Command، Status و Wait درخواست مقایسه شود. این پیوند برای رسیدن از لایه SQLOS به لایه اجرای کوئری کاربردی است.
SELECT t.session_id, t.request_id, t.exec_context_id,
t.task_state, r.command, r.status,
r.wait_type, r.cpu_time
FROM sys.dm_os_tasks AS t
JOIN sys.dm_exec_requests AS r
ON r.session_id = t.session_id
AND r.request_id = t.request_id
WHERE t.session_id > 50
ORDER BY r.cpu_time DESC, t.exec_context_id;
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 3 | Session 73؛ SELECT؛ Task RUNNING؛ CPU=1210ms | یک Request موازی چند ردیف ایجاد میکند و cpu_time درخواست در هر ردیف تکرار میشود. برای جمعزدن CPU ابتدا Requestها را یکتا کنید تا Double Count رخ ندهد. |
یک Request موازی چند ردیف ایجاد میکند و cpu_time درخواست در هر ردیف تکرار میشود. برای جمعزدن CPU ابتدا Requestها را یکتا کنید تا Double Count رخ ندهد.
مثال 4: یافتن Taskهای Runnable
Taskهای RUNNABLE کار لازم برای اجرا دارند اما در صف Scheduler منتظر CPU هستند. کوئری زیر آنها را با Scheduler و شناسه Session مرتب میکند تا فشار پردازنده به بار مشخص نسبت داده شود.
SELECT scheduler_id, session_id, request_id,
exec_context_id, context_switches_count
FROM sys.dm_os_tasks
WHERE task_state = N'RUNNABLE'
ORDER BY scheduler_id, context_switches_count DESC;
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 4 | Scheduler 4؛ Session 91؛ Context 1 | یک نتیجه منفرد طبیعی است. تداوم ردیفها، runnable_tasks_count Scheduler و مصرف CPU باید همزمان بررسی شود. |
یک نتیجه منفرد طبیعی است. تداوم ردیفها، runnable_tasks_count Scheduler و مصرف CPU باید همزمان بررسی شود.
مثال 5: مرور I/O معلق Taskها
pending_io_count و pending_io_byte_count میزان I/O فیزیکی منتظر در سطح Task را نمایش میدهند. فیلتر مقدار مثبت، Taskهایی را جدا میکند که در لحظه Snapshot کار I/O تکمیلنشده دارند.
SELECT TOP (20) session_id, request_id, task_state,
pending_io_count, pending_io_byte_count,
pending_io_byte_average
FROM sys.dm_os_tasks
WHERE pending_io_count > 0
ORDER BY pending_io_byte_count DESC;
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 5 | Session 62؛ pending I/O=2؛ bytes=131072 | برای یافتن فایل و نوع عملیات، این خروجی باید با Request و DMVهای I/O تکمیل شود. مقدار صفر نیز نبودن مشکل ذخیرهساز را در کل بازه ثابت نمیکند. |
برای یافتن فایل و نوع عملیات، این خروجی باید با Request و DMVهای I/O تکمیل شود. مقدار صفر نیز نبودن مشکل ذخیرهساز را در کل بازه ثابت نمیکند.
مثال 6: تشخیص Parallelism در سطح Request
وجود چند exec_context_id برای یک session_id و request_id معمولاً به اجرای موازی مربوط است. این گزارش Requestهایی را نشان میدهد که بیش از یک Task فعال دارند و تعداد Contextها را ثبت میکند.
SELECT session_id, request_id,
COUNT_BIG(*) AS task_count,
COUNT(DISTINCT exec_context_id) AS execution_contexts
FROM sys.dm_os_tasks
WHERE session_id > 50
AND task_state <> N'DONE'
GROUP BY session_id, request_id
HAVING COUNT_BIG(*) > 1
ORDER BY task_count DESC;
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 6 | Session 88؛ Request 0؛ 8 Context | هشت Context الزاماً مشکل نیست و میتواند با DOP مجاز سازگار باشد. Waitهای CXPACKET یا CXCONSUMER، مدت اجرا و پلن واقعی تعیین میکنند Parallelism مفید است یا پرهزینه. |
هشت Context الزاماً مشکل نیست و میتواند با DOP مجاز سازگار باشد. Waitهای CXPACKET یا CXCONSUMER، مدت اجرا و پلن واقعی تعیین میکنند Parallelism مفید است یا پرهزینه.
مثال 7: توزیع Taskها روی Schedulerها
این تجمیع تعداد Taskهای فعال، Runnable و Suspended را برای هر scheduler_id محاسبه میکند. هدف، یافتن تمرکز نامتعارف بار و مقایسه آن با NUMA و Affinity است.
SELECT scheduler_id,
COUNT_BIG(*) AS active_tasks,
SUM(CASE WHEN task_state = N'RUNNABLE' THEN 1 ELSE 0 END) AS runnable,
SUM(CASE WHEN task_state = N'SUSPENDED' THEN 1 ELSE 0 END) AS suspended
FROM sys.dm_os_tasks
WHERE task_state <> N'DONE'
GROUP BY scheduler_id
ORDER BY runnable DESC, active_tasks DESC;
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 7 | Scheduler 3؛ active=22؛ runnable=6 | اگر تمرکز در چند Snapshot تکرار شود، Scheduler و Node مربوط را بررسی کنید. Snapshot واحد ممکن است صرفاً همزمانی کوتاه چند Query باشد. |
اگر تمرکز در چند Snapshot تکرار شود، Scheduler و Node مربوط را بررسی کنید. Snapshot واحد ممکن است صرفاً همزمانی کوتاه چند Query باشد.
مثال 8: Taskهای دارای Context Switch زیاد
context_switches_count در سطح Task نشان میدهد چند بار Context عوض شده است. فهرست بالاترین مقادیر برای یافتن Taskهای طولانی یا پررفتوآمد مفید است، ولی مقدار تجمعی با سن Task ارتباط دارد.
SELECT TOP (20) session_id, request_id,
exec_context_id, task_state,
context_switches_count, scheduler_id
FROM sys.dm_os_tasks
WHERE session_id > 50
ORDER BY context_switches_count DESC;
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 8 | Session 77؛ Context switches=4320 | برای تصمیم Performance، زمان اجرا، Wait و مقدار کار انجامشده را نیز بسنجید. Context Switch زیاد بدون Baseline بهتنهایی نشانه خرابی نیست. |
برای تصمیم Performance، زمان اجرا، Wait و مقدار کار انجامشده را نیز بسنجید. Context Switch زیاد بدون Baseline بهتنهایی نشانه خرابی نیست.
مثال 9: جدا کردن Taskهای پسزمینه
Taskهای دارای session_id تهی یا Sessionهای سیستمی برای فعالیتهای داخلی موتور استفاده میشوند. این گزارش آنها را بر اساس State و Scheduler خلاصه میکند تا با بار کاربر اشتباه نشوند.
SELECT scheduler_id, task_state,
COUNT_BIG(*) AS background_tasks
FROM sys.dm_os_tasks
WHERE session_id IS NULL OR session_id <= 50
GROUP BY scheduler_id, task_state
ORDER BY scheduler_id, task_state;
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 9 | Scheduler 0؛ SUSPENDED=7 Task سیستمی | Taskهای پسزمینه مانند مانیتورها و Writerها طبیعیاند. حذف کورکورانه Sessionهای سیستمی یا تفسیر آنها بهعنوان Query کاربر خطای تشخیصی مهمی است. |
Taskهای پسزمینه مانند مانیتورها و Writerها طبیعیاند. حذف کورکورانه Sessionهای سیستمی یا تفسیر آنها بهعنوان Query کاربر خطای تشخیصی مهمی است.
مثال 10: Snapshot کمحجم برای Collector
ذخیره SELECT ستاره برای هر Task در هر ثانیه سریعاً داده زیادی تولید میکند. این نمونه فقط کلیدهای ارتباطی و State را برای Sessionهای کاربری انتخاب میکند و Timestamp UTC را نیز کنار Snapshot میگذارد.
SELECT SYSUTCDATETIME() AS captured_at_utc,
session_id, request_id, exec_context_id,
scheduler_id, task_state,
context_switches_count
FROM sys.dm_os_tasks
WHERE session_id > 50
AND task_state <> N'DONE';
| خروجی نمونه | مقدار نمایشی | برداشت سریع |
|---|
| مثال 10 | Capture UTC؛ Session 64؛ Task SUSPENDED | برای تاریخچه واقعی یک جدول مقصد با سیاست نگهداری تعریف کنید. UTC مقایسه میان سرورها و تغییرات ساعت محلی را سادهتر میکند و ستونهای محدود هزینه Collector را پایین میآورند. |
برای تاریخچه واقعی یک جدول مقصد با سیاست نگهداری تعریف کنید. UTC مقایسه میان سرورها و تغییرات ساعت محلی را سادهتر میکند و ستونهای محدود هزینه Collector را پایین میآورند.
سؤالات متداول
sys.dm_os_tasks دقیقاً چه چیزی را نشان میدهد؟
sys.dm_os_tasks برای هر Task فعال یا داخلی یک ردیف فراهم میکند و State، Scheduler، Session، Request، Execution Context و I/O منتظر را نشان میدهد. خروجی یک Snapshot زنده است و برای نتیجهگیری باید با زمان Capture، Uptime و DMVهای مکمل تفسیر شود.
چطور نخستین گزارش آموزشی از sys.dm_os_tasks بسازیم؟
از انتخاب ستونهای کلیدی، فیلتر Session یا وضعیت مرتبط و ثبت Timestamp UTC شروع کنید. سپس نتیجه نمونه را با Baseline محیط سالم مقایسه کنید و معنی هر ستون را پیش از تعریف Alert مستند سازید.
آیا داده sys.dm_os_tasks برای تصمیم خرید CPU یا حافظه کافی است؟
خیر. تصمیم تجاری خرید سختافزار به روند بلندمدت، SLA، رشد بار، Waitها و داده سیستمعامل نیاز دارد. این DMV یکی از شواهد است و مشاوره ظرفیتسنجی میتواند از هزینه خرید اشتباه جلوگیری کند.
چگونه پایش sys.dm_os_tasks هزینه عملیاتی را کاهش میدهد؟
Collector کمحجم میتواند نشانههای فشار را پیش از Incident ثبت کند و زمان عیبیابی را کاهش دهد. ارزش اقتصادی زمانی ایجاد میشود که داده با Runbook، Alert قابل اقدام و مسئول مشخص همراه باشد.
تفاوت sys.dm_os_tasks با DMV مکمل آن چیست؟
Task واحد زمانبندیشونده کار است؛ یک Request موازی میتواند چند Task و Execution Context داشته باشد. ترکیب لایهها مانع میشود یک شمارنده منفرد به علت قطعی تبدیل شود.
چه زمانی برای تحلیل sys.dm_os_tasks از خدمات تخصصی استفاده کنیم؟
وقتی مشکل گذرا، چندلایه یا Production است و تیم نمیتواند Snapshot را دوباره تولید کند، طراحی Session جمعآوری شواهد و تحلیل حرفهای مفید است. آموزش هدفمند نیز به تیم کمک میکند Queryها را ایمن و تکرارپذیر اجرا کند.
رایجترین خطا هنگام خواندن sys.dm_os_tasks چیست؟
رایجترین خطا تفسیر مقدار لحظهای یا تجمعی بدون Baseline و بدون توجه به Restart است. خطای دیگر استفاده از SELECT ستاره در Collector پرتکرار و فرض ثبات همه ستونهای داخلی در نسخههای مختلف است.
اجرای sys.dm_os_tasks چه اثر Performance دارد؟
یک SELECT محدود و موردی معمولاً سبک است، اما Polling بسیار پرتکرار، پردازش XML یا ذخیره همه ستونها هزینه ایجاد میکند. ستونهای لازم، TOP، فیلتر زودهنگام و تناوب متناسب با هدف را انتخاب کنید.
Best Practice ذخیره تاریخچه sys.dm_os_tasks چیست؟
Timestamp UTC، sqlserver_start_time، شناسه Instance و فقط شاخصهای لازم را ذخیره کنید. جدول تاریخچه باید Retention، Index متناسب با Query گزارش و جداسازی دسترسی امنیتی داشته باشد.
sys.dm_os_tasks در کدام نسخههای SQL Server قابل استفاده است؟
این DMV در نسخههای پشتیبان SQL Server ارائه میشود، اما ستونها و مجوزها میتوانند با نسخه و Platform فرق کنند. در SQL Server 2022 و جدیدتر برای بسیاری از DMVهای Performance مجوز VIEW SERVER PERFORMANCE STATE لازم است؛ اسکریپت چندنسخهای باید این تفاوت را کنترل کند.