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

sys.dm_os_sys_info یکی از DMVهای لایه SQL Server Operating System یا SQLOS است. یک Snapshot تک‌ردیفی از CPU، حافظه، Uptime، توپولوژی NUMA، مجازی‌سازی، Container، Soft-NUMA و منبع زمان ارائه می‌کند. این نما برای تشخیص مبتنی بر شواهد طراحی شده و خروجی آن نباید به‌صورت جدا از بار کاری، زمان نمونه‌برداری و وضعیت سیستم‌عامل تفسیر شود.

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

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

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

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

یک Snapshot تک‌ردیفی از CPU، حافظه، Uptime، توپولوژی NUMA، مجازی‌سازی، Container، Soft-NUMA و منبع زمان ارائه می‌کند.

این DMV ظرفیت و Context سیستم را می‌دهد؛ مصرف جاری Process را باید از sys.dm_os_process_memory و فشار Scheduler را از sys.dm_os_schedulers گرفت.

Syntax پایه

SELECT *
FROM sys.dm_os_sys_info;

پارامترها

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

نوع خروجی

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

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

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

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

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

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

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

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

مثال 1: نمای کلی ظرفیت Instance

این DMV معمولاً یک ردیف از اطلاعات سیستم و SQLOS برمی‌گرداند. Query پایه تعداد CPU، حافظه فیزیکی، زمان شروع سرویس و شرح نوع Affinity را در واحدهای خوانا نمایش می‌دهد.

SELECT cpu_count, hyperthread_ratio,
       physical_memory_kb / 1024 AS physical_memory_mb,
       sqlserver_start_time, affinity_type_desc
FROM sys.dm_os_sys_info;

این ظرفیت چیزی است که Instance مشاهده می‌کند و ممکن است با سخت‌افزار میزبان متفاوت باشد. در VM، تنظیم Hypervisor و محدودیت Container نیز اهمیت دارد.

مثال 2: محاسبه Uptime سرویس

ms_ticks زمان گذشته از شروع SQLOS را برحسب میلی‌ثانیه نگه می‌دارد. تقسیم مرحله‌ای آن، Uptime تقریبی را به روز و ساعت تبدیل می‌کند.

SELECT sqlserver_start_time,
       ms_ticks / 1000 / 60 AS uptime_minutes,
       ms_ticks / 1000 / 60 / 60 AS uptime_hours,
       ms_ticks / 1000 / 60 / 60 / 24 AS uptime_days
FROM sys.dm_os_sys_info;

Restart شمارنده‌های تجمعی بسیاری از DMVها را صفر می‌کند. زمان شروع سرویس باید کنار Snapshotهای Performance ذخیره شود تا Reset با بهبود واقعی اشتباه نشود.

مثال 3: تبدیل حافظه به گیگابایت

physical_memory_kb و virtual_memory_kb در واحد کیلوبایت هستند. تبدیل صریح به decimal از تقسیم صحیح و از دست رفتن اعشار جلوگیری می‌کند.

SELECT CAST(physical_memory_kb / 1024.0 / 1024.0 AS decimal(12,2)) AS physical_memory_gb,
       CAST(virtual_memory_kb / 1024.0 / 1024.0 AS decimal(12,2)) AS virtual_memory_gb
FROM sys.dm_os_sys_info;

این مقدار حافظه سیستم است، نه الزاماً حافظه مصرفی Process SQL Server. برای مصرف جاری از sys.dm_os_process_memory و برای تنظیم سقف از پیکربندی max server memory استفاده کنید.

مثال 4: مرور توپولوژی Socket و Core

socket_count، cores_per_socket و numa_node_count توپولوژی دیده‌شده را خلاصه می‌کنند. مقایسه حاصل ضرب Socket و Core با cpu_count سرنخی از Hyperthreading و ارائه vCPU می‌دهد.

SELECT socket_count, cores_per_socket,
       numa_node_count, cpu_count, hyperthread_ratio,
       socket_count * cores_per_socket AS reported_physical_cores
FROM sys.dm_os_sys_info;

تعریف Core در محیط مجازی به نحوه ارائه Hypervisor وابسته است. برای لایسنس و Capacity Planning، داده DMV باید با مشخصات میزبان و قرارداد لایسنس تطبیق داده شود.

مثال 5: بررسی نسبت Hyperthread

hyperthread_ratio تعداد Logical Processor به ازای Package را گزارش می‌کند و نام آن گاهی باعث برداشت اشتباه می‌شود. این Query آن را کنار CPU و Socket نشان می‌دهد تا در Context تفسیر شود.

