راهنمای جامع فرمان‌های DBCC برای کارایی، عیب‌یابی و سلامت SQL Server

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

DBCC Performance and Diagnostic Commands مجموعه‌ای برای سلامت، Cache، حافظه، فایل و عیب‌یابی است. تفاوت اعضا در سطح Session، Database یا Server، ماندگاری داده و میزان اثر بر موتور SQL Server قرار دارد.

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

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

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

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

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

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

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

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

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

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

SELECT name,state_desc,recovery_model_desc FROM sys.databases;

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

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

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

DECLARE @db sysname=DB_NAME(); DBCC CHECKDB(@db) WITH PHYSICAL_ONLY,NO_INFOMSGS;

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

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

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

SELECT name,size*8.0/1024 AS SizeMB FROM sys.database_files;

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

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

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

SELECT objtype,COUNT(*) PlanCount FROM sys.dm_exec_cached_plans GROUP BY objtype;

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

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

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

DBCC OPENTRAN WITH NO_INFOMSGS;

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

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

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

SELECT TOP (20) type,pages_kb FROM sys.dm_os_memory_clerks ORDER BY pages_kb DESC;

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

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

در مرکز عملیات، خانواده DBCC Performance and Diagnostic Commands به 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. گزارش مالک اقدام بعدی را مشخص کند.

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

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

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

DBCC Performance and Diagnostic Commands چه مسئله‌ای را حل می‌کند؟

برای سلامت، Cache، حافظه، فایل و عیب‌یابی در Scope مشخص استفاده می‌شود و خروجی آن باید به تصمیم قابل سنجش منجر شود.

DBCC Performance and Diagnostic Commands پیش‌نیاز یادگیری چیست؟

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

DBCC Performance and Diagnostic Commands هزینه پنهان سازمانی چیست؟

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

DBCC Performance and Diagnostic Commands خروجی پروژه حرفه‌ای چیست؟

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

DBCC Performance and Diagnostic Commands با روش جایگزین چه تفاوتی دارد؟

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

DBCC Performance and Diagnostic Commands چه زمانی مشاوره تخصصی لازم است؟

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

DBCC Performance and Diagnostic Commands رایج‌ترین خطا چیست؟

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

DBCC Performance and Diagnostic Commands اثر Performance چگونه کنترل می‌شود؟

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

DBCC Performance and Diagnostic Commands Best Practice اصلی چیست؟

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

DBCC Performance and Diagnostic Commands سازگاری نسخه چگونه بررسی می‌شود؟

مستندات همان 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. مالک اقدام ثبت شده است.