مقدمه

آمار انتظار یا Wait Statistics یکی از مهم‌ترین نماهای تشخیصی SQL Server است. هر Worker هنگام اجرای درخواست ممکن است برای دریافت CPU، خواندن صفحه از Storage، نوشتن Transaction Log، آزاد شدن Lock، هماهنگی Parallelism یا یک منبع داخلی متوقف شود. موتور پایگاه داده این توقف‌ها را به تفکیک wait_type جمع می‌کند و از طریق نمای sys.dm_os_wait_stats در اختیار مدیر پایگاه داده قرار می‌دهد. این داده مانند نقشه‌ای از محل مصرف زمان است؛ اما نقشه فقط مسیر تحقیق را نشان می‌دهد و به‌تنهایی حکم نهایی درباره علت کندی صادر نمی‌کند.

دستور DBCC SQLPERF با گزینه sys.dm_os_wait_stats و CLEAR تمام شمارنده‌های تجمعی آمار انتظار را بازنشانی می‌کند. این فرمان تنظیم Performance، پاک‌کردن Cache یا رفع Blocking نیست. کاربرد درست آن ایجاد یک نقطه شروع مشخص برای آزمایش کنترل‌شده، Release مهم، اجرای Batch یا بازه عیب‌یابی است. کاربرد نادرست آن نیز پاک کردن شتاب‌زده شواهد در زمان Incident، بدون Snapshot و بدون هماهنگی با تیم مانیتورینگ است.

این مقاله مفهوم شمارنده‌های تجمعی، اثر CLEAR، مجوزها، روش امن Snapshot، تحلیل دلتا و سناریوهای عملی را توضیح می‌دهد. برای بررسی نحو، پارامترها، خطاها و ده مثال مستقل فرمان اصلی نیز آموزش کامل DBCC SQLPERF برای پاک‌سازی sys.dm_os_wait_stats را بخوانید.

دسترسی سریع به مطالب

• شناخت دامنه و ماهیت تجمعی Wait Statistics
• تصمیم‌گیری درباره زمان مناسب یا نامناسب CLEAR
• گرفتن Baseline و محاسبه Delta بدون حذف تاریخچه
• اجرای شش مثال عملی از مشاهده تا اعتبارسنجی
• ورود به مقاله تخصصی دستور DBCC SQLPERF با ده مثال اجرایی

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

SQL Server کار هر درخواست را میان Schedulerها و Workerها توزیع می‌کند. وقتی Worker نتواند ادامه دهد، نوع انتظار و مدت آن ثبت می‌شود. ستون waiting_tasks_count تعداد رخدادها، wait_time_ms زمان کل، max_wait_time_ms بیشترین انتظار منفرد و signal_wait_time_ms بخشی از زمان را نشان می‌دهد که کار آماده اجرا بوده اما هنوز CPU نگرفته است. کم کردن signal_wait_time_ms از wait_time_ms تصویری تقریبی از زمان انتظار منبع می‌دهد.

مقادیر DMV از آخرین شروع Database Engine یا آخرین بازنشانی تجمع یافته‌اند و بعد از Restart پایدار نمی‌مانند. بنابراین عدد بزرگ لزوماً مشکل جاری نیست؛ ممکن است حاصل چند هفته فعالیت سالم باشد. برای تفسیر حرفه‌ای باید زمان شروع سرور، طول بازه، حجم تراکنش و تغییرات Workload معلوم باشد. نرخ انتظار در دقیقه یا به ازای هر تراکنش معمولاً از عدد خام گویاتر است.

برخی Waitها فعالیت عادی سرویس‌های پس‌زمینه را بازتاب می‌دهند و باید متناسب با نسخه و هدف گزارش فیلتر شوند. حذف کورکورانه یک فهرست اینترنتی نیز خطرناک است، چون انتظار بی‌اهمیت در یک سیستم شاید در سیستم دیگر نشانه فشار واقعی باشد. روش قابل دفاع این است که ابتدا انتظارهای غالب یک پنجره مشخص شناسایی شوند، سپس برای هر کدام شواهد مرتبط مانند Latency دیسک، Blocking Chain، CPU Runnable Queue و Planهای پرهزینه جمع‌آوری گردد.

اصل عملیاتی: پیش از هر CLEAR، یک Snapshot زمان‌دار و قابل بازیابی ذخیره کنید؛ در غیر این صورت بخشی از حافظه تشخیصی نمونه را عمداً از بین برده‌اید.

