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

sys.dm_os_ring_buffers یکی از DMVهای لایه SQL Server Operating System یا SQLOS است. رکوردهای چرخشی و محدود داخلی SQLOS را برای سرنخ‌های Scheduler Monitor، Resource، Exception و Connectivity در دسترس قرار می‌دهد. این نما برای تشخیص مبتنی بر شواهد طراحی شده و خروجی آن نباید به‌صورت جدا از بار کاری، زمان نمونه‌برداری و وضعیت سیستم‌عامل تفسیر شود.

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

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

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

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

رکوردهای چرخشی و محدود داخلی SQLOS را برای سرنخ‌های Scheduler Monitor، Resource، Exception و Connectivity در دسترس قرار می‌دهد.

این DMV منبع داخلی و نسخه‌پذیر است؛ برای پایش قراردادی و تاریخچه دائمی، Extended Events و منابع پشتیبانی‌شده اولویت دارند.

Syntax پایه

SELECT *
FROM sys.dm_os_ring_buffers;

پارامترها

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

نوع خروجی

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

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

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

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

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

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

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

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

مثال 1: فهرست نوع Ring Bufferها

Ring Buffer حافظه‌ای محدود و چرخشی است و رکوردهای قدیمی با ورود داده جدید بازنویسی می‌شوند. شمارش ring_buffer_type نشان می‌دهد در Instance فعلی چه نوع داده‌ای موجود است.

SELECT ring_buffer_type, COUNT_BIG(*) AS record_count
FROM sys.dm_os_ring_buffers
GROUP BY ring_buffer_type
ORDER BY record_count DESC;

وجود نوع و تعداد رکورد به نسخه و فعالیت Instance وابسته است. این DMV تاریخچه دائمی یا قرارداد ثابت برای XML داخلی ارائه نمی‌کند.

مثال 2: محاسبه زمان تقریبی رخدادها

timestamp برحسب Tick از شروع سرویس است، نه زمان تقویمی. با ms_ticks می‌توان زمان تقریبی هر رکورد را نسبت به ساعت فعلی محاسبه کرد و تازه‌ترین رکوردها را دید.

SELECT TOP (50) rb.ring_buffer_type,
       DATEADD(SECOND,
           -CONVERT(int, (si.ms_ticks - rb.[timestamp]) / 1000),
           SYSDATETIME()) AS approximate_event_time,
       rb.[timestamp]
FROM sys.dm_os_ring_buffers AS rb
CROSS JOIN sys.dm_os_sys_info AS si
ORDER BY rb.[timestamp] DESC;

زمان محاسبه‌شده تقریبی است و تغییر ساعت سیستم می‌تواند اثر بگذارد. برای حسابرسی دقیق از Extended Events یا منبع پایدارتر استفاده کنید.

مثال 3: مرور Scheduler Monitor

نوع RING_BUFFER_SCHEDULER_MONITOR داده‌های پایش داخلی Scheduler و System Health را در برخی نسخه‌ها نگه می‌دارد. این Query تازه‌ترین رکوردها را بدون فرض قطعی درباره شکل XML بازمی‌گرداند.

SELECT TOP (20) [timestamp],
       TRY_CONVERT(xml, record) AS record_xml
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = N'RING_BUFFER_SCHEDULER_MONITOR'
ORDER BY [timestamp] DESC;

TRY_CONVERT مانع شکست کل Query در صورت رکورد غیرقابل‌تبدیل می‌شود. Schema داخلی ممکن است تغییر کند؛ Parser باید نسخه‌پذیر و مقاوم به NULL باشد.

مثال 4: استخراج ProcessUtilization از System Health

در نسخه‌هایی که مسیر XML مربوط موجود است، می‌توان درصد ProcessUtilization را استخراج کرد. OUTER APPLY اجازه می‌دهد رکوردهای فاقد XML نیز بدون خطای Cast مدیریت شوند.

WITH rb AS
(
    SELECT TOP (20) [timestamp], TRY_CONVERT(xml, record) AS x
    FROM sys.dm_os_ring_buffers
    WHERE ring_buffer_type = N'RING_BUFFER_SCHEDULER_MONITOR'
    ORDER BY [timestamp] DESC
)
SELECT [timestamp],
       x.value('(./Record/SchedulerMonitorEvent/SystemHealth/ProcessUtilization)[1]', 'int')
           AS sql_process_cpu_pct
FROM rb
WHERE x IS NOT NULL;

اگر مسیر در نسخه یا رکورد خاص وجود نداشته باشد NULL برمی‌گردد. برای پایش قراردادی CPU بهتر است از Performance Counter یا ابزار مانیتورینگ استاندارد نیز استفاده شود.

مثال 5: استخراج SystemIdle از رکورد سلامت

SystemIdle سهم بیکاری پردازنده کل سیستم را در برخی رکوردهای System Health نشان می‌دهد. مقایسه آن با ProcessUtilization کمک می‌کند مصرف SQL Server از مصرف سایر Processها تفکیک شود.

WITH rb AS
(
    SELECT TOP (20) TRY_CONVERT(xml, record) AS x
    FROM sys.dm_os_ring_buffers
    WHERE ring_buffer_type = N'RING_BUFFER_SCHEDULER_MONITOR'
    ORDER BY [timestamp] DESC
)
SELECT x.value('(./Record/SchedulerMonitorEvent/SystemHealth/SystemIdle)[1]', 'int') AS system_idle_pct,
       x.value('(./Record/SchedulerMonitorEvent/SystemHealth/ProcessUtilization)[1]', 'int') AS sql_cpu_pct
