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

sys.dm_os_nodes یکی از DMVهای لایه SQL Server Operating System یا SQLOS است. ساختار Nodeهای SQLOS، ظرفیت CPU، Schedulerهای آنلاین و بیکار، Workerهای فعال، Affinity و Resource Monitor را نمایش می‌دهد. این نما برای تشخیص مبتنی بر شواهد طراحی شده و خروجی آن نباید به‌صورت جدا از بار کاری، زمان نمونه‌برداری و وضعیت سیستم‌عامل تفسیر شود.

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

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

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

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

ساختار Nodeهای SQLOS، ظرفیت CPU، Schedulerهای آنلاین و بیکار، Workerهای فعال، Affinity و Resource Monitor را نمایش می‌دهد.

Node لایه locality و منابع را نشان می‌دهد؛ Schedulerهای قابل مشاهده از طریق parent_node_id به Node خود متصل می‌شوند.

Syntax پایه

SELECT *
FROM sys.dm_os_nodes;

پارامترها

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

نوع خروجی

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

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

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

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

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

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

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

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

مثال 1: نمای کلی Nodeهای آنلاین

SQLOS ساختار Node را برای بازتاب locality پردازنده و NUMA ایجاد می‌کند. نخستین Query وضعیت، تعداد CPU، Schedulerهای آنلاین و Workerهای فعال هر Node را نمایش می‌دهد.

SELECT node_id, node_state_desc, processor_group,
       cpu_count, online_scheduler_count,
       idle_scheduler_count, active_worker_count
FROM sys.dm_os_nodes
WHERE node_state_desc LIKE N'%ONLINE%'
ORDER BY node_id;

Nodeهای ویژه یا DAC ممکن است ویژگی متفاوت داشته باشند. برای تحلیل بار عادی، Nodeهای آنلاین مرتبط با Schedulerهای قابل مشاهده را در اولویت بگذارید.

مثال 2: جمع ظرفیت CPU و Scheduler

جمع cpu_count و online_scheduler_count یک کنترل سریع برای ظرفیت دیده‌شده توسط SQLOS است. اختلاف ممکن است از Affinity، Nodeهای ویژه یا پیکربندی Instance ناشی شود و باید با sys.dm_os_sys_info مقایسه گردد.

SELECT SUM(cpu_count) AS node_cpu_count,
       SUM(online_scheduler_count) AS online_schedulers,
       SUM(active_worker_count) AS active_workers
FROM sys.dm_os_nodes
WHERE node_state_desc LIKE N'%ONLINE%';

برابری در نمونه عادی است، اما قانون مطلق همه محیط‌ها نیست. مجازی‌سازی و Affinity می‌توانند شکل توپولوژی را تغییر دهند.

مثال 3: مقایسه میانگین بار Nodeها

avg_load_balance یک مقدار داخلی برای متوسط Task در Schedulerهای Node است. مرتب‌سازی آن برای یافتن نامتوازنی احتمالی مفید است، ولی تصمیم نهایی باید بر شاخص‌های پشتیبانی‌شده و روند چند Snapshot تکیه کند.

SELECT node_id, avg_load_balance,
       active_worker_count, online_scheduler_count
FROM sys.dm_os_nodes
WHERE node_state_desc LIKE N'%ONLINE%'
ORDER BY avg_load_balance DESC;

اختلاف کوتاه می‌تواند طبیعی باشد. تداوم اختلاف همراه با صف Runnable و الگوی اتصال، بررسی Soft-NUMA و Affinity را توجیه می‌کند.

مثال 4: درصد Schedulerهای Idle هر Node

نسبت idle_scheduler_count به online_scheduler_count نشان می‌دهد چه سهمی از Schedulerهای Node در Snapshot بی‌کار هستند. NULLIF از تقسیم بر صفر جلوگیری می‌کند.

SELECT node_id, online_scheduler_count,
       idle_scheduler_count,
       CAST(100.0 * idle_scheduler_count /
            NULLIF(online_scheduler_count, 0) AS decimal(6,2)) AS idle_pct
FROM sys.dm_os_nodes
WHERE node_state_desc LIKE N'%ONLINE%'
ORDER BY idle_pct;

این درصد لحظه‌ای است و برای Capacity Planning باید در بازه‌های مختلف ذخیره شود. Idle پایین در ساعت اوج طبیعی است؛ Idle نزدیک صفر و صف CPU پایدار هشدار مهم‌تری است.

مثال 5: کنترل Resource Monitor هر Node

هر Node یک Resource Monitor دارد و resource_monitor_state فعال یا بیکار بودن آن را نشان می‌دهد. این Query وضعیت را به برچسب خوانا تبدیل می‌کند.

SELECT node_id,
       CASE resource_monitor_state
            WHEN 1 THEN N'فعال'
            ELSE N'بیکار'
       END AS resource_monitor_status,
       node_state_desc
FROM sys.dm_os_nodes
ORDER BY node_id;

فعال بودن Resource Monitor به‌تنهایی فشار حافظه را ثابت نمی‌کند. اعلان‌های حافظه، sys.dm_os_process_memory و Error Log شواهد تکمیلی هستند.