پاک‌سازی دقیقاً چه کاری انجام می‌دهد؟

فرمان DBCC SQLPERF فقط شمارنده‌های مرتبط با sys.dm_os_wait_stats را صفر می‌کند. Sessionها قطع نمی‌شوند، تراکنش‌ها Rollback نمی‌شوند، قفل‌ها آزاد نمی‌گردند و Plan Cache یا Buffer Pool پاک نمی‌شود. پس اگر مشکل فعالی مانند Blocking یا I/O کند وجود داشته باشد، پس از فرمان نیز ادامه خواهد یافت و شمارنده‌های جدید دوباره رشد می‌کنند.

دامنه این آمار به محیط اجرای SQL Server وابسته است. در یک Instance معمولی، تحلیل و بازنشانی در سطح Server معنا دارد؛ در سرویس‌های ابری دامنه مشاهده و الزامات دسترسی می‌تواند با Tier و مدل سرویس متفاوت باشد. اسکریپت عملیاتی باید محیط را شناسایی کند و نباید فرض کند مجوزی که در سرور On-Premises کار می‌کند در همه سرویس‌ها دقیقاً همان رفتار را دارد.

پاک‌سازی همچنین زمان رخداد را در خود DMV ثبت نمی‌کند. اگر Audit جداگانه نداشته باشید، تحلیلگر بعدی ممکن است افت ناگهانی نمودار را با Restart یا خرابی جمع‌آوری اشتباه بگیرد. حداقل نام Server، Login اجراکننده، زمان UTC و محلی، Ticket یا Change ID، دلیل اجرا و محل Snapshot قبلی را ثبت کنید.

در سرور پرترافیک انتظار نداریم نتیجه SELECT بعدی کاملاً صفر باشد. فاصله میان پایان DBCC و خواندن DMV برای ثبت انتظارهای تازه کافی است. به جای آزمون صفر مطلق، زمان بازنشانی را ثبت کنید و بررسی نمایید که مقادیر قدیمی حذف شده و نرخ جدید از همان مرز زمانی محاسبه می‌شود.

موضوع تخصصی این مجموعه

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR)

این دستور روش رسمی بازنشانی شمارنده‌های Wait در SQL Server است. آرگومان متنی نام DMV هدف را تعیین می‌کند و کلمه CLEAR عملیات Reset را درخواست می‌دهد. گزینه WITH NO_INFOMSGS نیز برای اجرای خودکار و کم‌کردن پیام‌های اطلاعاتی قابل استفاده است.

فرمان باید با حسابی اجرا شود که ALTER SERVER STATE دارد. چون اثر آن روی داده تشخیصی مشترک نمونه است، اجرای Production بهتر است از مسیر Runbook مصوب و با ثبت Snapshot انجام شود، نه از پنجره Query شخصی و بدون ردپا.

آموزش تخصصی DBCC SQLPERF، مجوزها، خطاها و ده مثال عملی

فرایند پیشنهادی پیش از اجرا

1. هدف را روشن کنید: آزمایش، Release، Incident یا شروع یک پنجره اندازه‌گیری.
2. زمان شروع SQL Server و آخرین Snapshot معتبر را بررسی کنید.
3. شمارنده‌های فعلی را همراه waiting_tasks_count، wait_time_ms و signal_wait_time_ms ذخیره کنید.
4. با تیم‌های DBA، مانیتورینگ و مالک سرویس هماهنگ شوید تا نمودارها درست تفسیر شوند.
5. فرمان را با حساب کنترل‌شده و حداقل دسترسی لازم اجرا کنید.
6. زمان Reset را ممیزی کنید و پس از بازه تعیین‌شده Snapshot دوم و تحلیل Delta بسازید.

مثال‌های عملی پاک‌سازی و اندازه‌گیری

SELECT TOP (10)
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    signal_wait_time_ms,
    wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0
ORDER BY wait_time_ms DESC;

SELECT
    sqlserver_start_time,
    SYSDATETIME() AS captured_at,
    DATEDIFF(MINUTE, sqlserver_start_time, SYSDATETIME()) AS uptime_minutes
FROM sys.dm_os_sys_info;

SELECT
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    signal_wait_time_ms,
    SYSDATETIME() AS captured_at
INTO #WaitStatsBeforeClear
FROM sys.dm_os_wait_stats
WHERE waiting_tasks_count > 0;

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);

