مقدمه

دستور DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) ابزار رسمی SQL Server برای بازنشانی شمارنده‌های تجمعی Wait Statistics است. این دستور برای ساختن یک مرز زمانی تازه در Benchmark، آزمون تغییر پیکربندی یا عیب‌یابی کنترل‌شده کاربرد دارد. فرمان به معنی بهینه‌سازی خودکار نیست و اجرای آن هیچ Query کند، Lock، I/O یا فشار CPU را برطرف نمی‌کند.

خطر اصلی فرمان از دست رفتن داده تشخیصی قبلی است. اگر تیم بدون Snapshot آن را اجرا کند، دیگر نمی‌توان سهم Waitهای دوره قبل را از همان DMV بازیابی کرد. به همین دلیل اجرای حرفه‌ای شامل ذخیره Baseline، ثبت زمان و هویت، هماهنگی با مانیتورینگ و گرفتن نمونه بعدی در انتهای پنجره است.

برای دید کلی‌تر درباره تحلیل Wait، تشخیص زمان مناسب Reset و طراحی مخزن Delta به راهنمای جامع پاک‌سازی آمار انتظار در SQL Server بازگردید.

تعریف و Syntax

DBCC SQLPERF چند کاربرد دارد: نمایش مصرف فضای Transaction Log و بازنشانی آمار Wait یا Latch. در این مقاله فقط شاخه sys.dm_os_wait_stats بررسی می‌شود. عبارت CLEAR عمل بازنشانی را مشخص می‌کند و نام DMV باید به صورت Literal معتبر در فرمان نوشته شود.

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

پارامترها، خروجی و دامنه اثر

این شکل فرمان پارامتر عددی، فیلتر wait_type یا Return Type داده‌ای ندارد. CLEAR همه شمارنده‌های قابل مشاهده در DMV هدف را با هم بازنشانی می‌کند. نمی‌توان فقط PAGEIOLATCH_SH یا WRITELOG را انتخاب کرد. اگر تحلیل انتخابی لازم است، Snapshot را نگه دارید و در Query گزارش WHERE اعمال کنید.

پس از موفقیت، پیام اطلاعاتی DBCC ممکن است نمایش داده شود؛ NO_INFOMSGS آن را حذف می‌کند. نتیجه تحلیلی را باید با SELECT از sys.dm_os_wait_stats بسازید. به دلیل فعالیت مداوم موتور، نتیجه بعدی می‌تواند ردیف‌های غیرصفر تازه داشته باشد و این رفتار طبیعی است.

شمارنده‌ها از آخرین Start موتور یا آخرین Reset تجمع می‌یابند و پس از Restart پایدار نیستند. زمان sqlserver_start_time را کنار هر Snapshot نگه دارید. اگر شمارنده جدید از قبلی کوچک‌تر شد، Collector باید آن را مرز Reset یا Restart تشخیص دهد و Delta منفی را به عنوان بهبود واقعی محاسبه نکند.

مجوز موردنیاز

برای Reset کردن Wait یا Latch Statistics در SQL Server مجوز ALTER SERVER STATE لازم است. این سطح دسترسی از مشاهده ساده داده گسترده‌تر است و باید بر اساس اصل حداقل دسترسی واگذار شود. در Production بهتر است حساب Job یا Runbook مشخص، فرمان را اجرا کند و کاربران عادی فقط گزارش‌های Snapshot را بخوانند.

SELECT
    ORIGINAL_LOGIN() AS original_login,
    SUSER_SNAME() AS execution_login,
    HAS_PERMS_BY_NAME(NULL, NULL, 'ALTER SERVER STATE') AS can_alter_server_state;

مقدار ۱ در ستون can_alter_server_state نشان می‌دهد نشست مجوز را دارد، صفر یعنی ندارد و NULL می‌تواند ناشی از ورودی یا Context نامعتبر باشد. این بررسی جای طراحی امنیت و آزمون محیط هدف را نمی‌گیرد.

آمادگی پیش از اجرا

