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

sys.dm_os_threads یکی از DMVهای لایه SQL Server Operating System یا SQLOS است. اطلاعات Threadهای سیستم‌عامل مرتبط با SQL Server، از جمله OS Thread ID، زمان CPU، Stack، Affinity و Processor Group را ارائه می‌کند. این نما برای تشخیص مبتنی بر شواهد طراحی شده و خروجی آن نباید به‌صورت جدا از بار کاری، زمان نمونه‌برداری و وضعیت سیستم‌عامل تفسیر شود.

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

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

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

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

اطلاعات Threadهای سیستم‌عامل مرتبط با SQL Server، از جمله OS Thread ID، زمان CPU، Stack، Affinity و Processor Group را ارائه می‌کند.

Thread موجودی سیستم‌عامل است؛ Worker انتزاع SQLOS برای اجرای Task روی Thread یا Fiber محسوب می‌شود.

Syntax پایه

SELECT *
FROM sys.dm_os_threads;

پارامترها

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

نوع خروجی

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

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

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

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

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

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

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

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

مثال 1: فهرست Threadهای ساخته‌شده توسط SQL Server

ستون started_by_sqlservr مشخص می‌کند Thread از سوی موتور ایجاد شده است. نمایش os_thread_id، وضعیت و زمان ایجاد، پایه‌ای برای تطبیق Threadهای SQL Server با ابزارهای سیستم‌عامل فراهم می‌کند.

SELECT TOP (50) os_thread_id, status,
       creation_time, processor_group, affinity
FROM sys.dm_os_threads
WHERE started_by_sqlservr = 1
ORDER BY creation_time;

os_thread_id برای تطبیق با Trace یا ابزارهای OS مفید است، اما پس از Restart یا ایجاد مجدد Thread پایدار نمی‌ماند.

مثال 2: شمار Threadها بر اساس وضعیت

این تجمیع ترکیب Status و اینکه Thread توسط SQL Server آغاز شده یا نه را نشان می‌دهد. Status یک مقدار سطح پایین است و نباید بدون مستندات همان نسخه به برچسب دلخواه تبدیل شود.

SELECT started_by_sqlservr, status,
       COUNT_BIG(*) AS thread_count
FROM sys.dm_os_threads
GROUP BY started_by_sqlservr, status
ORDER BY started_by_sqlservr DESC, thread_count DESC;

از شمار Thread به‌تنهایی نمی‌توان اشباع Worker را نتیجه گرفت. Workers، Tasks و max worker threads با Thread مفاهیم مرتبط اما یکسان نیستند.

مثال 3: Threadهای پرمصرف از نظر CPU تجمعی

kernel_time و usermode_time زمان CPU تجمعی Thread را نشان می‌دهند. مرتب‌سازی مجموع آن‌ها Threadهای فعال‌تر از زمان ایجاد را مشخص می‌کند و os_thread_id را برای تطبیق بیرونی ارائه می‌دهد.

SELECT TOP (20) os_thread_id, kernel_time,
       usermode_time,
       kernel_time + usermode_time AS total_cpu_time,
       creation_time
FROM sys.dm_os_threads
ORDER BY total_cpu_time DESC;

این مقادیر تجمعی هستند و واحد و دامنه باید مطابق نسخه تفسیر شود. Delta دو Snapshot برای بار جاری ارزشمندتر از رتبه کل عمر Thread است.

مثال 4: بررسی مصرف Stack Thread

ستون‌های stack_bytes_committed و stack_bytes_used برای بررسی حافظه Stack در سطح Thread کاربرد دارند. نسبت استفاده به Commit می‌تواند Threadهای نزدیک‌تر به ظرفیت تخصیص‌یافته را آشکار کند.

SELECT TOP (20) os_thread_id,
       stack_bytes_committed, stack_bytes_used,
       CAST(100.0 * stack_bytes_used /
            NULLIF(stack_bytes_committed, 0) AS decimal(6,2)) AS used_pct
FROM sys.dm_os_threads
ORDER BY used_pct DESC;

درصد بالا به‌تنهایی اثبات خطا نیست. این شاخص برای تحلیل عمیق و Support سناریوهای خاص است و نباید مبنای تغییر خودسرانه تنظیمات موتور باشد.

مثال 5: توزیع Affinity و Processor Group

سرورهای بزرگ ممکن است چند Processor Group داشته باشند. شمار Threadها بر اساس processor_group و affinity کمک می‌کند توزیع سطح پایین پردازش و محدودیت‌های Affinity مرور شود.

SELECT processor_group, affinity,
       COUNT_BIG(*) AS thread_count
FROM sys.dm_os_threads
WHERE started_by_sqlservr = 1
GROUP BY processor_group, affinity
ORDER BY processor_group, affinity;

Affinity یک Bitmap است و باید با توپولوژی واقعی CPU و تنظیمات Instance تفسیر شود. مقایسه با sys.dm_os_nodes و sys.dm_os_schedulers تصویر کامل‌تری می‌دهد.

مثال 6: Threadهای منتظر Loader Lock

پرچم is_waiting_on_loader_lock در تحلیل شرایط خاص بارگذاری Module یا DLL اهمیت دارد. این کوئری فقط Threadهای منتظر Loader Lock را همراه با Instruction Address و زمان ایجاد نمایش می‌دهد.