SELECT COUNT(*) AS saved_wait_types
FROM #WaitStatsBeforeClear;

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) WITH NO_INFOMSGS;

SELECT N'Wait statistics cleared' AS operation_status,
       SYSDATETIME() AS completed_at;

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) WITH NO_INFOMSGS;

SELECT
    COUNT_BIG(*) AS active_wait_types_after_clear,
    SUM(waiting_tasks_count) AS tasks_after_clear,
    SUM(wait_time_ms) AS wait_ms_after_clear
FROM sys.dm_os_wait_stats
WHERE waiting_tasks_count > 0;

SELECT wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms
INTO #WaitStart
FROM sys.dm_os_wait_stats;

WAITFOR DELAY '00:00:05';

SELECT wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms
INTO #WaitEnd
FROM sys.dm_os_wait_stats;

SELECT TOP (10)
    e.wait_type,
    e.waiting_tasks_count - s.waiting_tasks_count AS delta_tasks,
    e.wait_time_ms - s.wait_time_ms AS delta_wait_ms,
    e.signal_wait_time_ms - s.signal_wait_time_ms AS delta_signal_ms
FROM #WaitEnd AS e
JOIN #WaitStart AS s ON s.wait_type = e.wait_type
WHERE e.wait_time_ms > s.wait_time_ms
ORDER BY delta_wait_ms DESC;

تفسیر گروه‌های مهم انتظار

فشار CPU و زمان Signal

رشد signal_wait_time_ms و انتظارهایی مانند SOS_SCHEDULER_YIELD می‌تواند نیاز به بررسی فشار CPU، Queryهای پرمصرف، Parallelism و تعداد Workerهای Runnable را مطرح کند. این نشانه به‌تنهایی به معنی کمبود سخت‌افزار نیست؛ طرح اجرای نامناسب، Cardinality اشتباه یا Scan بزرگ نیز می‌تواند CPU را مصرف کند.

انتظارهای I/O

خانواده PAGEIOLATCH معمولاً زمان انتظار برای ورود صفحات داده از Storage به Buffer Pool را نشان می‌دهد و WRITELOG به مسیر Flush شدن Log مرتبط است. تحلیل باید Latency فایل، الگوی Read و Write، اندازه و رشد فایل، Plan Query و فشار حافظه را کنار هم قرار دهد. پاک‌سازی این شمارنده‌ها هیچ I/O را سریع‌تر نمی‌کند.

Blocking و Lock

انتظارهای LCK_M نشان می‌دهند یک درخواست برای Lock سازگار منتظر مانده است. Snapshot تجمعی می‌گوید Blocking چقدر زمان مصرف کرده اما معمولاً Blocker فعلی را نگه نمی‌دارد؛ Extended Events، DMVs نشست‌ها و ابزار مانیتورینگ برای زنجیره زنده لازم‌اند. قبل از CLEAR، زمان و الگوی انتظارهای Lock را ثبت کنید.

Parallelism

CXPACKET و CXCONSUMER باید در متن Plan موازی، توزیع کار میان Threadها، هزینه Query و تنظیمات MAXDOP تحلیل شوند. بالا بودن شمارنده تجمعی در سامانه‌ای با گزارش‌های موازی طبیعی می‌تواند باشد. تمرکز بر Queryهایی که بیشترین CPU و زمان را در پنجره مورد نظر مصرف کرده‌اند از تغییر تنظیم عمومی بر اساس یک ردیف امن‌تر است.

چه زمانی CLEAR منطقی است؟

• پس از ذخیره Baseline و درست پیش از یک آزمایش Performance کنترل‌شده.
• در آغاز پنجره Benchmark که Workload، مدت و معیار موفقیت آن از قبل تعریف شده است.
• بعد از یک تغییر بزرگ زیرساختی، وقتی تیم عمداً می‌خواهد رفتار دوره جدید را جدا اندازه بگیرد.
• در Runbook رخداد، تنها اگر Snapshot قبلی حفظ شده و مسئول Incident اجازه داده باشد.
• در محیط آزمایش و آموزش برای نمایش رشد شمارنده‌ها از نقطه صفر.

چه زمانی نباید CLEAR کرد؟