1. بررسی کنید مشکل جاری هنوز شواهد جمع‌نشده ندارد.
2. Snapshot کامل Waitها و زمان sqlserver_start_time را ذخیره کنید.
3. هدف، مالک، Change ID و طول پنجره اندازه‌گیری را ثبت کنید.
4. Collector و Dashboard را از مرز Reset آگاه کنید.
5. مجوز حساب اجراکننده و محیط Server یا Azure را کنترل کنید.
6. معیارهای Query و زیرساخت را نیز برای مقایسه قبل و بعد آماده سازید.

اگر نمی‌توانید توضیح دهید داده قبل کجا ذخیره شده و نتیجه بعد چگونه سنجیده می‌شود، هنوز زمان اجرای CLEAR نرسیده است.

ده مثال عملی و قابل اجرا

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

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) WITH NO_INFOMSGS;
SELECT N'OK' AS reset_status, SYSDATETIME() AS reset_time;

DECLARE @TasksBefore bigint;

SELECT @TasksBefore = SUM(waiting_tasks_count)
FROM sys.dm_os_wait_stats;

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

SELECT
    @TasksBefore AS tasks_before,
    SUM(waiting_tasks_count) AS tasks_after
FROM sys.dm_os_wait_stats;

SELECT TOP (10)
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    signal_wait_time_ms,
    SYSDATETIME() AS captured_at
INTO #TopWaitsBeforeReset
FROM sys.dm_os_wait_stats
WHERE waiting_tasks_count > 0
ORDER BY wait_time_ms DESC;

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

SELECT wait_type, wait_time_ms, captured_at
FROM #TopWaitsBeforeReset
ORDER BY wait_time_ms DESC;

CREATE TABLE #WaitResetAudit
(
    server_name sysname,
    login_name sysname,
    reset_started_at datetime2(3),
    reset_completed_at datetime2(3) NULL
);

INSERT INTO #WaitResetAudit
    (server_name, login_name, reset_started_at)
VALUES
    (CAST(SERVERPROPERTY('ServerName') AS sysname), ORIGINAL_LOGIN(), SYSDATETIME());

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

UPDATE #WaitResetAudit
SET reset_completed_at = SYSDATETIME();

SELECT * FROM #WaitResetAudit;

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

DECLARE @WindowStart datetime2(3) = SYSDATETIME();
WAITFOR DELAY '00:00:05';

SELECT TOP (5)
    @WindowStart AS window_start,
    SYSDATETIME() AS window_end,
    wait_type,
    waiting_tasks_count,
    wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0
ORDER BY wait_time_ms DESC;

-- Wrong and intentionally not executed:
-- DBCC SQLPERF ('sys.dm_os_wait_stat', CLEAR);

-- Correct:
DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) WITH NO_INFOMSGS;
SELECT N'Correct DMV name was used' AS validation_result;

DECLARE @ConfirmReset bit = NULL;

IF @ConfirmReset = 1
BEGIN
    DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) WITH NO_INFOMSGS;
    SELECT N'Executed' AS operation_status;
END
ELSE
BEGIN
    SELECT N'Not executed; explicit confirmation is required' AS operation_status;
END;

BEGIN TRY
    DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) WITH NO_INFOMSGS;
    SELECT N'Succeeded' AS operation_status,
           SYSDATETIME() AS event_time;
END TRY
BEGIN CATCH
    SELECT N'Failed' AS operation_status,
           ERROR_NUMBER() AS error_number,
           ERROR_MESSAGE() AS error_message,
           SYSDATETIME() AS event_time;
    THROW;
END CATCH;

CREATE TABLE #Orders
(
    OrderID int NOT NULL,
    CustomerID int NOT NULL,
    OrderDate date NOT NULL,
    Amount decimal(12,2) NOT NULL
);

INSERT INTO #Orders (OrderID, CustomerID, OrderDate, Amount)
SELECT TOP (10000)
    ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
    1 + ABS(CHECKSUM(NEWID())) % 500,
    DATEADD(DAY, -ABS(CHECKSUM(NEWID())) % 365, CAST(GETDATE() AS date)),
    CAST(10 + ABS(CHECKSUM(NEWID())) % 5000 AS decimal(12,2))
