راهنمای جامع DMVهای پایش کارایی و مصرف فضای TempDB در SQL Server

تعریف مجموعه و جایگاه معماری

TempDB Performance DMVs مجموعه‌ای برای ظرفیت TempDB، Session، Task و Version Store است. تفاوت اعضا در سطح Session، Database یا Server، ماندگاری داده و میزان اثر بر موتور SQL Server قرار دارد.

مدل انتخاب چهار پرسش دارد: مشاهده یا تغییر؟ Scope چیست؟ خروجی لحظه‌ای یا ماندگار است؟ و در صورت شکست چه Rollbackی وجود دارد؟

هیچ عضو مجموعه به‌تنهایی علت ریشه‌ای را اثبات نمی‌کند؛ داده باید با زمان، بار کاری، Plan، Wait، Log و تنظیمات نسخه هم‌بسته شود.

نقشه نخست نمای Bird’s-eye اعضای خانواده را همراه محور مقایسه سربار، Scope و قابلیت خودکارسازی نمایش می‌دهد.

دسته‌بندی اعضا و لینک آموزش

جدول مقایسه تصمیم‌محور

معماری اجرا و اعتبارسنجی

جریان دوم از تعریف مسئله به کنترل مجوز، Snapshot، تفسیر و تأیید با منبع دوم می‌رسد.

شش مثال ترکیبی

مثال ترکیبی 1: سناریوی ترکیبی 1

این Query یک نمای هماهنگ از خانواده 31 برای تصمیم مرحله 1 می‌سازد.

SELECT * FROM sys.dm_db_file_space_usage;

مثال 1 نقش هماهنگ‌کننده دارد و جایگزین Syntax و هشدارهای مقاله تخصصی نیست.

مثال ترکیبی 2: سناریوی ترکیبی 2

این Query یک نمای هماهنگ از خانواده 31 برای تصمیم مرحله 2 می‌سازد.

SELECT TOP (20) * FROM sys.dm_db_session_space_usage;

مثال 2 نقش هماهنگ‌کننده دارد و جایگزین Syntax و هشدارهای مقاله تخصصی نیست.

مثال ترکیبی 3: سناریوی ترکیبی 3

این Query یک نمای هماهنگ از خانواده 31 برای تصمیم مرحله 3 می‌سازد.

SELECT TOP (20) * FROM sys.dm_db_task_space_usage;

مثال 3 نقش هماهنگ‌کننده دارد و جایگزین Syntax و هشدارهای مقاله تخصصی نیست.

مثال ترکیبی 4: سناریوی ترکیبی 4

این Query یک نمای هماهنگ از خانواده 31 برای تصمیم مرحله 4 می‌سازد.

SELECT * FROM sys.dm_tran_active_snapshot_database_transactions;

مثال 4 نقش هماهنگ‌کننده دارد و جایگزین Syntax و هشدارهای مقاله تخصصی نیست.

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

این Query یک نمای هماهنگ از خانواده 31 برای تصمیم مرحله 5 می‌سازد.

SELECT TOP (20) * FROM sys.dm_tran_top_version_generators;

مثال 5 نقش هماهنگ‌کننده دارد و جایگزین Syntax و هشدارهای مقاله تخصصی نیست.

مثال ترکیبی 6: سناریوی ترکیبی 6

این Query یک نمای هماهنگ از خانواده 31 برای تصمیم مرحله 6 می‌سازد.

SELECT * FROM sys.dm_tran_persistent_version_store_stats;

مثال 6 نقش هماهنگ‌کننده دارد و جایگزین Syntax و هشدارهای مقاله تخصصی نیست.

سناریوهای واقعی

در مرکز عملیات، خانواده TempDB Performance DMVs به Runbook پاسخ سریع، گزارش ظرفیت و تحلیل پس از Incident تبدیل می‌شود. هر Runbook مالک، زمان، Query کم‌خطر و شرط Escalation دارد.

در پروژه حرفه‌ای، جدول Snapshot، Retention، داشبورد، آستانه هشدار، مستندات مجوز و آموزش تیم جزو خروجی هستند.

در آموزش، هنرجو باید ابزار نامناسب را رد کند، عضو درست را برگزیند و نتیجه را با منبع دوم تأیید نماید.

اشتباهات رایج

• انتخاب بر اساس عادت به‌جای Scope؛ از جدول مقایسه استفاده کنید.
• اجرای چند Query سنگین بدون Baseline؛ نمونه‌برداری مرحله‌ای انجام دهید.
• نادیده‌گرفتن Reset داده؛ زمان Capture را ذخیره کنید.
• ترکیب مشاهده و تغییر؛ دو Runbook مستقل بسازید.
• نسبت‌دادن خروجی به علت؛ با Plan، Wait یا Log اعتبارسنجی کنید.