• هنگام کندی ناشناخته، پیش از اینکه شواهد لازم جمع‌آوری شود.
• برای زیباتر شدن Dashboard یا پنهان کردن Waitهای بزرگ تاریخی.
• به صورت Job روزانه بدون نیاز تحلیلی و بدون ذخیره Snapshot.
• با این تصور که فرمان Cache، Lock یا Query بد را اصلاح می‌کند.
• وقتی چند تیم از همان تاریخچه برای Trend و Capacity Planning استفاده می‌کنند و هماهنگی نشده است.

امنیت، مجوز و حاکمیت عملیاتی

بازنشانی Wait و Latch Statistics به ALTER SERVER STATE نیاز دارد. این مجوز گسترده‌تر از خواندن ساده DMV است؛ بنابراین اعطای دائمی آن به حساب‌های انسانی متعدد توصیه نمی‌شود. یک Stored Procedure امضاشده، Job کنترل‌شده یا حساب عملیاتی با ممیزی می‌تواند سطح دسترسی و مسیر اجرا را محدود کند.

خود فرمان داده تجاری را تغییر نمی‌دهد، اما Telemetry مشترک را تغییر می‌دهد و از این جهت یک عملیات حساس تشخیصی است. سازمان‌های دارای SLA یا الزامات ممیزی باید Reset را در Change Log ثبت کنند. اگر پاک‌سازی بدون ثبت انجام شود، گزارش قبل و بعد ممکن است نرخ‌های اشتباه یا افت مصنوعی نشان دهد.

در Azure SQL Database و Managed Instance مدل Permission و دامنه DMV با SQL Server نصب‌شده یکسان نیست. پیش از استفاده در Automation، مستندات همان سرویس و Tier را کنترل و Script را در محیط غیرتولیدی آزمایش کنید. شکست مجوز نباید با اجرای حسابی بیش‌ازحد قدرتمند و دائمی دور زده شود.

خطاهای رایج در تحلیل

• مقایسه عدد تجمعی دو سرور با Uptime متفاوت، بدون تبدیل آن به نرخ.
• در نظر گرفتن بالاترین Wait به عنوان علت ریشه‌ای قطعی.
• حذف Waitهای پس‌زمینه با فهرستی ثابت و بدون توجه به نسخه و Workload.
• اجرای CLEAR قبل از Snapshot و از بین بردن تنها شاهد موجود از Incident.
• انتظار صفر مطلق بلافاصله بعد از Reset در یک Instance فعال.
• نادیده گرفتن Restart و نسبت دادن افت شمارنده‌ها به بهبود Performance.
• بهینه‌سازی تنظیمات Server بدون یافتن Query یا منبعی که Wait را ایجاد کرده است.

نکات کارایی و بهترین روش‌ها

خواندن sys.dm_os_wait_stats معمولاً سبک است، اما جمع‌آوری بسیار پرتکرار، نگهداری بی‌حد داده و گزارش‌های پیچیده روی مخزن مانیتورینگ هزینه ایجاد می‌کند. فاصله نمونه‌برداری را با هدف هماهنگ کنید؛ برای داشبورد عملیاتی یک تا پنج دقیقه و برای Trend ظرفیت بازه بزرگ‌تر ممکن است کافی باشد. همیشه زمان UTC، زمان محلی، نام نمونه و نسخه موتور را ذخیره کنید.

به جای Reset دوره‌ای، Snapshotهای پیوسته و Delta را مبنای تحلیل قرار دهید. Counter Reset یک Event است و باید در مدل داده مانیتورینگ ثبت شود. الگوریتم محاسبه دلتا باید منفی شدن شمارنده را تشخیص دهد؛ مقدار منفی معمولاً نشانه Restart، CLEAR یا تعویض دامنه مشاهده است و نباید مانند کاهش واقعی Wait گزارش شود.

برای رسیدن از Wait به اقدام، یک مسیر شواهد تعریف کنید: ابتدا گروه غالب در پنجره، سپس Queryها و Sessionهای مرتبط، بعد منبع زیرساختی و در پایان تغییر قابل آزمون. موفقیت تغییر را با همان بازه و Workload قابل مقایسه بسنجید. این چرخه از تنظیمات حدسی، افزودن سخت‌افزار بی‌دلیل و درمان نشانه به جای علت جلوگیری می‌کند.

طراحی مخزن مانیتورینگ حرفه‌ای

جدول Snapshot بهتر است کلید زمان، ServerName، InstanceName، sqlserver_start_time، wait_type، waiting_tasks_count، wait_time_ms، signal_wait_time_ms و شناسه Collector را داشته باشد. یک جدول Event جدا نیز زمان Restart، CLEAR، Failover، Deployment و تغییر پیکربندی را ذخیره کند. اتصال این دو مجموعه اجازه می‌دهد مرزهای معتبر محاسبه دلتا مشخص شوند.

