آموزش sys.dm_os_virtual_address_dump در SQL Server؛ فضای آدرس مجازی SQL Server
مقدمه
sys.dm_os_virtual_address_dump یکی از DMVهای تخصصی حافظه در Microsoft SQL Server است. نمای تشخیصی از فضای آدرس مجازی فرایند SQL Server برای بررسی رزرو، Commit و نواحی حافظه در سناریوهای عیبیابی پیشرفته. استفاده صحیح از این نما به DBA کمک میکند به جای حدس زدن علت مشکل، دادههای داخلی موتور را مشاهده و با سایر شاخصها مقایسه کند.
داده DMVها معمولاً لحظهای است و بعد از Restart سرویس یا تغییرات داخلی میتواند از نو شکل بگیرد. بنابراین نتیجه را به عنوان Snapshot تفسیر کنید و برای تصمیمهای مهم، روند چند نمونه را در کنار Wait Statistics، I/O، CPU و تنظیمات حافظه بررسی نمایید.
بازگشت به راهنمای جامع DMVهای عملکرد حافظه در SQL Server برای مشاهده ارتباط این DMV با سایر ابزارهای تحلیل حافظه.
تعریف و کاربرد اصلی
نمای تشخیصی از فضای آدرس مجازی فرایند SQL Server برای بررسی رزرو، Commit و نواحی حافظه در سناریوهای عیبیابی پیشرفته.
کاربرد sys.dm_os_virtual_address_dump در سناریوهای عیبیابی شامل ایجاد Baseline، بررسی رخدادهای فشار حافظه، مقایسه قبل و بعد از تغییر تنظیمات و ساخت داشبورد مانیتورینگ است. برای تحلیل حرفهای بهتر است این DMV را در کنار حداقل یک شاخص سطح سیستمعامل و یک شاخص داخلی SQL Server بررسی کنید.
در محیط Production از Queryهای سبک شروع کنید. SELECT * روی DMVهای حجیم یا تجمیع مکرر با فاصله چندثانیهای ممکن است سربار ایجاد کند. ابتدا تعداد ردیف، Metadata و ستونهای موردنیاز را مشخص کنید، سپس Query نهایی مانیتورینگ را محدود و هدفمند بسازید.
Syntax و نحوه استفاده
نحو پایه
SELECT *
FROM sys.dm_os_virtual_address_dump;
نحو پایه ساده است، اما ستونها و مجوزهای موردنیاز ممکن است بسته به نسخه SQL Server، Edition و پلتفرم تفاوت داشته باشند. در اسکریپتهای قابل حمل، Metadata همان سرور را بررسی کنید و از فرض قطعی درباره تمام ستونها خودداری نمایید.
پارامترها و نوع خروجی
این شیء بهصورت DMV خوانده میشود و پارامتر ورودی مستقیم ندارد. خروجی مجموعهای از ردیفها و ستونهای تشخیصی است. معنی هر ردیف به ماهیت DMV وابسته است و باید با زمان نمونهبرداری و وضعیت Workload تفسیر شود.
مثالهای عملی
مثال 1: مشاهده مستقیم دادههای DMV
در این سناریو هدف این است که برای آشنایی با ساختار واقعی DMV و وضعیت جاری سرور، ابتدا تعداد محدودی ردیف را مشاهده کنید. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT TOP (20)
*
FROM sys.dm_os_virtual_address_dump;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 1 | Sample-1 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 1: برای آشنایی با ساختار واقعی DMV و وضعیت جاری سرور، ابتدا تعداد محدودی ردیف را مشاهده کنید. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 2: شمارش ردیفهای قابل مشاهده
در این سناریو هدف این است که شمارش ردیفها کمک میکند اندازه Result Set را قبل از گزارشگیری سنگین ارزیابی کنید. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT COUNT_BIG(*) AS row_count
FROM sys.dm_os_virtual_address_dump;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 2 | Sample-2 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 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_virtual_address_dump')
ORDER BY c.column_id;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 3 | Sample-3 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 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_virtual_address_dump;
SELECT COUNT_BIG(*) AS captured_rows
FROM #memory_snapshot;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 4 | Sample-4 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 4: Snapshot موقت امکان تحلیل چندمرحلهای را بدون Query مکرر DMV فراهم میکند. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 5: کنترل وجود داده با EXISTS
در این سناریو هدف این است که این الگو برای Health Check یا اجرای شرطی بخشهای بعدی اسکریپت مناسب است. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT CASE
WHEN EXISTS (SELECT 1 FROM sys.dm_os_virtual_address_dump) THEN N'داده در دسترس است'
ELSE N'ردیفی برگردانده نشد'
END AS dmv_status;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 5 | Sample-5 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 5: این الگو برای Health Check یا اجرای شرطی بخشهای بعدی اسکریپت مناسب است. هنگام تحلیل نتیجه، مقدار فعلی را با 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_virtual_address_dump', NULL, 0
)
WHERE is_hidden = 0
ORDER BY column_ordinal;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 6 | Sample-6 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 6: این تابع Metadata خروجی Query را برمیگرداند و برای ابزارهای پویا و تولید گزارش سازگار با نسخه مفید است. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 7: ثبت زمان نمونهبرداری کنار داده
در این سناریو هدف این است که ثبت Timestamp کنار هر Snapshot برای تحلیل روند و همبستگی با رخدادهای Performance ضروری است. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SELECT TOP (20)
SYSDATETIME() AS sample_time,
d.*
FROM sys.dm_os_virtual_address_dump AS d;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 7 | Sample-7 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 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_virtual_address_dump;
WAITFOR DELAY '00:00:01';
SELECT TOP (100) * INTO #s2 FROM sys.dm_os_virtual_address_dump;
SELECT
(SELECT COUNT_BIG(*) FROM #s1) AS first_count,
(SELECT COUNT_BIG(*) FROM #s2) AS second_count;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 8 | Sample-8 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 8: در مانیتورینگ واقعی بهتر است فاصله نمونهبرداری بزرگتر و داده در جدول تاریخچه ذخیره شود. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 9: مدیریت خطای دسترسی
در این سناریو هدف این است که این الگو برای اسکریپتهای عملیاتی مناسب است تا خطای Permission یا تفاوت نسخه بهصورت کنترلشده گزارش شود. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
BEGIN TRY
SELECT TOP (5) *
FROM sys.dm_os_virtual_address_dump;
END TRY
BEGIN CATCH
SELECT
ERROR_NUMBER() AS error_number,
ERROR_MESSAGE() AS error_message;
END CATCH;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 9 | Sample-9 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 9: این الگو برای اسکریپتهای عملیاتی مناسب است تا خطای Permission یا تفاوت نسخه بهصورت کنترلشده گزارش شود. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
مثال 10: الگوی کمهزینه برای مانیتورینگ
در این سناریو هدف این است که در Queryهای دورهای باید تعداد ستون و ردیف را محدود کنید و از اجرای تجمیعهای سنگین با فاصله کوتاه بپرهیزید. Query زیر قابل اجرا است و برای محیط واقعی بهتر است ابتدا در سرور تست یا با حجم محدود اجرا شود.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT TOP (10) *
FROM sys.dm_os_virtual_address_dump;
| شاخص | خروجی نمونه | تفسیر |
|---|
| Example 10 | Sample-10 | خروجی نمونه برای sys.dm_os_virtual_address_dump; مقدار واقعی به وضعیت سرور وابسته است. |
نکته فنی مثال 10: در Queryهای دورهای باید تعداد ستون و ردیف را محدود کنید و از اجرای تجمیعهای سنگین با فاصله کوتاه بپرهیزید. هنگام تحلیل نتیجه، مقدار فعلی را با Baseline همان سرور مقایسه کنید؛ مقایسه خام دو سرور با سختافزار و Workload متفاوت میتواند گمراهکننده باشد.
خطاهای رایج و تفسیر اشتباه
یکی از خطاهای رایج در استفاده از sys.dm_os_virtual_address_dump این است که یک مقدار بالا بلافاصله به عنوان مشکل تلقی شود. بسیاری از ساختارهای حافظه با افزایش بار کاری یا Cache طبیعی رشد میکنند. ابتدا بررسی کنید آیا همزمان افت کارایی، Wait مرتبط، Paging یا فشار حافظه مشاهده میشود.
خطای دوم مقایسه مستقیم Snapshotهای نامتجانس است. نمونهای که در ساعت اوج گرفته شده با نمونه شبانه قابل قیاس ساده نیست. زمان، تعداد Sessionها، Batch Requestها و Jobهای سنگین را کنار Snapshot ثبت کنید.
خطای سوم اجرای Queryهای سنگین مانیتورینگ است. خود ابزار تشخیصی نباید به منبع سربار تبدیل شود. روی DMVهای بزرگ ستونها را محدود، تجمیع را با فاصله مناسب اجرا و Retention دادههای تاریخی را مدیریت کنید.
خطای چهارم نادیده گرفتن نسخه SQL Server است. ستونها، مجوزها و رفتار بعضی DMVها در نسخههای مختلف تغییر میکند. اسکریپت Production باید Version-aware باشد و در صورت نبود ستون، خطای قابل فهم تولید کند.
نکات Performance و Best Practice
- ابتدا Query محدود با TOP و ستونهای مشخص اجرا کنید و فقط در زمان نیاز به جزئیات کامل بروید.
- برای تحلیل روند، Snapshot دورهای را در جدول تاریخچه ذخیره کنید و زمان نمونهبرداری را اجباری قرار دهید.
- آستانه ثابت را از اینترنت کپی نکنید؛ Baseline مخصوص همان سرور و Workload بسازید.
- داده این DMV را با حداقل دو منبع دیگر مانند Performance Counter، Wait Statistics یا DMV مکمل همبسته کنید.
- مجوزهای مانیتورینگ را با اصل Least Privilege تخصیص دهید و از اعطای دسترسی بیش از نیاز خودداری کنید.
- پس از تغییر Max Server Memory، NUMA، سختافزار یا تنظیمات سیستمعامل، همان Queryهای Baseline را دوباره اجرا و نتیجه را مقایسه کنید.
برای sys.dm_os_virtual_address_dump مهم است که Query مانیتورینگ در ساعات اوج کمهزینه باقی بماند. اگر نیاز به جزئیات زیاد دارید، نمونهبرداری سنگین را با فاصله بیشتر انجام دهید و در داشبورد از داده ذخیرهشده استفاده کنید، نه اینکه هر Refresh مستقیماً DMV را چندبار اسکن کند.
کاربرد واقعی در پروژههای سازمانی
در یک سامانه مانیتورینگ سازمانی میتوان خروجی منتخب sys.dm_os_virtual_address_dump را همراه ServerName، InstanceName و SampleTime ذخیره کرد. سپس با Window Function یا ابزار BI روندها را نمایش داد و رخدادهای غیرعادی را نسبت به Baseline شناسایی کرد.
در پروژه Capacity Planning، داده تاریخی حافظه باید کنار رشد دیتابیس، تعداد کاربران، Batch Request و ساعات اوج تحلیل شود. این ترکیب مشخص میکند آیا مشکل با تنظیم Query و Index قابل حل است یا ارتقای RAM و معماری سختافزار نیز لازم است.
در خدمات مشاوره Performance، یک DMV بهتنهایی مبنای توصیه نهایی نیست. نتیجه باید با Execution Plan، Query Store، Wait Statistics و تنظیمات Instance تطبیق داده شود تا اقدام اصلاحی به جای درمان علامت، علت اصلی را هدف بگیرد.
سؤالات متداول
sys.dm_os_virtual_address_dump دقیقاً چه چیزی را نشان میدهد؟
نمای تشخیصی از فضای آدرس مجازی فرایند SQL Server برای بررسی رزرو، Commit و نواحی حافظه در سناریوهای عیبیابی پیشرفته. خروجی آن باید در زمینه زمان نمونهبرداری و Workload تفسیر شود.
بهترین نقطه شروع برای یادگیری sys.dm_os_virtual_address_dump چیست؟
ابتدا Syntax پایه و Metadata ستونها را ببینید، سپس دو یا سه ستون کلیدی را در چند Snapshot مقایسه کنید و بعد سراغ Queryهای تحلیلیتر بروید.
آیا sys.dm_os_virtual_address_dump برای مانیتورینگ تجاری مناسب است؟
بله، به شرط آنکه نرخ نمونهبرداری، Retention و سربار Query کنترل شود. در سامانههای حرفهای معمولاً داده منتخب ذخیره و سپس گزارش میشود.
چگونه از sys.dm_os_virtual_address_dump در پروژه Performance Tuning استفاده میشود؟
این DMV یک قطعه از شواهد است. متخصص آن را با Waitها، Query Store، I/O و تنظیمات حافظه ترکیب میکند تا علت اصلی مشخص شود.
sys.dm_os_virtual_address_dump با DMVهای دیگر چه تفاوتی دارد؟
هر DMV سطح متفاوتی از حافظه را نشان میدهد. تفاوت اصلی در Scope داده است؛ برخی سطح سیستم یا فرایند، برخی Clerk، Cache، Buffer Pool یا NUMA را پوشش میدهند.
آیا میتوان برای sys.dm_os_virtual_address_dump Alert ساخت؟
بله، اما Alert بهتر است بر روند یا ترکیب چند شاخص بنا شود. آستانه تکعددی بدون Baseline ممکن است False Positive زیادی ایجاد کند.
رایجترین خطا هنگام استفاده از sys.dm_os_virtual_address_dump چیست؟
تفسیر یک Snapshot به عنوان حقیقت دائمی، اجرای Query سنگین با فاصله کوتاه و فرض یکسان بودن ستونها در همه نسخهها از خطاهای رایج است.
آیا Query کردن sys.dm_os_virtual_address_dump روی Performance اثر دارد؟
Queryهای ساده معمولاً سبک هستند، اما حجم DMV و نوع تجمیع مهم است. SELECT گسترده یا GROUP BY سنگین را با نرخ بالا اجرا نکنید.
Best Practice ذخیره داده sys.dm_os_virtual_address_dump چیست؟
فقط ستونهای لازم را همراه Timestamp و شناسه سرور ذخیره کنید، Index مناسب روی جدول تاریخچه بسازید و Retention مشخص داشته باشید.
آیا sys.dm_os_virtual_address_dump در همه نسخههای SQL Server یکسان است؟
خیر. وجود DMV، ستونها و مجوز لازم میتواند میان نسخهها تفاوت داشته باشد. Metadata و مستندات همان نسخه باید مرجع نهایی اسکریپت Production باشد.
سؤالات مصاحبه
sys.dm_os_virtual_address_dump را در چه سناریویی استفاده میکنید؟ پاسخ حرفهای باید Scope DMV، Query نمونه، روش مقایسه زمانی، محدودیت نسخه و یک اقدام عملی بعدی را پوشش دهد.
چگونه خروجی sys.dm_os_virtual_address_dump را Baseline میکنید؟ پاسخ حرفهای باید Scope DMV، Query نمونه، روش مقایسه زمانی، محدودیت نسخه و یک اقدام عملی بعدی را پوشش دهد.
چه خطاهایی در تفسیر sys.dm_os_virtual_address_dump رخ میدهد؟ پاسخ حرفهای باید Scope DMV، Query نمونه، روش مقایسه زمانی، محدودیت نسخه و یک اقدام عملی بعدی را پوشش دهد.
چگونه سربار مانیتورینگ sys.dm_os_virtual_address_dump را کاهش میدهید؟ پاسخ حرفهای باید Scope DMV، Query نمونه، روش مقایسه زمانی، محدودیت نسخه و یک اقدام عملی بعدی را پوشش دهد.
برای تأیید یافتههای sys.dm_os_virtual_address_dump از چه منابع مکملی استفاده میکنید؟ پاسخ حرفهای باید Scope DMV، Query نمونه، روش مقایسه زمانی، محدودیت نسخه و یک اقدام عملی بعدی را پوشش دهد.
چکلیست نهایی
- مجوز لازم را بررسی کردهام و Query را با حداقل دسترسی اجرا میکنم.
- ستونها و Metadata را روی نسخه واقعی سرور بررسی کردهام.
- Snapshot را با Timestamp ذخیره میکنم و به یک مقدار لحظهای تکیه نمیکنم.
- خروجی را با DMVها و شاخصهای مکمل مقایسه میکنم.
- Query مانیتورینگ را از نظر CPU، I/O و تعداد ردیف محدود کردهام.
- پس از هر تغییر تنظیمات، قبل و بعد را با همان روش اندازهگیری مقایسه میکنم.
جمعبندی
sys.dm_os_virtual_address_dump ابزار ارزشمندی برای فضای آدرس مجازی SQL Server است، اما بیشترین ارزش آن زمانی آشکار میشود که در یک فرآیند عیبیابی ساختاریافته استفاده شود. ابتدا Baseline بسازید، سپس تغییرات را در زمان دنبال کنید و یافتهها را با سایر DMVها و شاخصهای Performance تأیید نمایید.
برای دیدن تصویر کاملتر حافظه، به مقاله مادر DMVهای عملکرد حافظه در SQL Server بازگردید و DMVهای مکمل را نیز بررسی کنید.