FROM sys.all_objects AS a
CROSS JOIN sys.all_objects AS b;

CREATE INDEX IX_Orders_Customer_OrderDate
ON #Orders (CustomerID, OrderDate)
INCLUDE (Amount);

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

SELECT CustomerID, SUM(Amount) AS total_amount
FROM #Orders
WHERE CustomerID BETWEEN 100 AND 120
  AND OrderDate >= DATEADD(DAY, -90, CAST(GETDATE() AS date))
GROUP BY CustomerID;

SELECT TOP (5) wait_type, waiting_tasks_count, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0
ORDER BY wait_time_ms DESC;

خطاهای رایج

خطای مجوز

اگر Login مجوز ALTER SERVER STATE نداشته باشد، فرمان شکست می‌خورد. ابتدا ORIGINAL_LOGIN، عضویت Roleها و مسیر اجرای Job را بررسی کنید. افزودن کاربر به sysadmin برای حل سریع، اصل حداقل دسترسی را نقض می‌کند و سطح خطر را بی‌دلیل بالا می‌برد.

نام نادرست DMV

اشتباه تایپی در sys.dm_os_wait_stats یا استفاده از متغیر به جای Literal مجاز، Syntax مورد انتظار DBCC را نمی‌سازد. فرمان را به شکل ثابت، Version Controlled و Reviewشده نگه دارید و ورودی کاربر را مستقیماً به DBCC متصل نکنید.

برداشت اشتباه از خروجی

غیرصفر بودن چند ردیف بلافاصله پس از Reset معمولاً نتیجه فعالیت تازه است. برعکس، صفر شدن شمارنده‌ها نیز ثابت نمی‌کند Performance بهتر شده است. معیار موفقیت باید نرخ انتظار و شاخص‌های Workload طی بازه مشخص باشد.

از دست دادن Baseline

شایع‌ترین خطای فرایندی اجرای فرمان پیش از Snapshot است. دیتای تجمعی قبلی از DMV بازیابی نمی‌شود، مگر آنکه ابزار مانیتورینگ قبلاً آن را نگه داشته باشد. پیش‌شرط Script را ذخیره موفق Snapshot قرار دهید.

ملاحظات Performance

خود Reset معمولاً سبک است و برای آزادسازی منابع طراحی نشده است. اثر مهم آن بر روش اندازه‌گیری است: همه فعالیت‌های هم‌زمان Instance در شمارنده جدید مشارکت می‌کنند. اگر Benchmark یک Query خاص است، محیط ایزوله یا کنترل بار و تکرار چندباره لازم است؛ در غیر این صورت Waitهای دیگر کاربران نتیجه را آلوده می‌کنند.

برای سنجش بهبود ایندکس، فقط Wait Type کافی نیست. Duration، CPU، Logical Reads، Physical Reads، Compile، Memory Grant و Plan را ثبت کنید. ممکن است یک تغییر زمان Query را کم کند ولی به دلیل افزایش هم‌زمان بار، شمارنده Instance بیشتر شود. معیارهای Query-level و Server-level باید کنار هم تفسیر شوند.

CLEAR پرتکرار در Job روزانه ارزش Performance ندارد و Trend را خرد می‌کند. Snapshot و Delta اجازه می‌دهد هر پنجره بدون حذف گذشته جدا شود. Reset را به رخدادهای محدود و مستند اختصاص دهید؛ Collector نیز باید Restart، Failover و Reset را به عنوان Counter Boundary تشخیص دهد.

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

