مقدمه و جایگاه این DMV

sys.dm_os_workers یکی از DMVهای لایه SQL Server Operating System یا SQLOS است. برای هر Worker سیستم یک ردیف برمی‌گرداند و State، Wait اخیر، I/O، Context Switch و پیوند آن با Task و Thread را آشکار می‌کند. این نما برای تشخیص مبتنی بر شواهد طراحی شده و خروجی آن نباید به‌صورت جدا از بار کاری، زمان نمونه‌برداری و وضعیت سیستم‌عامل تفسیر شود.

در معماری اجرا، Request می‌تواند یک یا چند Task بسازد، Task به Worker متصل شود و Worker روی Scheduler و Thread اجرا گردد. جایگاه دقیق sys.dm_os_workers در این زنجیره تعیین می‌کند هر ستون چه چیزی را اندازه می‌گیرد و کدام نتیجه‌گیری از آن معتبر است.

DMVها معمولاً Snapshot جاری یا شمارنده تجمعی از زمان شروع سرویس هستند. بنابراین بهترین روش این است که زمان UTC، زمان شروع SQL Server و چند نمونه با فاصله ثابت جمع‌آوری شود. مقایسه Delta و هم‌بستگی با Waitها و Queryهای فعال از آستانه‌گذاری کورکورانه قابل‌اعتمادتر است.

بازگشت به راهنمای جامع DMVهای CPU و Scheduler در SQL Server

تعریف، Syntax و نوع خروجی

برای هر Worker سیستم یک ردیف برمی‌گرداند و State، Wait اخیر، I/O، Context Switch و پیوند آن با Task و Thread را آشکار می‌کند.

Worker موجودی اجرایی SQLOS است؛ Task واحد کار و Thread موجودی سطح سیستم‌عامل است که Worker روی آن اجرا می‌شود.

Syntax پایه

SELECT *
FROM sys.dm_os_workers;

پارامترها

sys.dm_os_workers تابع پارامتردار نیست و بدون آرگومان در بخش FROM استفاده می‌شود. محدودسازی باید با انتخاب ستون‌ها، WHERE، TOP و در صورت نیاز پیوند به DMVهای دیگر انجام شود.

نوع خروجی

خروجی یک مجموعه ردیف Read-only است. تعداد ردیف‌ها و مقادیر با وضعیت لحظه‌ای Instance تغییر می‌کند؛ آدرس‌های حافظه و Tickها فقط در عمر جاری سرویس معنا دارند و شناسه کسب‌وکاری دائمی نیستند.

ستون‌های کلیدی

روش تفسیر حرفه‌ای خروجی

ابتدا سؤال عملیاتی را دقیق تعریف کنید: آیا هدف تشخیص فشار CPU، کمبود Worker، انتظار I/O، توپولوژی NUMA، حافظه یا Inventory است؟ سپس فقط ستون‌هایی را انتخاب کنید که همان فرضیه را می‌سنجند. جمع‌آوری داده بدون سؤال مشخص، حجم زیاد و نتیجه مبهم تولید می‌کند.

در تحلیل sys.dm_os_workers باید مقدارهای حالت، شمارنده تجمعی و شناسه‌های پیوند از هم جدا شوند. State وضعیت همان لحظه است؛ Counter معمولاً برای Delta مناسب است؛ Address و ID مسیر اتصال به لایه مکمل را فراهم می‌کنند. ترکیب این سه نوع داده تصویر قابل دفاع‌تری می‌سازد.

Baseline باید ساعت اوج، ساعت عادی و دوره نگهداری را پوشش دهد. آستانه‌ای که در یک سرور هشت‌هسته‌ای هشدار است ممکن است در سرور دیگر طبیعی باشد. روند چند Snapshot و اثر روی SLA مهم‌تر از یک عدد عمومی در اینترنت است.

اصل تشخیصی: DMV علت قطعی را اعلام نمی‌کند؛ DMV شواهدی تولید می‌کند که باید با زمان، بار کاری و منابع مکمل هم‌بسته شود.

مثال‌های عملی و قابل اجرا

