مثالهای عملی
مثال 1: مشاهده مستقیم دادههای DMV
در این سناریو هدف این است که برای آشنایی با ساختار واقعی DMV و وضعیت جاری سرور، ابتدا تعداد محدودی ردیف را مشاهده کنید. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT TOP (20)
memory_broker_type, allocations_kb, allocations_kb_per_sec, predicted_allocations_kb, target_allocations_kb, future_allocations_kb, overall_limit_kb
FROM sys.dm_os_memory_brokers;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 1 | Sample-1 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 1: برای آشنایی با ساختار واقعی DMV و وضعیت جاری سرور، ابتدا تعداد محدودی ردیف را مشاهده کنید. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 2: شمارش ردیفهای قابل مشاهده
در این سناریو هدف این است که شمارش ردیفها کمک میکند اندازه Result Set را قبل از گزارشگیری سنگین ارزیابی کنید. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT COUNT_BIG(*) AS row_count
FROM sys.dm_os_memory_brokers;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 2 | Sample-2 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 2: شمارش ردیفها کمک میکند اندازه Result Set را قبل از گزارشگیری سنگین ارزیابی کنید. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 3: مشاهده Metadata ستونها
در این سناریو هدف این است که این روش برای سازگاری نسخهها مفید است و قبل از وابسته کردن اسکریپت به نام ستونها، Metadata واقعی سرور را نشان میدهد. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT
c.column_id,
c.name AS column_name,
TYPE_NAME(c.user_type_id) AS data_type
FROM sys.all_columns AS c
WHERE c.object_id = OBJECT_ID(N'sys.dm_os_memory_brokers')
ORDER BY c.column_id;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 3 | Sample-3 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 3: این روش برای سازگاری نسخهها مفید است و قبل از وابسته کردن اسکریپت به نام ستونها، Metadata واقعی سرور را نشان میدهد. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 4: ذخیره Snapshot موقت
در این سناریو هدف این است که Snapshot موقت امکان تحلیل چندمرحلهای را بدون Query مکرر DMV فراهم میکند. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
DROP TABLE IF EXISTS #memory_snapshot;
SELECT TOP (100) *
INTO #memory_snapshot
FROM sys.dm_os_memory_brokers;
SELECT COUNT_BIG(*) AS captured_rows
FROM #memory_snapshot;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 4 | Sample-4 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 4: Snapshot موقت امکان تحلیل چندمرحلهای را بدون Query مکرر DMV فراهم میکند. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 5: فیلتر بر اساس یک شاخص عددی
در این سناریو هدف این است که فیلتر روی allocations_kb کمک میکند ردیفهای فعال یا پرمصرف سریعتر دیده شوند. آستانه واقعی باید بر اساس Baseline سرور تعیین شود. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT TOP (50)
memory_broker_type, allocations_kb, allocations_kb_per_sec, predicted_allocations_kb, target_allocations_kb, future_allocations_kb, overall_limit_kb
FROM sys.dm_os_memory_brokers
WHERE allocations_kb > 0
ORDER BY allocations_kb DESC;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 5 | Sample-5 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 5: فیلتر روی allocations_kb کمک میکند ردیفهای فعال یا پرمصرف سریعتر دیده شوند. آستانه واقعی باید بر اساس Baseline سرور تعیین شود. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 6: نمایش ساختار Result Set بدون حدس ستونها
در این سناریو هدف این است که این تابع Metadata خروجی Query را برمیگرداند و برای ابزارهای پویا و تولید گزارش سازگار با نسخه مفید است. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT
column_ordinal,
name,
system_type_name,
is_nullable
FROM sys.dm_exec_describe_first_result_set(
N'SELECT * FROM sys.dm_os_memory_brokers', NULL, 0
)
WHERE is_hidden = 0
ORDER BY column_ordinal;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 6 | Sample-6 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 6: این تابع Metadata خروجی Query را برمیگرداند و برای ابزارهای پویا و تولید گزارش سازگار با نسخه مفید است. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 7: ثبت زمان نمونهبرداری کنار داده
در این سناریو هدف این است که ثبت Timestamp کنار هر Snapshot برای تحلیل روند و همبستگی با رخدادهای Performance ضروری است. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT TOP (20)
SYSDATETIME() AS sample_time,
d.*
FROM sys.dm_os_memory_brokers AS d;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 7 | Sample-7 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 7: ثبت Timestamp کنار هر Snapshot برای تحلیل روند و همبستگی با رخدادهای Performance ضروری است. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 8: مقایسه دو نمونه متوالی
در این سناریو هدف این است که در مانیتورینگ واقعی بهتر است فاصله نمونهبرداری بزرگتر و داده در جدول تاریخچه ذخیره شود. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
DROP TABLE IF EXISTS #s1;
DROP TABLE IF EXISTS #s2;
SELECT TOP (100) * INTO #s1 FROM sys.dm_os_memory_brokers;
WAITFOR DELAY '00:00:01';
SELECT TOP (100) * INTO #s2 FROM sys.dm_os_memory_brokers;
SELECT
(SELECT COUNT_BIG(*) FROM #s1) AS first_count,
(SELECT COUNT_BIG(*) FROM #s2) AS second_count;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 8 | Sample-8 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 8: در مانیتورینگ واقعی بهتر است فاصله نمونهبرداری بزرگتر و داده در جدول تاریخچه ذخیره شود. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 9: مدیریت خطای دسترسی
در این سناریو هدف این است که این الگو برای اسکریپتهای عملیاتی مناسب است تا خطای Permission یا تفاوت نسخه بهصورت کنترلشده گزارش شود. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
BEGIN TRY
SELECT TOP (5) *
FROM sys.dm_os_memory_brokers;
END TRY
BEGIN CATCH
SELECT
ERROR_NUMBER() AS error_number,
ERROR_MESSAGE() AS error_message;
END CATCH;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 9 | Sample-9 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 9: این الگو برای اسکریپتهای عملیاتی مناسب است تا خطای Permission یا تفاوت نسخه بهصورت کنترلشده گزارش شود. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 10: الگوی کمهزینه برای مانیتورینگ
در این سناریو هدف این است که در Queryهای دورهای باید تعداد ستون و ردیف را محدود کنید و از اجرای تجمیعهای سنگین با فاصله کوتاه بپرهیزید. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT TOP (10) *
FROM sys.dm_os_memory_brokers;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 10 | Sample-10 | خروجی نمونه برای sys.dm_os_memory_brokers; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 10: در Queryهای دورهای باید تعداد ستون و ردیف را محدود کنید و از اجرای تجمیعهای سنگین با فاصله کوتاه بپرهیزید. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
سؤالات متداول
sys.dm_os_memory_brokers دقیقاً چه چیزی را نشان میدهد؟
اطلاعات Brokerهای مدیریت حافظه و روند تخصیص، هدفگذاری و فشار حافظه میان اجزای مختلف موتور SQL Server. خروجی آن باید در زمینه زمان نمونهبرداری و Workload تفسیر شود.
بهترین نقطه شروع برای یادگیری sys.dm_os_memory_brokers چیست؟
ابتدا Syntax پایه و Metadata ستونها را ببینید، سپس دو یا سه ستون کلیدی را در چند Snapshot مقایسه کنید و بعد سراغ Queryهای تحلیلیتر بروید.
آیا sys.dm_os_memory_brokers برای مانیتورینگ تجاری مناسب است؟
بله، به شرط آنکه نرخ نمونهبرداری، Retention و سربار Query کنترل شود. در سامانههای حرفهای معمولاً داده منتخب ذخیره و سپس گزارش میشود.
چگونه از sys.dm_os_memory_brokers در پروژه Performance Tuning استفاده میشود؟
این DMV یک قطعه از شواهد است. متخصص آن را با Waitها، Query Store، I/O و تنظیمات حافظه ترکیب میکند تا علت اصلی مشخص شود.
sys.dm_os_memory_brokers با DMVهای دیگر چه تفاوتی دارد؟
هر DMV سطح متفاوتی از حافظه را نشان میدهد. تفاوت اصلی در Scope داده است؛ برخی سطح سیستم یا فرایند، برخی Clerk، Cache، Buffer Pool یا NUMA را پوشش میدهند.
آیا میتوان برای sys.dm_os_memory_brokers Alert ساخت؟
بله، اما Alert بهتر است بر روند یا ترکیب چند شاخص بنا شود. آستانه تکعددی بدون Baseline ممکن است False Positive زیادی ایجاد کند.
رایجترین خطا هنگام استفاده از sys.dm_os_memory_brokers چیست؟
تفسیر یک Snapshot به عنوان حقیقت دائمی، اجرای Query سنگین با فاصله کوتاه و فرض یکسان بودن ستونها در همه نسخهها از خطاهای رایج است.
آیا Query کردن sys.dm_os_memory_brokers روی Performance اثر دارد؟
Queryهای ساده معمولاً سبک هستند، اما حجم DMV و نوع تجمیع مهم است. SELECT گسترده یا GROUP BY سنگین را با نرخ بالا اجرا نکنید.
Best Practice ذخیره داده sys.dm_os_memory_brokers چیست؟
فقط ستونهای لازم را همراه Timestamp و شناسه سرور ذخیره کنید، Index مناسب روی جدول تاریخچه بسازید و Retention مشخص داشته باشید.
آیا sys.dm_os_memory_brokers در همه نسخههای SQL Server یکسان است؟
خیر. وجود DMV، ستونها و مجوز لازم میتواند میان نسخهها تفاوت داشته باشد. Metadata و مستندات همان نسخه باید مرجع نهایی اسکریپت Production باشد.