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

sys.dm_os_host_info یکی از DMVهای لایه SQL Server Operating System یا SQLOS است. Platform، Distribution، Release، سطح سرویس، SKU و زبان سیستم‌عامل میزبان را برای Inventory و Automation چندسکویی ارائه می‌کند. این نما برای تشخیص مبتنی بر شواهد طراحی شده و خروجی آن نباید به‌صورت جدا از بار کاری، زمان نمونه‌برداری و وضعیت سیستم‌عامل تفسیر شود.

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

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

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

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

Platform، Distribution، Release، سطح سرویس، SKU و زبان سیستم‌عامل میزبان را برای Inventory و Automation چندسکویی ارائه می‌کند.

این DMV مشخصات میزبان را می‌دهد؛ نسخه و Edition موتور با SERVERPROPERTY و ظرفیت CPU و حافظه با sys.dm_os_sys_info تکمیل می‌شود.

Syntax پایه

SELECT *
FROM sys.dm_os_host_info;

پارامترها

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

نوع خروجی

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

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

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

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

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

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

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

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

مثال 1: نمای کامل سیستم‌عامل میزبان

این DMV یک ردیف از Platform، Distribution، Release و اطلاعات میزبان بازمی‌گرداند. Query پایه برای Inventory سریع SQL Server روی Windows یا Linux مناسب است.

SELECT host_platform, host_distribution,
       host_release, host_service_pack_level,
       host_sku, os_language_version
FROM sys.dm_os_host_info;

ستون‌ها و مقدارها به Platform و نسخه SQL Server بستگی دارند. NULL یا متن متفاوت باید در ابزار Inventory پذیرفته شود.

مثال 2: تشخیص Windows یا Linux

host_platform برای شاخه‌بندی کنترل‌های عملیاتی مفید است. CASE زیر Platform شناخته‌شده را به توضیح فارسی تبدیل می‌کند و برای مقدارهای آینده مسیر عمومی دارد.

SELECT host_platform,
       CASE host_platform
         WHEN N'Windows' THEN N'میزبان ویندوزی'
         WHEN N'Linux' THEN N'میزبان لینوکسی'
         ELSE N'سکوی دیگر یا نسخه جدید'
       END AS platform_description
FROM sys.dm_os_host_info;

از Platform برای انتخاب مسیر فایل، ابزار Patch و دستورات سرویس استفاده کنید؛ منطق برنامه نباید فقط یک مقدار را فرض کند.

مثال 3: ساخت رشته نسخه میزبان

ترکیب Distribution و Release یک برچسب خوانا برای داشبورد Inventory می‌سازد. CONCAT با NULLها ایمن‌تر از عملگر جمع رشته‌ای است.

SELECT CONCAT(host_distribution, N' ', host_release) AS host_version,
       host_platform, host_service_pack_level
FROM sys.dm_os_host_info;

رشته برای نمایش مناسب است، اما مقایسه Patch بهتر است اجزای نسخه را جدا و استاندارد نگه دارد.

مثال 4: کنترل Service Pack یا سطح سرویس

host_service_pack_level سطح سرویس گزارش‌شده توسط میزبان را ارائه می‌کند. COALESCE مقدار خالی را به پیام خوانا تبدیل می‌کند.

SELECT host_platform,
       COALESCE(NULLIF(host_service_pack_level, N''),
                N'سطح سرویس گزارش نشده') AS service_pack_level,
       host_release
FROM sys.dm_os_host_info;

خالی بودن در بسیاری از Platformها طبیعی است. وضعیت Patch باید با ابزار مدیریت سیستم‌عامل و چرخه امنیتی سازمان تأیید شود.

مثال 5: مرور SKU میزبان

host_sku شناسه SKU یا Edition سیستم‌عامل را در نسخه‌های پشتیبان ارائه می‌دهد. این داده برای Inventory مفید است، ولی تفسیر عدد باید با Platform هماهنگ شود.

SELECT host_platform, host_sku,
       host_distribution, host_release
FROM sys.dm_os_host_info;

SKU سیستم‌عامل با Edition SQL Server یکسان نیست. برای Edition موتور از SERVERPROPERTY استفاده کنید.

مثال 6: گزارش زبان سیستم‌عامل

os_language_version مقدار زبان میزبان را نشان می‌دهد. این شاخص در عیب‌یابی Format، پیام‌های سیستمی و Automation چندزبانه مفید است.

SELECT os_language_version,
       host_platform, host_distribution
FROM sys.dm_os_host_info;