مثال 1: شمارش Workerها بر اساس State

این نمای پایه توزیع Workerهای RUNNING، RUNNABLE و SUSPENDED را نشان می‌دهد. شمار زیاد SUSPENDED ذاتاً خطا نیست، زیرا بسیاری از Workerها منتظر رخداد هستند؛ روند و نوع انتظار باید در کنار شمار تفسیر شود.

SELECT state, COUNT_BIG(*) AS worker_count
FROM sys.dm_os_workers
GROUP BY state
ORDER BY worker_count DESC;

وجود دو Worker در RUNNABLE تنها یک Snapshot است. برای تشخیص فشار CPU، مدت حضور در صف و Scheduler مربوط نیز بررسی می‌شود.

مثال 2: محاسبه مدت حضور Worker در صف Runnable

wait_resumed_ms_ticks لحظه ورود Worker به RUNNABLE را برحسب Tick سرویس نگه می‌دارد. با ms_ticks از sys.dm_os_sys_info می‌توان مدت تقریبی انتظار را محاسبه و Workerهای قدیمی‌تر را در اولویت بررسی قرار داد.

SELECT TOP (20) w.worker_address, w.state,
       si.ms_ticks - w.wait_resumed_ms_ticks AS runnable_ms,
       w.last_wait_type
FROM sys.dm_os_workers AS w
CROSS JOIN sys.dm_os_sys_info AS si
WHERE w.state = N'RUNNABLE'
  AND w.wait_resumed_ms_ticks > 0
ORDER BY runnable_ms DESC;

مدت بالا و تکرارشونده همراه با CPU زیاد می‌تواند نشانه رقابت پردازنده باشد. Tickها Timestamp تقویمی نیستند و فقط اختلاف آن‌ها باید استفاده شود.

مثال 3: محاسبه مدت تعلیق Worker

برای Workerهای SUSPENDED، wait_started_ms_ticks نقطه شروع انتظار را ثبت می‌کند. این کوئری Workerهای دارای انتظار طولانی را فهرست می‌کند تا سپس با task_address به درخواست یا Task مرتبط برسیم.

SELECT TOP (20) w.worker_address, w.last_wait_type,
       si.ms_ticks - w.wait_started_ms_ticks AS suspended_ms,
       w.task_address
FROM sys.dm_os_workers AS w
CROSS JOIN sys.dm_os_sys_info AS si
WHERE w.state = N'SUSPENDED'
  AND w.wait_started_ms_ticks > 0
ORDER BY suspended_ms DESC;

انتظار طولانی لزوماً بد نیست؛ Workerهای پس‌زمینه ممکن است عمداً مدت زیادی منتظر بمانند. session_id و command تعیین می‌کند انتظار مربوط به بار کاربر است یا وظیفه سیستمی.

مثال 4: یافتن Workerهای Preemptive

کدی که بیرون از کنترل زمان‌بندی Non-preemptive موتور اجرا می‌شود می‌تواند Worker را به حالت Preemptive ببرد. شمار و وضعیت این Workerها برای تحلیل فراخوانی‌های خارجی، Providerها یا عملیات سیستم‌عامل مفید است.

SELECT state, last_wait_type, COUNT_BIG(*) AS worker_count
FROM sys.dm_os_workers
WHERE is_preemptive = 1
GROUP BY state, last_wait_type
ORDER BY worker_count DESC;

یک Worker Preemptive طبیعی است. تمرکز باید بر انباشت، مدت و نوع انتظار باشد؛ نام Wait کمک می‌کند جزء خارجی یا عملیاتی که کنترل Scheduler را ترک کرده شناسایی شود.

مثال 5: بررسی I/O معلق Workerها

pending_io_count و pending_io_byte_count میزان I/O فیزیکی منتظر هر Worker را نشان می‌دهند. انتخاب Workerهای دارای مقدار مثبت، نقطه شروع مناسبی برای پیوند به Task و سپس فایل یا Request مرتبط است.

SELECT TOP (20) worker_address, state,
       pending_io_count, pending_io_byte_count,
       pending_io_byte_average, task_address