• فرمان را در Script مستقل با Header شامل هدف، مالک و شماره Change نگه دارید.
• پیش از اجرا ذخیره Snapshot را بررسی و تعداد ردیف‌های آن را ثبت کنید.
• از WITH NO_INFOMSGS در Automation و از خروجی وضعیت ساخت‌یافته استفاده کنید.
• Error Handling را طوری بنویسید که شکست مجوز به Pipeline بازگردد.
• زمان را با datetime2 و ترجیحاً UTC ذخیره کنید.
• اجرا را در جدول Audit یا سامانه مرکزی رخدادها ثبت نمایید.
• Reset را جایگزین تحلیل Delta، Query Store یا Extended Events نکنید.
• مجوز ALTER SERVER STATE را محدود و دوره‌ای بازبینی کنید.

کاربردهای واقعی

در پروژه ارتقای Storage، تیم می‌تواند Snapshot قبلی را حفظ کند، درست پیش از بار آزمایشی Reset انجام دهد و نرخ PAGEIOLATCH و WRITELOG را همراه Latency فایل مقایسه کند. در پروژه بهینه‌سازی Index نیز پنجره کنترل‌شده می‌تواند اثر تغییر روی Logical Reads، Duration و Waitها را روشن سازد.

در Release بزرگ، ایجاد مرز زمانی جدید فقط وقتی مفید است که Baseline نسخه قبلی موجود باشد و Collector زمان Deployment را بداند. اگر پس از Release Wait خاصی رشد کند، تیم می‌تواند آن را با Queryهای تغییرکرده و Planها هم‌بسته کند. بدون داده قبل، عبارت بهتر یا بدتر پشتوانه عددی ندارد.

در خدمات مشاوره و عیب‌یابی SQL Server، Reset نباید نخستین حرکت باشد. مشاور ابتدا معماری جمع‌آوری، Uptime، روند Wait، Queryهای سنگین و شاخص‌های زیرساخت را بررسی می‌کند. سپس اگر سؤال آزمایشی مشخصی وجود داشت، یک پنجره Reset کنترل‌شده طراحی می‌شود و نتیجه با معیار از پیش تعیین‌شده گزارش می‌گردد.

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

نحو صحیح DBCC SQLPERF برای پاک‌سازی Wait چیست؟

شکل استاندارد DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) است و می‌توان WITH NO_INFOMSGS را برای سرکوب پیام‌های اطلاعاتی افزود. نام DMV و کلمه CLEAR باید دقیق نوشته شوند.

آیا این فرمان خروجی جدولی برمی‌گرداند؟

عملیات CLEAR برای ارائه گزارش Wait طراحی نشده و معمولاً فقط پیام تکمیل DBCC می‌دهد. برای مشاهده وضعیت قبل یا بعد، SELECT جداگانه روی sys.dm_os_wait_stats اجرا کنید.

آیا اجرای DBCC SQLPERF هزینه تجاری یا Downtime دارد؟

Downtime ایجاد نمی‌کند و معمولاً عملیات سبکی است، اما تاریخچه تشخیصی مشترک را تغییر می‌دهد. هزینه اصلی فرایندی، از دست رفتن Baseline و احتمال تحلیل غلط است؛ بنابراین اجرای Production باید کنترل شود.

چه کسی باید این فرمان را در سازمان اجرا کند؟

حساب DBA یا Automation کنترل‌شده با ALTER SERVER STATE و Audit مناسب. بهتر است کاربران گزارش‌خوان مجوز Reset نداشته باشند و درخواست از مسیر Change یا Incident تأییدشده عبور کند.

تفاوت CLEAR برای wait_stats و latch_stats چیست؟

هر هدف مجموعه شمارنده متفاوتی را بازنشانی می‌کند. sys.dm_os_wait_stats انتظار Workerها را نگه می‌دارد و sys.dm_os_latch_stats آمار کلاس‌های Latch را؛ انتخاب یکی، جای تحلیل دیگری را نمی‌گیرد.

آیا می‌توان فرمان را داخل Stored Procedure قرار داد؟

بله، ولی Permission سطح Server باید با طراحی امن مدیریت شود. اعطای مجوز گسترده به همه اجراکنندگان مناسب نیست؛ امضای Module و محدودکردن مسیر اجرا گزینه‌ای قابل بررسی است.