در لایه گزارش، هم مقدار خام و هم Delta نمایش داده شود. درصد سهم یک Wait از کل زمان مفید است، اما اگر مخرج شامل Waitهای Idle باشد می‌تواند گمراه‌کننده شود. فیلترها باید مستند، قابل نسخه‌بندی و قابل بازگشت باشند. برای Capacity Planning روند چند هفته‌ای و برای Incident پنجره دقیقه‌ای لازم است؛ یک نمودار واحد پاسخ هر دو نیاز را نمی‌دهد.

هشدار نیز بهتر است بر نرخ، تداوم و هم‌بستگی بنا شود، نه صرف عبور یک شمارنده تجمعی از حد ثابت. برای نمونه، افزایش پایدار WRITELOG همراه Latency بالای فایل Log و رشد مدت Commit سیگنال قوی‌تری از عدد بزرگ WRITELOG به‌تنهایی است. تیم مشاوره یا پروژه SQL Server نیز با همین داده منظم می‌تواند پیشنهاد قابل اندازه‌گیری ارائه کند.

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

آمار انتظار در SQL Server دقیقاً چه چیزی را نشان می‌دهد؟

این آمار مدت و تعداد دفعاتی را ثبت می‌کند که Workerهای SQL Server برای منابع یا زمان CPU منتظر مانده‌اند. داده‌ها سرنخ سطح نمونه هستند و برای رسیدن به علت ریشه‌ای باید با Query Store، طرح اجرا، شمارنده‌های سیستم‌عامل و وضعیت ذخیره‌سازی ترکیب شوند.

آیا پاک‌سازی آمار انتظار باعث سریع‌تر شدن سرور می‌شود؟

خیر. پاک‌سازی فقط شمارنده‌های تشخیصی را صفر می‌کند و هیچ قفل، حافظه، Plan Cache یا عملیات کاربری را برطرف نمی‌سازد. ارزش آن در ایجاد یک خط شروع روشن برای اندازه‌گیری آزمایش یا رخداد بعدی است.

برای CLEAR چه مجوزی لازم است؟

در SQL Server، بازنشانی آمار انتظار و Latch به مجوز ALTER SERVER STATE در سطح Server نیاز دارد. بهتر است این اختیار فقط به حساب عملیاتی کنترل‌شده داده شود و اجرای فرمان ثبت و ممیزی گردد.

آیا می‌توان فقط یک نوع Wait را پاک کرد؟

دستور DBCC SQLPERF برای sys.dm_os_wait_stats همه شمارنده‌های این DMV را در سطح محدوده مربوط بازنشانی می‌کند و انتخاب یک wait_type منفرد ندارد. برای تحلیل انتخابی، Snapshot بگیرید و در Query گزارش فیلتر اعمال کنید.

CLEAR چه تفاوتی با Restart سرویس دارد؟

هر دو باعث شروع مجدد شمارنده‌های تجمعی Wait می‌شوند، اما Restart تمام موتور را متوقف و راه‌اندازی می‌کند و آثار بسیار گسترده‌تری مانند از دست رفتن Cache گرم دارد. برای صفر کردن شمارنده‌ها هرگز Restart راه‌حل مناسبی نیست.

آیا پاک‌سازی برای گزارش SLA مناسب است؟

تنها زمانی مناسب است که زمان، دلیل و مسئول اجرا ثبت شود و سامانه گزارش‌گیری از مرز جدید آگاه باشد. در غیر این صورت نمودارهای بلندمدت شکسته می‌شوند و امکان مقایسه روند از بین می‌رود؛ ذخیره Snapshot معمولاً گزینه امن‌تری است.

چرا بلافاصله پس از CLEAR باز هم عدد غیرصفر دیده می‌شود؟

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

آیا پاک‌سازی روی کارایی Queryهای در حال اجرا اثر مستقیم دارد؟

خود فرمان عملیات سبک مدیریتی است و Queryهای در حال اجرا را درمان نمی‌کند. با این حال اجرای مدیریتی باید در زمان کنترل‌شده انجام شود، چون از نظر فرایندی تاریخچه تشخیصی مشترک همه تیم‌ها را تغییر می‌دهد.