FROM sys.dm_os_workers
WHERE pending_io_count > 0
ORDER BY pending_io_byte_count DESC;

این شمارنده‌ها علت کندی دیسک را تعیین نمی‌کنند. خروجی باید با DMV درخواست‌های I/O، آمار فایل و Waitهای PAGEIOLATCH یا WRITELOG تطبیق داده شود.

مثال 6: کنترل پرچم‌های خطا و Spinlock

is_sick، is_fatal_exception و exception_num برای یافتن Workerهایی به کار می‌روند که وضعیت غیرعادی یا Exception داشته‌اند. این بررسی برای تشخیص پیشرفته است و هر مقدار غیرصفر باید با Error Log و Dump احتمالی تطبیق داده شود.

SELECT worker_address, state, is_sick,
       is_fatal_exception, is_inside_catch,
       exception_num, exception_severity
FROM sys.dm_os_workers
WHERE is_sick = 1
   OR is_fatal_exception = 1
   OR exception_num <> 0;

خروجی خالی حالت عادی است. در صورت مشاهده is_sick، تغییر تنظیمات بدون بررسی شواهد توصیه نمی‌شود و تحلیل عمیق‌تر توسط متخصص SQL Server ارزش دارد.

مثال 7: پیوند Worker به Request جاری

task_address کلید اتصال Worker به Task یا Request جاری است. نمونه زیر از الگوی مستند برای نمایش Session، Command، وضعیت Worker و زمان‌های Runnable و Suspended استفاده می‌کند.

SELECT r.session_id, r.command, r.status,
       w.state AS worker_state, w.last_wait_type,
       si.ms_ticks - NULLIF(w.wait_started_ms_ticks, 0) AS wait_ms
FROM sys.dm_exec_requests AS r
JOIN sys.dm_os_workers AS w
  ON w.task_address = r.task_address
CROSS JOIN sys.dm_os_sys_info AS si
WHERE r.scheduler_id IS NOT NULL;

اگر wait_started_ms_ticks صفر باشد عبارت NULL برمی‌گرداند و از نتیجه گمراه‌کننده جلوگیری می‌کند. در برنامه عملی باید دسترسی مشاهده Sessionهای دیگر نیز کنترل شود.

مثال 8: توزیع Workerها میان Schedulerها

scheduler_address امکان پیوند مستقیم Worker و Scheduler را فراهم می‌کند. این مثال تعداد کل، Workerهای Runnable و Workerهای Preemptive را برای هر Scheduler آنلاین محاسبه می‌کند.

SELECT s.scheduler_id, COUNT_BIG(*) AS workers,
       SUM(CASE WHEN w.state = N'RUNNABLE' THEN 1 ELSE 0 END) AS runnable,
       SUM(CONVERT(int, w.is_preemptive)) AS preemptive
FROM sys.dm_os_schedulers AS s
JOIN sys.dm_os_workers AS w
  ON w.scheduler_address = s.scheduler_address
WHERE s.status = N'VISIBLE ONLINE'
GROUP BY s.scheduler_id
ORDER BY runnable DESC, workers DESC;

تمرکز Workerهای Runnable روی یک Scheduler می‌تواند کوتاه‌مدت باشد. هم‌زمان parent_node_id، Affinity و بار درخواست‌ها را بررسی کنید تا نامتوازنی واقعی اثبات شود.

مثال 9: Workerهای پرتعویض Context

context_switch_count مقدار تجمعی تعویض Context هر Worker است. مرتب‌سازی این ستون Workerهای فعال‌تر را پیدا می‌کند، اما برای تحلیل بازه جاری بهتر است Delta دو Snapshot محاسبه شود.

SELECT TOP (20) worker_address, state,
       context_switch_count, tasks_processed_count,
       last_wait_type
FROM sys.dm_os_workers
ORDER BY context_switch_count DESC;

مقدار تجمعی بالا ممکن است فقط عمر طولانی Worker را نشان دهد. آن را با زمان ایجاد Worker و نمونه دوم مقایسه کنید و از آستانه ثابت برای همه سرورها استفاده نکنید.