SELECT cpu_count, socket_count, cores_per_socket,
       hyperthread_ratio,
       CAST(1.0 * cpu_count / NULLIF(socket_count, 0) AS decimal(10,2)) AS logical_cpu_per_socket
FROM sys.dm_os_sys_info;

برای نتیجه قطعی فعال بودن SMT فقط به نام ستون تکیه نکنید. توپولوژی OS، VM و مستندات سخت‌افزار نیز باید بررسی شوند.

مثال 6: تشخیص ماشین مجازی

virtual_machine_type_desc نشان می‌دهد SQL Server محیط را فیزیکی، Hypervisor یا نوع دیگری تشخیص داده است. این داده برای تفسیر CPU Steal، Overcommit و محدودیت منابع مهم است.

SELECT virtual_machine_type,
       virtual_machine_type_desc,
       cpu_count, physical_memory_kb / 1024 AS memory_mb
FROM sys.dm_os_sys_info;

تشخیص Hypervisor جزئیات تخصیص واقعی یا Overcommit میزبان را نمی‌دهد. برای تحلیل کندی VM، داده تیم زیرساخت و Metrics میزبان لازم است.

مثال 7: مرور وضعیت Container

در نسخه‌هایی که ستون‌های Container ارائه می‌شوند، container_type_desc مشخص می‌کند Process در Container اجرا می‌شود یا نه. ظرفیت داخل Container ممکن است با ظرفیت میزبان تفاوت داشته باشد.

SELECT container_type, container_type_desc,
       cpu_count,
       physical_memory_kb / 1024 AS visible_memory_mb
FROM sys.dm_os_sys_info;

در محیط چندنسخه‌ای ابتدا وجود ستون را بررسی کنید. محدودیت cgroup یا Orchestrator باید در کنار ظرفیت گزارش‌شده توسط SQL Server تحلیل شود.

مثال 8: زمان CPU مصرف‌شده Process

process_kernel_time_ms و process_user_time_ms مصرف تجمعی CPU Process را از شروع سرویس نشان می‌دهند. مجموع آن‌ها برای Snapshot پایه مفید است.

SELECT process_kernel_time_ms,
       process_user_time_ms,
       process_kernel_time_ms + process_user_time_ms AS process_cpu_ms,
       sqlserver_start_time
FROM sys.dm_os_sys_info;

مقدار تجمعی باید در دو زمان نمونه‌برداری و به نسبت تعداد CPU تحلیل شود. مقایسه خام دو سرور با Uptime متفاوت گمراه‌کننده است.

مثال 9: بررسی منبع زمان

time_source_desc منبع زمانی استفاده‌شده توسط موتور را شرح می‌دهد. این اطلاعات در تحلیل Timestamp، مجازی‌سازی و جهش‌های زمان سیستم مفید است.

SELECT time_source, time_source_desc,
       cpu_ticks, ms_ticks,
       sqlserver_start_time
FROM sys.dm_os_sys_info;

منبع زمان معمولاً نباید دستکاری شود. در رخدادهای زمان، همگام‌سازی OS، Hypervisor و سرویس NTP را نیز بررسی کنید.

مثال 10: گزارش Soft-NUMA

softnuma_configuration_desc وضعیت پیکربندی Soft-NUMA را در نسخه‌های جدید نشان می‌دهد. این داده با شمار Nodeها و Schedulerها برای تحلیل توزیع CPU ترکیب می‌شود.

SELECT softnuma_configuration,
       softnuma_configuration_desc,
       numa_node_count, cpu_count
FROM sys.dm_os_sys_info;

Automatic Soft-NUMA در سخت‌افزارهای پرهسته می‌تواند توزیع را بهبود دهد. تغییر دستی آن باید بر پایه Baseline و آزمون بار انجام شود، نه صرفاً مشاهده تعداد Node.

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

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

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

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

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

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

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

sys.dm_os_sys_info یک Snapshot تک‌ردیفی از CPU، حافظه، Uptime، توپولوژی NUMA، مجازی‌سازی، Container، Soft-NUMA و منبع زمان ارائه می‌کند. خروجی یک Snapshot زنده است و برای نتیجه‌گیری باید با زمان Capture، Uptime و DMVهای مکمل تفسیر شود.

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

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

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

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

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

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

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

این DMV ظرفیت و Context سیستم را می‌دهد؛ مصرف جاری Process را باید از sys.dm_os_process_memory و فشار Scheduler را از sys.dm_os_schedulers گرفت. ترکیب لایه‌ها مانع می‌شود یک شمارنده منفرد به علت قطعی تبدیل شود.

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

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

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

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

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

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

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

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

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

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

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

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

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

جمع‌بندی

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

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