بهترین روش برای تحلیل Performance بدون از دست دادن تاریخچه چیست؟

Snapshotهای زمان‌دار را در جدول مانیتورینگ ذخیره کنید و دلتا را بین دو نمونه محاسبه نمایید. این روش هم روند بلندمدت را نگه می‌دارد و هم می‌تواند پنجره‌های بار، Release یا Incident را جداگانه مقایسه کند.

این دستور با کدام نسخه‌های SQL Server سازگار است؟

DBCC SQLPERF و گزینه پاک‌سازی sys.dm_os_wait_stats در نسخه‌های پشتیبانی‌شده SQL Server در دسترس است و مستندات جدید Microsoft آن را برای SQL Server، Azure SQL Database و Azure SQL Managed Instance پوشش می‌دهد؛ سطح دسترسی و دامنه مشاهده در سرویس‌های ابری می‌تواند متفاوت باشد.

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

چرا مجموع wait_time_ms را نباید به‌تنهایی علت کندی بدانیم؟

زیرا شمارنده تجمعی، مدت فعالیت سرور و تعداد Workerها را نیز در خود دارد. ابتدا باید بازه را مشخص کرد، انتظارهای Idle را کنار گذاشت، دلتا و نرخ را محاسبه کرد و سپس شواهد لایه Query و سیستم را بررسی نمود.

تفاوت signal wait و resource wait چیست؟

signal wait زمانی است که Worker پس از آماده شدن منبع، برای دریافت زمان CPU در صف Runnable می‌ماند. resource wait بخش دیگر زمان است که واقعاً صرف انتظار برای منبعی مانند I/O، Lock یا Log شده است.

در چه سناریویی CLEAR را تأیید می‌کنید؟

پس از ذخیره Baseline، در آزمایش کنترل‌شده‌ای که شروع و پایان روشن دارد؛ مثلاً پیش و پس از تغییر ایندکس یا تنظیم Storage. در Incident ناشناخته و بدون Snapshot، انجام آن شواهد را از بین می‌برد.

چگونه متوجه می‌شوید شمارنده‌ها با Restart صفر شده‌اند؟

زمان sqlserver_start_time را از sys.dm_os_sys_info ثبت و با زمان نمونه‌های مانیتورینگ مقایسه می‌کنم. هر تغییر در زمان شروع، یک مرز جدید برای سری تجمعی است.

چرا فهرست ثابت Waitهای خوب و بد کافی نیست؟

معنای Wait به Workload، نسخه، معماری و نرخ آن وابسته است. برخی Waitهای پس‌زمینه طبیعی‌اند و یک Wait مشابه ممکن است در دو سامانه دلایل متفاوتی داشته باشد؛ بنابراین Context و هم‌بستگی شواهد ضروری است.

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

1. هدف و طول پنجره اندازه‌گیری مشخص است.
2. زمان شروع SQL Server ثبت شده است.
3. Snapshot کامل پیش از CLEAR ذخیره شده است.
4. مالک سرویس و تیم مانیتورینگ از Reset آگاه‌اند.
5. حساب اجراکننده مجوز کنترل‌شده ALTER SERVER STATE دارد.
6. زمان، Login، Server و Change ID ممیزی می‌شود.
7. انتظار صفر مطلق به عنوان معیار موفقیت استفاده نمی‌شود.
8. Snapshot انتهای پنجره و Delta تولید خواهد شد.
9. تحلیل Wait با Query، Plan و شاخص‌های زیرساختی ترکیب می‌شود.
10. نتیجه تغییر با Baseline قابل مقایسه گزارش می‌گردد.

جمع‌بندی

پاک‌سازی آمار انتظار یک ابزار اندازه‌گیری است، نه ابزار درمان. تصمیم حرفه‌ای از حفظ شواهد آغاز می‌شود: ابتدا Snapshot، سپس ثبت مرز زمانی، اجرای کنترل‌شده و در پایان تحلیل Delta. اگر این زنجیره رعایت شود، شمارنده‌های تازه می‌توانند اثر یک Release، تغییر ایندکس یا پنجره بار را شفاف کنند؛ در غیر این صورت CLEAR فقط تاریخچه ارزشمند را حذف می‌کند.

برای Syntax کامل، مجوزها، سناریوهای خطا، رفتار NULL، ثبت Audit و مثال Performance، مقاله جامع DBCC SQLPERF برای Reset کردن Wait Statistics را مطالعه کنید.