مثال 10: نمونه‌برداری Delta کارهای پردازش‌شده

برای مشاهده فعالیت جدید، tasks_processed_count را در دو Snapshot ذخیره می‌کنیم. این نمونه Workerهایی را نشان می‌دهد که در فاصله کوتاه Task بیشتری پردازش کرده‌اند و حجم داده را با فیلتر Delta مثبت محدود می‌کند.

SELECT worker_address, tasks_processed_count
INTO #worker_before
FROM sys.dm_os_workers;

WAITFOR DELAY '00:00:01';

SELECT TOP (20) w.worker_address,
       w.tasks_processed_count - b.tasks_processed_count AS tasks_delta
FROM sys.dm_os_workers AS w
JOIN #worker_before AS b
  ON b.worker_address = w.worker_address
WHERE w.tasks_processed_count > b.tasks_processed_count
ORDER BY tasks_delta DESC;

DROP TABLE #worker_before;

آدرس Worker در طول عمر سرویس معنا دارد و پس از Restart قابل مقایسه با تاریخچه قبلی نیست. Collector باید زمان شروع SQL Server را نیز کنار Snapshot نگه دارد.

خطاهای رایج و راه اصلاح

نخستین خطا اجرای SELECT ستاره در Job پرتکرار است. این روش ستون‌های غیرضروری، داده داخلی و وابستگی نسخه‌ای را وارد تاریخچه می‌کند. Query هدفمند با ستون‌های محدود هم سبک‌تر است و هم گزارش بعدی را قابل نگهداری می‌کند.

خطای دوم تبدیل یک Snapshot به حکم قطعی است. صف Runnable یا پرچم فشار ممکن است گذرا باشد؛ از طرف دیگر مقدار صفر لحظه‌ای مشکل گذشته را رد نمی‌کند. نمونه‌برداری زمان‌دار و Alert رخدادمحور این شکاف را جبران می‌کند.

خطای سوم جمع‌زدن داده پس از Join یک‌به‌چند بدون توجه به تکرار است. Request موازی، چند Task یا چند Worker می‌تواند عدد CPU و Duration را چندبار تکرار کند. سطح Grain هر DMV و کلیدهای Join باید پیش از Aggregate نوشته شود.

خطای چهارم اجرای اسکریپت نسخه جدید روی نسخه قدیمی بدون کنترل ستون است. مجوزها، Platform و ستون‌های اطلاعاتی تغییر می‌کنند. اسکریپت سازمانی باید نسخه، EngineEdition و دسترسی لازم را ثبت و خطای واضح تولید کند.

ملاحظات Performance و امنیت

خواندن موردی sys.dm_os_workers با ستون‌های محدود معمولاً سبک است، اما هزینه به نرخ اجرا، تعداد ردیف، Joinها، مرتب‌سازی و تبدیل XML بستگی دارد. Collector ثانیه‌ای تنها وقتی توجیه دارد که داده همان تفکیک زمانی واقعاً برای تشخیص استفاده شود.

برای SQL Server و SQL Managed Instance معمولاً مجوزهای مشاهده وضعیت سرور مطرح هستند. در SQL Server 2022 و نسخه‌های جدیدتر، بسیاری از این نماها VIEW SERVER PERFORMANCE STATE می‌خواهند. اصل حداقل دسترسی و حفاظت از متن Query یا نام سرور باید رعایت شود.

تاریخچه را در پایگاه مانیتورینگ جداگانه، با Timestamp UTC، شناسه Instance و Retention مشخص نگه دارید. Index تاریخچه باید براساس Query گزارش ساخته شود؛ افزودن Index به خود DMV ممکن نیست و تلاش برای Hint یا تغییر داخلی روش درستی نیست.

• ستون‌های لازم را صریح نام ببرید.
• فیلتر را تا حد ممکن زود اعمال کنید.
• برای شمارنده تجمعی Delta بسازید.
• Uptime و Restart را ثبت کنید.
• در Incident شواهد مکمل را هم‌زمان بگیرید.
• روی Production از Query آزمایش‌نشده و XML سنگین دوری کنید.