مثال 6: گزارش Processor Group و CPU

روی سخت‌افزارهای بزرگ، processor_group برای شناخت گروه‌های پردازنده اهمیت دارد. تجمیع Nodeها بر اساس Group ظرفیت CPU و تعداد Schedulerهای آنلاین را خلاصه می‌کند.

SELECT processor_group,
       COUNT_BIG(*) AS node_count,
       SUM(cpu_count) AS cpu_count,
       SUM(online_scheduler_count) AS online_schedulers
FROM sys.dm_os_nodes
WHERE node_state_desc LIKE N'%ONLINE%'
GROUP BY processor_group
ORDER BY processor_group;

در محیط مجازی ممکن است توپولوژی ارائه‌شده با سخت‌افزار فیزیکی میزبان متفاوت باشد. گزارش باید با داده Hypervisor و تنظیمات VM تکمیل شود.

مثال 7: پیوند Node و Scheduler

parent_node_id در sys.dm_os_schedulers به node_id متصل می‌شود. این گزارش شمار Scheduler، صف Runnable و Worker فعال را برای هر Node با داده واقعی Schedulerها محاسبه می‌کند.

SELECT n.node_id, COUNT_BIG(*) AS schedulers,
       SUM(s.runnable_tasks_count) AS runnable_tasks,
       SUM(s.active_workers_count) AS active_workers
FROM sys.dm_os_nodes AS n
JOIN sys.dm_os_schedulers AS s
  ON s.parent_node_id = n.node_id
WHERE s.status = N'VISIBLE ONLINE'
GROUP BY n.node_id
ORDER BY runnable_tasks DESC;

این پیوند برای فشار CPU عملی‌تر از avg_load_balance تنها است. چند Snapshot متوالی کمک می‌کند نوسان کوتاه از عدم تعادل پایدار جدا شود.

مثال 8: مرور Affinity Maskهای Node

cpu_affinity_mask و online_scheduler_mask Bitmapهایی برای CPUهای مرتبط و Schedulerهای آنلاین هستند. نمایش Hex خواندن و مقایسه Mask را ساده‌تر می‌کند.

SELECT node_id,
       CONVERT(varchar(34), cpu_affinity_mask, 1) AS cpu_affinity_mask,
       CONVERT(varchar(34), online_scheduler_mask, 1) AS online_scheduler_mask,
       cpu_count
FROM sys.dm_os_nodes
ORDER BY node_id;

تفسیر بیت‌ها باید با شماره CPU و Processor Group هماهنگ باشد. Mask را بدون برنامه و آزمون تغییر ندهید؛ Affinity نامناسب می‌تواند توازن بار را بدتر کند.

مثال 9: یافتن هشدار کمبود Thread Resource

node_state_desc می‌تواند وضعیت ترکیبی THREAD_RESOURCES_LOW را گزارش کند. برای تحمل تفاوت فاصله و نمایش، متن به حروف بزرگ و Underscore تبدیل و سپس فیلتر می‌شود.

SELECT node_id, node_state_desc,
       active_worker_count, online_scheduler_count
FROM sys.dm_os_nodes
WHERE UPPER(REPLACE(node_state_desc, N' ', N'_'))
      LIKE N'%THREAD_RESOURCES_LOW%';

خروجی خالی مطلوب است. اگر ردیف پایدار دیده شد، هم‌زمان THREADPOOL، تعداد اتصال، Block شدن و فشار حافظه بررسی شود.

مثال 10: ثبت Snapshot ظرفیت Node

برای Baseline بهتر است Timestamp UTC و ستون‌های پشتیبانی‌شده و ضروری ذخیره شوند. این Query ردیف کم‌حجم مناسبی برای جدول تاریخچه می‌سازد.

SELECT SYSUTCDATETIME() AS captured_at_utc,
       node_id, processor_group, cpu_count,
       online_scheduler_count, idle_scheduler_count,
       active_worker_count, resource_monitor_state
FROM sys.dm_os_nodes
WHERE node_state_desc LIKE N'%ONLINE%';

توپولوژی معمولاً کندتر از بار تغییر می‌کند؛ بنابراین نمونه‌برداری بسیار پرتکرار لازم نیست. نرخ Collector را با ارزش داده و هزینه نگهداری هماهنگ کنید.

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

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

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

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

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

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

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

sys.dm_os_nodes ساختار Nodeهای SQLOS، ظرفیت CPU، Schedulerهای آنلاین و بیکار، Workerهای فعال، Affinity و Resource Monitor را نمایش می‌دهد. خروجی یک Snapshot زنده است و برای نتیجه‌گیری باید با زمان Capture، Uptime و DMVهای مکمل تفسیر شود.

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

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

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

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

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

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

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

Node لایه locality و منابع را نشان می‌دهد؛ Schedulerهای قابل مشاهده از طریق parent_node_id به Node خود متصل می‌شوند. ترکیب لایه‌ها مانع می‌شود یک شمارنده منفرد به علت قطعی تبدیل شود.

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

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

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

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

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

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

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

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

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

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

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

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

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

جمع‌بندی

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

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