خطای Permission هنگام CLEAR چگونه رفع می‌شود؟

ابتدا هویت واقعی اتصال و محیط را بررسی کنید. راه درست واگذاری کنترل‌شده ALTER SERVER STATE یا اجرای Runbook توسط حساب مجاز است، نه استفاده دائمی از sysadmin برای دور زدن طراحی دسترسی.

آیا Reset کردن مکرر Performance را بهتر اندازه می‌گیرد؟

معمولاً خیر. Snapshot و Delta تاریخچه را حفظ می‌کنند و برای بازه‌های متعدد مقیاس‌پذیرترند. Reset مکرر مرزهای زیاد و خطر تداخل با Collectorها ایجاد می‌کند.

Best Practice پیش از فرمان چیست؟

زمان شروع موتور و Snapshot کامل را ذخیره کنید، هدف و طول پنجره را بنویسید، تیم مانیتورینگ را آگاه سازید و زمان و هویت اجراکننده را Audit کنید.

سازگاری DBCC SQLPERF در نسخه‌های جدید چگونه است؟

این فرمان در نسخه‌های پشتیبانی‌شده SQL Server وجود دارد و مستندات Microsoft کاربرد آن را برای SQL Server و سرویس‌های Azure مرتبط بیان می‌کند. جزئیات Permission و دامنه DMV را برای محصول و Tier خود جداگانه کنترل کنید.

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

DBCC SQLPERF CLEAR چه چیزی را پاک نمی‌کند؟

Plan Cache، Buffer Pool، Lockهای فعال، Sessionها، Query Store و داده‌های کاربری را پاک نمی‌کند؛ تنها شمارنده هدف را بازنشانی می‌کند.

چرا WITH NO_INFOMSGS را استفاده می‌کنیم؟

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

چرا پس از فرمان ممکن است waiting_tasks_count صفر نباشد؟

زیرا فعالیت Instance بلافاصله Waitهای تازه ثبت می‌کند. فاصله بسیار کوتاه میان DBCC و SELECT نیز برای ایجاد مقدار جدید کافی است.

چگونه Reset ناخواسته را در Pipeline مهار می‌کنید؟

تأیید صریح، جداسازی حساب، کنترل محیط، ثبت Change ID، Dry Run، Audit و محدودکردن فرمان به Runbook Reviewشده را ترکیب می‌کنم.

برای مقایسه قبل و بعد چه معیارهایی کنار Wait لازم است؟

Duration، CPU time، Logical Reads، Throughput، Blocking، Latency فایل، Plan اجرا و حجم Workload باید ثبت شوند تا تغییر Wait در Context درست معنا شود.

چک‌لیست نهایی فرمان

1. Snapshot قبل از فرمان ذخیره و قابل بازیابی است.
2. زمان شروع موتور و زمان Reset ثبت می‌شود.
3. حساب اجراکننده ALTER SERVER STATE کنترل‌شده دارد.
4. نام sys.dm_os_wait_stats دقیق نوشته شده است.
5. NO_INFOMSGS در Automation بر اساس نیاز افزوده شده است.
6. TRY/CATCH و ثبت خطا فعال است.
7. Dashboard از Reset یا Restart آگاه است.
8. بازه بعدی و معیار موفقیت تعریف شده است.
9. نتیجه با Query، Plan و زیرساخت هم‌بسته می‌شود.
10. مجوز و رخداد پس از پایان کار بازبینی می‌شوند.

جمع‌بندی

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) فرمان کوتاهی است، اما استفاده درست از آن به انضباط عملیاتی نیاز دارد. فرمان شمارنده‌ها را بازنشانی می‌کند و مشکل کارایی را درمان نمی‌کند. Snapshot، Audit، Permission محدود، پنجره مشخص و تحلیل چندمنبعی پنج جزء اجرای قابل دفاع هستند.

برای مرور راهبرد کامل تحلیل، زمان‌های مناسب و نامناسب Reset و طراحی Snapshot، به مقاله مادر پاک‌سازی آمار انتظار در SQL Server بازگردید.