بهترین روش‌ها و کاربرد سازمانی

sys.dm_os_workers زمانی بیشترین ارزش را دارد که در Runbook مشخص جای بگیرد: Trigger چه چیزی است، Query چه زمانی اجرا می‌شود، چه ستون‌هایی ثبت می‌شوند و مسئول تفسیر کیست. این نظم داده خام را به تصمیم عملیاتی تبدیل می‌کند.

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

در پروژه مشاوره یا بهینه‌سازی، Snapshot باید با Query Store، Wait Statistics، Extended Events، Performance Counter و شاخص‌های سیستم‌عامل هم‌بسته شود. هیچ ابزار واحدی همه لایه‌ها را پوشش نمی‌دهد.

1. فرضیه و بازه زمانی را مشخص کنید.
2. نسخه و مجوز را کنترل کنید.
3. Query کم‌حجم را در آزمایش اجرا کنید.
4. Timestamp و Uptime را ذخیره کنید.
5. حداقل دو Snapshot قابل مقایسه بگیرید.
6. داده را با DMV مکمل Join کنید.
7. تکرار یک‌به‌چند را کنترل کنید.
8. نتیجه را با SLA و تجربه کاربر مرتبط کنید.

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

sys.dm_os_workers دقیقاً چه چیزی را نشان می‌دهد؟

sys.dm_os_workers برای هر Worker سیستم یک ردیف برمی‌گرداند و State، Wait اخیر، I/O، Context Switch و پیوند آن با Task و Thread را آشکار می‌کند. خروجی یک Snapshot زنده است و برای نتیجه‌گیری باید با زمان Capture، Uptime و DMVهای مکمل تفسیر شود.

چطور نخستین گزارش آموزشی از sys.dm_os_workers بسازیم؟

از انتخاب ستون‌های کلیدی، فیلتر Session یا وضعیت مرتبط و ثبت Timestamp UTC شروع کنید. سپس نتیجه نمونه را با Baseline محیط سالم مقایسه کنید و معنی هر ستون را پیش از تعریف Alert مستند سازید.

آیا داده sys.dm_os_workers برای تصمیم خرید CPU یا حافظه کافی است؟

خیر. تصمیم تجاری خرید سخت‌افزار به روند بلندمدت، SLA، رشد بار، Waitها و داده سیستم‌عامل نیاز دارد. این DMV یکی از شواهد است و مشاوره ظرفیت‌سنجی می‌تواند از هزینه خرید اشتباه جلوگیری کند.

چگونه پایش sys.dm_os_workers هزینه عملیاتی را کاهش می‌دهد؟

Collector کم‌حجم می‌تواند نشانه‌های فشار را پیش از Incident ثبت کند و زمان عیب‌یابی را کاهش دهد. ارزش اقتصادی زمانی ایجاد می‌شود که داده با Runbook، Alert قابل اقدام و مسئول مشخص همراه باشد.

تفاوت sys.dm_os_workers با DMV مکمل آن چیست؟

Worker موجودی اجرایی SQLOS است؛ Task واحد کار و Thread موجودی سطح سیستم‌عامل است که Worker روی آن اجرا می‌شود. ترکیب لایه‌ها مانع می‌شود یک شمارنده منفرد به علت قطعی تبدیل شود.

چه زمانی برای تحلیل sys.dm_os_workers از خدمات تخصصی استفاده کنیم؟

وقتی مشکل گذرا، چندلایه یا Production است و تیم نمی‌تواند Snapshot را دوباره تولید کند، طراحی Session جمع‌آوری شواهد و تحلیل حرفه‌ای مفید است. آموزش هدفمند نیز به تیم کمک می‌کند Queryها را ایمن و تکرارپذیر اجرا کند.

رایج‌ترین خطا هنگام خواندن sys.dm_os_workers چیست؟

رایج‌ترین خطا تفسیر مقدار لحظه‌ای یا تجمعی بدون Baseline و بدون توجه به Restart است. خطای دیگر استفاده از SELECT ستاره در Collector پرتکرار و فرض ثبات همه ستون‌های داخلی در نسخه‌های مختلف است.