Performance Considerations

هزینه مجموعه از نرخ نمونه‌برداری، حجم Snapshot و پردازش گزارش تشکیل می‌شود. Queryهای حجیم را از Backup، ETL و CHECKDB جدا زمان‌بندی کنید.

برای داشبورد، داده را در Staging ذخیره و روی زمان، DatabaseID، SessionID یا FileID ایندکس کنید. Retention بر اساس نیاز Trend تعیین شود.

پاک‌سازی Cache یا Shrink نباید در حلقه پایش خودکار باشد؛ Automation فقط شناسایی و پیشنهاد بسازد و اجرای پرریسک نیازمند Approval باشد.

Best Practices

1. Scope و Permission هر عضو مستند شود.
2. Queryها پارامتری و محدود باشند.
3. Snapshot با نام سرور و زمان ذخیره شود.
4. آستانه از Baseline واقعی استخراج شود.
5. ابزار Deprecated نقشه مهاجرت داشته باشد.
6. اقدام تغییردهنده Approval و Rollback داشته باشد.
7. گزارش مالک اقدام بعدی را مشخص کند.

برد تصمیم سوم گزینه کم‌هزینه، نیازمند بررسی و پرریسک را از هم جدا می‌کند.

مزایا و محدودیت‌ها

سؤالات متداول

TempDB Performance DMVs چه مسئله‌ای را حل می‌کند؟

برای ظرفیت TempDB، Session، Task و Version Store در Scope مشخص استفاده می‌شود و خروجی آن باید به تصمیم قابل سنجش منجر شود.

TempDB Performance DMVs پیش‌نیاز یادگیری چیست؟

آشنایی با T-SQL، Session، Transaction و خواندن خروجی‌های تشخیصی کافی است.

TempDB Performance DMVs هزینه پنهان سازمانی چیست؟

زمان تحلیل، سربار نمونه‌برداری و ریسک اقدام نادرست باید در طراحی Runbook دیده شود.

TempDB Performance DMVs خروجی پروژه حرفه‌ای چیست؟

Query نسخه‌بندی‌شده، Snapshot، معیار هشدار، Runbook و آموزش تیم بهره‌بردار خروجی مناسب هستند.

TempDB Performance DMVs با روش جایگزین چه تفاوتی دارد؟

Scope، ماندگاری داده، سربار، نسخه و قابلیت Rollback معیار مقایسه هستند.

TempDB Performance DMVs چه زمانی مشاوره تخصصی لازم است؟

در Production، SLA سخت، داده حساس یا عملیات اثرگذار بر Cache و فایل، بازبینی متخصص ضروری است.

TempDB Performance DMVs رایج‌ترین خطا چیست؟

اجرای بدون Baseline و تفسیر یک Snapshot به‌عنوان علت قطعی، خطای متداول است.

TempDB Performance DMVs اثر Performance چگونه کنترل می‌شود؟

با TOP، Filter، نرخ نمونه‌برداری، پنجره اجرا و مقایسه قبل و بعد کنترل می‌شود.

TempDB Performance DMVs Best Practice اصلی چیست؟

ابتدا مشاهده کم‌هزینه، سپس اعتبارسنجی با منبع دوم و در پایان اقدام محدود انجام شود.

TempDB Performance DMVs سازگاری نسخه چگونه بررسی می‌شود؟

مستندات همان Edition و نسخه نصب‌شده، به‌ویژه نام مجوزها و ستون‌های DMV، کنترل شود.

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

Scope اعضا چگونه مقایسه می‌شود؟

سطح Session، Database یا Server، زمان Reset و ماندگاری خروجی مقایسه می‌شود.

ریسک اقدام چگونه کنترل می‌شود؟

Baseline، Approval، Backup، Scope محدود و Rollback تعریف می‌شوند.

چرا یک ابزار کافی نیست؟

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

پایش چگونه مقیاس‌پذیر می‌شود؟

Snapshot دوره‌ای، Staging، Index و Retention کنترل‌شده به کار می‌رود.

Deprecated چگونه مدیریت می‌شود؟

Inventory، مقصد مهاجرت، آزمایش تطبیقی و تاریخ خاموشی ثبت می‌شود.

خروجی مدیریتی چیست؟

وضعیت، روند، ریسک، مالک اقدام و موعد بازبینی ارائه می‌شود.

چک‌لیست نهایی

1. مسئله و Scope مشخص است.
2. عضو مناسب انتخاب شده است.
3. مجوز و نسخه کنترل شده‌اند.
4. Baseline موجود است.
5. مشاهده از تغییر جداست.
6. نتیجه با منبع دوم تأیید می‌شود.
7. مقاله فرزند خوانده شده است.
8. مالک اقدام ثبت شده است.