زبان OS با Language جلسه SQL Server یا Collation پایگاه داده متفاوت است. هر سه لایه باید جداگانه بررسی شوند.

مثال 7: ترکیب Host و مشخصات SQL Server

برای Inventory کامل‌تر، داده میزبان با SERVERPROPERTY ترکیب می‌شود. نتیجه Platform و نسخه OS را کنار ProductVersion، Edition و MachineName قرار می‌دهد.

SELECT h.host_platform, h.host_distribution, h.host_release,
       CONVERT(nvarchar(128), SERVERPROPERTY('MachineName')) AS machine_name,
       CONVERT(nvarchar(128), SERVERPROPERTY('ProductVersion')) AS sql_version,
       CONVERT(nvarchar(128), SERVERPROPERTY('Edition')) AS sql_edition
FROM sys.dm_os_host_info AS h;

MachineName ممکن است در Cluster یا Container نیازمند تفسیر باشد. برای شناسه پایدار CMDB، InstanceName و شناسه زیرساخت نیز ذخیره شوند.

مثال 8: انتخاب دستورالعمل بر پایه Platform

یک Query می‌تواند مسیر عملیاتی مناسب را بدون اجرای Command خارجی پیشنهاد دهد. این نمونه فقط پیام Read-only می‌سازد و هیچ تغییری روی میزبان انجام نمی‌دهد.

SELECT CASE host_platform
         WHEN N'Windows' THEN N'Patch را با چرخه Windows Update هماهنگ کنید'
         WHEN N'Linux' THEN N'Patch را با Package Manager توزیع هماهنگ کنید'
         ELSE N'مستندات سکوی میزبان را بررسی کنید'
       END AS patch_guidance
FROM sys.dm_os_host_info;

اجرای Patch باید با Backup، آزمون سازگاری، پنجره نگهداری و طرح بازگشت همراه باشد. DMV فقط Inventory می‌دهد، نه مجوز تغییر.

مثال 9: کنترل نسخه‌های ناهمگون در گزارش

COALESCE و CONCAT کمک می‌کنند خروجی در Platformهای دارای ستون خالی نیز شکسته نشود. این Query یک کلید نمایشی استاندارد می‌سازد.

SELECT CONCAT(
           COALESCE(host_platform, N'Unknown'), N'|',
           COALESCE(host_distribution, N'Unknown'), N'|',
           COALESCE(host_release, N'Unknown')) AS host_inventory_key
FROM sys.dm_os_host_info;

کلید نمایشی جایگزین شناسه یکتا نیست. برای CMDB از شناسه دارایی معتبر سازمان استفاده کنید و این رشته را ویژگی نسخه نگه دارید.

مثال 10: Snapshot استاندارد برای CMDB

این نمونه Timestamp UTC، مشخصات میزبان و نسخه موتور را در یک ردیف کم‌حجم برمی‌گرداند. خروجی برای Job دوره‌ای Inventory مناسب است.

SELECT SYSUTCDATETIME() AS captured_at_utc,
       host_platform, host_distribution, host_release,
       host_service_pack_level, host_sku, os_language_version,
       CONVERT(nvarchar(128), SERVERPROPERTY('ServerName')) AS server_name,
       CONVERT(nvarchar(128), SERVERPROPERTY('ProductVersion')) AS product_version
FROM sys.dm_os_host_info;

Inventory میزبان روزانه یا پس از تغییر کافی است و Polling ثانیه‌ای ارزشی ندارد. دسترسی خروجی و اطلاعات نام سرور نیز باید طبق سیاست امنیتی کنترل شود.

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

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

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

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

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

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

خواندن موردی sys.dm_os_host_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_host_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_host_info دقیقاً چه چیزی را نشان می‌دهد؟

sys.dm_os_host_info Platform، Distribution، Release، سطح سرویس، SKU و زبان سیستم‌عامل میزبان را برای Inventory و Automation چندسکویی ارائه می‌کند. خروجی یک Snapshot زنده است و برای نتیجه‌گیری باید با زمان Capture، Uptime و DMVهای مکمل تفسیر شود.

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

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

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

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

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

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

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

این DMV مشخصات میزبان را می‌دهد؛ نسخه و Edition موتور با SERVERPROPERTY و ظرفیت CPU و حافظه با sys.dm_os_sys_info تکمیل می‌شود. ترکیب لایه‌ها مانع می‌شود یک شمارنده منفرد به علت قطعی تبدیل شود.

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

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

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

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

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

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

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

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

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

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

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

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

جمع‌بندی

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

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