FROM rb
WHERE x IS NOT NULL;

باقی مصرف به Processهای دیگر و خطای نمونه مربوط است. این داده تقریبی و داخلی است؛ برای ظرفیت‌سنجی طولانی باید Collector پایدارتر داشته باشید.

مثال 6: مرور اعلان‌های Resource Monitor

رکوردهای Resource Monitor می‌توانند سرنخ‌هایی از تغییر وضعیت منابع بدهند. نمونه زیر نوع دقیق و XML خام تازه‌ترین رکوردهای مرتبط با واژه RESOURCE را نگه می‌دارد.

SELECT TOP (30) ring_buffer_type, [timestamp],
       TRY_CONVERT(xml, record) AS record_xml
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type LIKE N'%RESOURCE%'
ORDER BY [timestamp] DESC;

نام و شکل رکوردها میان نسخه‌ها ممکن است فرق کند. برای فشار حافظه، پرچم‌های sys.dm_os_process_memory، Memory Clerkها و Error Log نیز بررسی می‌شوند.

مثال 7: مرور رکوردهای Exception

Ring Bufferهای مرتبط با Exception برای سرنخ اولیه مفیدند. این Query آخرین رکوردهای نوع‌هایی را که نامشان EXCEPTION دارد بازمی‌گرداند و تبدیل XML را ایمن انجام می‌دهد.

SELECT TOP (30) ring_buffer_type, [timestamp],
       TRY_CONVERT(xml, record) AS record_xml
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type LIKE N'%EXCEPTION%'
ORDER BY [timestamp] DESC;

هر Exception داخلی به معنی Crash نیست. شماره خطا، Severity، Error Log و Dump احتمالی باید برای تفسیر حرفه‌ای جمع‌آوری شوند.

مثال 8: مرور رخدادهای Connectivity

رکوردهای Connectivity می‌توانند در بررسی قطع اتصال یا خطای شبکه کمک کنند. محدود کردن TOP و مرتب‌سازی بر Timestamp از انتقال بی‌دلیل همه XMLها جلوگیری می‌کند.

SELECT TOP (50) [timestamp],
       TRY_CONVERT(xml, record) AS connectivity_record
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = N'RING_BUFFER_CONNECTIVITY'
ORDER BY [timestamp] DESC;

این داده محدود و چرخشی است. برای تحلیل قطعی Login و شبکه، Extended Events هدفمند و SQL Server Error Log مناسب‌ترند.

مثال 9: فیلتر بازه اخیر بر اساس Tick

به‌جای تبدیل همه رکوردها به زمان، می‌توان ابتدا بر اختلاف Tick فیلتر کرد. نمونه زیر رکوردهای تقریبی پنج دقیقه اخیر را انتخاب می‌کند و سپس زمان را نمایش می‌دهد.

SELECT rb.ring_buffer_type,
       DATEADD(SECOND,
           -CONVERT(int, (si.ms_ticks - rb.[timestamp]) / 1000),
           SYSDATETIME()) AS approximate_event_time,
       TRY_CONVERT(xml, rb.record) AS record_xml
FROM sys.dm_os_ring_buffers AS rb
CROSS JOIN sys.dm_os_sys_info AS si
WHERE si.ms_ticks - rb.[timestamp] BETWEEN 0 AND 300000
ORDER BY rb.[timestamp] DESC;

فیلتر قبل از تحلیل XML هزینه را کاهش می‌دهد. بااین‌حال Polling بسیار پرتکرار Ring Buffer توصیه نمی‌شود و باید با نیاز رخدادمحور تنظیم شود.

مثال 10: الگوی امن برای ذخیره شواهد

برای Incident می‌توان نوع، Tick، XML و زمان Capture را در یک جدول موقت نگه داشت. انتخاب ستون‌های محدود و TOP مانع تولید خروجی حجیم می‌شود.

SELECT TOP (200)
       SYSUTCDATETIME() AS captured_at_utc,
       ring_buffer_type, [timestamp],
       TRY_CONVERT(xml, record) AS record_xml
INTO #ring_buffer_evidence
FROM sys.dm_os_ring_buffers
ORDER BY [timestamp] DESC;

SELECT ring_buffer_type, COUNT_BIG(*) AS captured_rows
FROM #ring_buffer_evidence
GROUP BY ring_buffer_type;

DROP TABLE #ring_buffer_evidence;

جدول موقت فقط برای جلسه جاری است. برای تاریخچه دائمی، Schema نسخه‌پذیر، Retention، امنیت داده و استفاده ترجیحی از Extended Events را طراحی کنید.

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

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

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

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

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

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

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

sys.dm_os_ring_buffers رکوردهای چرخشی و محدود داخلی SQLOS را برای سرنخ‌های Scheduler Monitor، Resource، Exception و Connectivity در دسترس قرار می‌دهد. خروجی یک Snapshot زنده است و برای نتیجه‌گیری باید با زمان Capture، Uptime و DMVهای مکمل تفسیر شود.

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

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

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

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

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

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

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

این DMV منبع داخلی و نسخه‌پذیر است؛ برای پایش قراردادی و تاریخچه دائمی، Extended Events و منابع پشتیبانی‌شده اولویت دارند. ترکیب لایه‌ها مانع می‌شود یک شمارنده منفرد به علت قطعی تبدیل شود.

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

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

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

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

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

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

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

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

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

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

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

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

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

جمع‌بندی

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

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