اجرای sys.dm_os_workers چه اثر Performance دارد؟

یک SELECT محدود و موردی معمولاً سبک است، اما Polling بسیار پرتکرار، پردازش XML یا ذخیره همه ستون‌ها هزینه ایجاد می‌کند. ستون‌های لازم، TOP، فیلتر زودهنگام و تناوب متناسب با هدف را انتخاب کنید.

Best Practice ذخیره تاریخچه sys.dm_os_workers چیست؟

Timestamp UTC، sqlserver_start_time، شناسه Instance و فقط شاخص‌های لازم را ذخیره کنید. جدول تاریخچه باید Retention، Index متناسب با Query گزارش و جداسازی دسترسی امنیتی داشته باشد.

sys.dm_os_workers در کدام نسخه‌های SQL Server قابل استفاده است؟

این DMV در نسخه‌های پشتیبان SQL Server ارائه می‌شود، اما ستون‌ها و مجوزها می‌توانند با نسخه و Platform فرق کنند. در SQL Server 2022 و جدیدتر برای بسیاری از DMVهای Performance مجوز VIEW SERVER PERFORMANCE STATE لازم است؛ اسکریپت چندنسخه‌ای باید این تفاوت را کنترل کند.

سؤالات مصاحبه SQL Server

چرا یک Snapshot از sys.dm_os_workers برای تشخیص قطعی کافی نیست؟

زیرا State می‌تواند گذرا و Counter تجمعی باشد. پاسخ حرفه‌ای باید به Baseline، Delta، Uptime و هم‌بستگی با شواهد مکمل اشاره کند.

تفاوت Task، Worker، Scheduler و Thread چیست؟

Task واحد کار، Worker مجری SQLOS، Scheduler هماهنگ‌کننده اجرای Cooperative و Thread موجودی سیستم‌عامل است. یک Request موازی می‌تواند چند Task و Worker داشته باشد.

چرا Timestamp UTC و زمان شروع سرویس ثبت می‌شوند؟

UTC مقایسه بین سرورها را پایدار می‌کند و زمان شروع سرویس Reset شمارنده‌های تجمعی را آشکار می‌سازد.

چگونه هزینه Collector را کاهش می‌دهید؟

ستون‌های محدود، Filter زودهنگام، Interval متناسب، حذف Sort غیرضروری و Retention روشن انتخاب می‌شوند. Query در بار مشابه Production آزمایش می‌شود.

مجوز مناسب در SQL Server 2022 چیست؟

برای بسیاری از DMVهای Performance مجوز VIEW SERVER PERFORMANCE STATE لازم است. پاسخ دقیق باید نسخه، Platform و اصل حداقل دسترسی را نیز در نظر بگیرد.

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

• هدف Query مربوط به sys.dm_os_workers روشن است.
• نسخه و وجود ستون‌های استفاده‌شده بررسی شده است.
• مجوز با اصل حداقل دسترسی واگذار شده است.
• SELECT ستاره در Collector استفاده نشده است.
• Timestamp UTC و Uptime ثبت می‌شوند.
• مقدار تجمعی با Delta تحلیل می‌شود.
• Snapshot منفرد به علت قطعی تبدیل نمی‌شود.
• Join یک‌به‌چند از نظر Double Count کنترل شده است.
• Retention و امنیت جدول تاریخچه مشخص است.
• نتیجه با DMVها و شواهد مکمل تطبیق داده می‌شود.

جمع‌بندی

sys.dm_os_workers ابزار ارزشمندی برای تحلیل Workerهای SQL Server است، به شرط آنکه خروجی آن در Context معماری SQLOS، نسخه SQL Server و زمان نمونه‌برداری خوانده شود. مثال‌های این مقاله از Query پایه تا Snapshot و پیوند چند DMV را پوشش دادند تا مسیر تشخیص قابل تکرار باشد.

برای مشاهده ارتباط این DMV با هشت نمای دیگر، راهنمای جامع CPU، Scheduler، Worker، Task و منابع SQLOS را مطالعه کنید.