SELECT os_thread_id, status, instruction_address,
       creation_time, kernel_time, usermode_time
FROM sys.dm_os_threads
WHERE is_waiting_on_loader_lock = 1;

خروجی خالی حالت معمول است. مشاهده ردیف پایدار باید با Error Log، Dump و تغییرات اخیر Componentها بررسی شود، نه با خاتمه تصادفی Thread.

مثال 7: بررسی Impersonation در سطح Thread

is_impersonating نشان می‌دهد Thread در آن لحظه تحت زمینه امنیتی Impersonation اجرا می‌شود. این نمای کمکی برای عیب‌یابی سناریوهای امنیتی، Linked Server یا دسترسی‌های تفویض‌شده است.

SELECT os_thread_id, status, creation_time,
       processor_group, affinity
FROM sys.dm_os_threads
WHERE is_impersonating = 1
ORDER BY creation_time;

Impersonation می‌تواند کاملاً قانونی باشد. برای نتیجه امنیتی باید Session، Login، Context اجرا و پیکربندی Kerberos یا Delegation نیز بررسی شود.

مثال 8: پیوند Thread به Worker

thread_address کلید اتصال sys.dm_os_threads به sys.dm_os_workers است. این پیوند os_thread_id را در کنار State Worker، Wait اخیر و Task جاری قرار می‌دهد و فاصله میان ابزار OS و DMV را پر می‌کند.

SELECT th.os_thread_id, th.processor_group,
       w.state AS worker_state, w.last_wait_type,
       w.task_address, w.is_preemptive
FROM sys.dm_os_threads AS th
JOIN sys.dm_os_workers AS w
  ON w.thread_address = th.thread_address
ORDER BY th.os_thread_id;

این اتصال برای تشخیص دقیق ارزشمند است، ولی آدرس‌ها در حافظه و فقط در عمر فعلی سرویس معتبرند. آن‌ها را شناسه دائمی کسب‌وکار تلقی نکنید.

مثال 9: شناسایی Priorityهای غیرمعمول

مرتب‌سازی Threadها بر اساس priority و گروه‌بندی وضعیت، تفاوت Priorityهای سطح پایین را نشان می‌دهد. این بررسی باید Read-only بماند؛ تغییر Priority Threadهای موتور از بیرون می‌تواند پایداری را مختل کند.

SELECT priority, status,
       COUNT_BIG(*) AS thread_count,
       MIN(creation_time) AS oldest_thread
FROM sys.dm_os_threads
GROUP BY priority, status
ORDER BY priority DESC, status;

مقادیر داخلی ممکن است میان نسخه‌ها تفاوت داشته باشند. هدف این Query ساخت Baseline و یافتن تغییر غیرمنتظره است، نه اعمال تنظیم سطح OS.

مثال 10: Delta مصرف CPU Threadها

برای جدا کردن فعالیت جاری از مقدار تجمعی، زمان‌های Kernel و User در دو Snapshot مقایسه می‌شوند. Threadهایی که در فاصله یک ثانیه بیشترین رشد را داشته‌اند در بالای خروجی قرار می‌گیرند.

SELECT thread_address, os_thread_id,
       kernel_time, usermode_time
INTO #thread_before
FROM sys.dm_os_threads;

WAITFOR DELAY '00:00:01';

SELECT TOP (20) t.os_thread_id,
       (t.kernel_time - b.kernel_time) +
       (t.usermode_time - b.usermode_time) AS cpu_delta
FROM sys.dm_os_threads AS t
JOIN #thread_before AS b
  ON b.thread_address = t.thread_address
ORDER BY cpu_delta DESC;

DROP TABLE #thread_before;

اگر Thread میان دو Snapshot حذف یا ایجاد شود در Join دیده نمی‌شود؛ این رفتار برای مقایسه امن است. فاصله نمونه‌برداری باید با هدف و هزینه مانیتورینگ تنظیم شود.

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

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

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

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

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

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

خواندن موردی sys.dm_os_threads با ستون‌های محدود معمولاً سبک است، اما هزینه به نرخ اجرا، تعداد ردیف، 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_threads زمانی بیشترین ارزش را دارد که در 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_threads دقیقاً چه چیزی را نشان می‌دهد؟

sys.dm_os_threads اطلاعات Threadهای سیستم‌عامل مرتبط با SQL Server، از جمله OS Thread ID، زمان CPU، Stack، Affinity و Processor Group را ارائه می‌کند. خروجی یک Snapshot زنده است و برای نتیجه‌گیری باید با زمان Capture، Uptime و DMVهای مکمل تفسیر شود.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

زیرا 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_threads روشن است.
• نسخه و وجود ستون‌های استفاده‌شده بررسی شده است.
• مجوز با اصل حداقل دسترسی واگذار شده است.
• SELECT ستاره در Collector استفاده نشده است.
• Timestamp UTC و Uptime ثبت می‌شوند.
• مقدار تجمعی با Delta تحلیل می‌شود.
• Snapshot منفرد به علت قطعی تبدیل نمی‌شود.
• Join یک‌به‌چند از نظر Double Count کنترل شده است.
• Retention و امنیت جدول تاریخچه مشخص است.
• نتیجه با DMVها و شواهد مکمل تطبیق داده می‌شود.

جمع‌بندی

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

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