مقدمه و هدف مقاله

شمارنده Deadlocks/sec یکی از موضوع‌های مهم پایش Microsoft SQL Server است. هدف آن محاسبه نرخ Deadlockهای شناسایی‌شده توسط موتور قفل است. در یک سامانه عملیاتی، عدد این شاخص زمانی ارزش دارد که همراه زمان نمونه‌برداری، بار کاری، رخدادهای استقرار و وضعیت منابع تحلیل شود؛ در غیر این صورت یک مقدار جدا می‌تواند هم هشدار کاذب بسازد و هم یک مشکل واقعی را پنهان کند.

در این راهنما از سطح پایه تا اجرای Query، تفسیر واحد «بن‌بست در ثانیه»، نمونه‌برداری، نگهداری تاریخچه، طراحی هشدار و ارتباط با Lock Waits/sec پیش می‌رویم. مثال‌ها برای SQL Server نوشته شده‌اند و خروجی نمونه دارند تا ساختار نتیجه پیش از اجرا روشن باشد. با این حال اعداد خروجی نمایشی‌اند و مقدار واقعی به نسخه، Uptime، سخت‌افزار و الگوی مصرف شما وابسته است.

اصل کلیدی در تحلیل Deadlocks/sec این است که ابتدا نوع Counter مشخص شود. حتی مقدار کم تکرارشونده مهم است و باید نمودار Deadlock برای یافتن ترتیب قفل‌ها استخراج شود. همچنین باید دانست که نام واقعی شمارنده در DMV معمولاً Number of Deadlocks/sec است و عدد به‌تنهایی Queryهای درگیر را مشخص نمی‌کند. این دو نکته جلوی رایج‌ترین برداشت‌های اشتباه در داشبوردهای دست‌ساز را می‌گیرند.

برای دیدن نقشه کامل شاخص‌ها و ارتباط این موضوع با سایر حوزه‌های حافظه، I/O، Query Processing، Lock و Transaction به راهنمای جامع شمارنده‌های کارایی SQL Server بازگردید.

تعریف، منبع داده و کاربرد

Deadlocks/sec در دسته «Locks» قرار می‌گیرد. منبع اصلی این مقاله نمای مدیریتی sys.dm_os_performance_counters است؛ نمایی که بسیاری از Counterهای موتور را از داخل T-SQL قابل‌خواندن می‌کند. مزیت این روش، امکان ساخت Collector، گزارش و Health Check بدون وابستگی به رابط گرافیکی Performance Monitor است.

کاربرد واقعی این شاخص فقط نمایش یک کارت سبز یا قرمز نیست. روند شمارنده Deadlocks/sec می‌تواند برای مقایسه قبل و بعد از Deploy، تحلیل ساعات اوج، ظرفیت‌سنجی، ارزیابی اثر Query جدید، تشخیص Regression و ساخت گزارش SLA به کار رود. برای نتیجه معتبر باید Counter را در بازه کافی و با فاصله نمونه‌برداری ثابت یا ثبت‌شده جمع‌آوری کرد.

دسترسی به DMVهای سیستمی ممکن است به مجوزهای مشاهده وضعیت سرور یا مجوز متناظر نسخه جدید نیاز داشته باشد. حساب Collector را با اصل حداقل دسترسی بسازید، خطای دسترسی را ثبت کنید و از اجرای Collector با حساب مدیریتی روزمره خودداری نمایید. در محیط Always On نیز نام Replica و Instance را همراه Snapshot نگه دارید.

نحو پایه

SELECT object_name, counter_name, instance_name, cntr_value, cntr_type
FROM sys.dm_os_performance_counters
WHERE object_name LIKE N'%:Locks'
  AND counter_name = N'Number of Deadlocks/sec'
  AND instance_name = N'_Total';

ستون‌ها و پارامترهای مهم

• object_name: نام شیء Performance Counter همراه پیشوند Instance؛ برای قابل‌حمل‌بودن می‌توان suffix گروه را با دقت فیلتر کرد.
• counter_name: نام دقیق شاخص؛ در این مقاله نام موردنظر یا نگاشت واقعی آن به‌صورت Unicode استفاده می‌شود.
• instance_name: زیرنمونه‌ای مانند نام پایگاه داده، نوع Lock یا _Total؛ انتخاب اشتباه آن موجب دوباره‌شماری یا تحلیل دامنه نادرست می‌شود.
• cntr_value: مقدار خام bigint؛ معنی آن بدون cntr_type و فرمول Counter کامل نیست.
• cntr_type: نوع Windows Performance Counter که مشخص می‌کند مقدار مستقیم، تجمعی یا Fraction چگونه تبدیل شود.
• واحد تحلیلی: بن‌بست در ثانیه. واحد را در نام ستون تاریخچه، Tooltip داشبورد و متن هشدار صریح نگه دارید.

نوع خروجی و تفسیر

خروجی خام cntr_value از نوع bigint است، اما خروجی تحلیلی می‌تواند تعداد، نرخ decimal یا درصد باشد. درباره Deadlocks/sec، حتی مقدار کم تکرارشونده مهم است و باید نمودار Deadlock برای یافتن ترتیب قفل‌ها استخراج شود. اگر تبدیل انجام می‌شود، مقدار خام را نیز نگه دارید تا امکان بازحساب، بررسی Formula و مهاجرت ابزار مانیتورینگ وجود داشته باشد.

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

مثال 1: خواندن ردیف خام شمارنده

در نخستین گام ردیف دقیق Deadlocks/sec، نوع شمارنده و مقدار تجمعی آن خوانده می‌شود تا مطمئن شویم نام شیء و Counter در این Instance موجود است.

SELECT object_name, counter_name, instance_name, cntr_value, cntr_type
FROM sys.dm_os_performance_counters
WHERE object_name LIKE N'%:Locks'
  AND counter_name = N'Number of Deadlocks/sec'
  AND instance_name = N'_Total';

نکته کاربردی: این مقدار خام نرخ یک‌ثانیه‌ای نیست. cntr_type برابر 272696576 معمولاً یعنی نرخ باید از اختلاف دو نمونه محاسبه شود.

مثال 2: محاسبه نرخ با دو نمونه پنج‌ثانیه‌ای

دو Snapshot با فاصله پنج ثانیه گرفته می‌شود. تقسیم اختلاف مقدار تجمعی بر مدت نمونه‌برداری، نرخ قابل‌مقایسه‌ای برای داشبورد می‌سازد.

DECLARE @v1 bigint, @v2 bigint;

SELECT @v1 = cntr_value
FROM sys.dm_os_performance_counters
WHERE object_name LIKE N'%:Locks'
  AND counter_name = N'Number of Deadlocks/sec'
  AND instance_name = N'_Total';

WAITFOR DELAY '00:00:05';

SELECT @v2 = cntr_value
FROM sys.dm_os_performance_counters
WHERE object_name LIKE N'%:Locks'
  AND counter_name = N'Number of Deadlocks/sec'
  AND instance_name = N'_Total';

SELECT CAST((@v2 - @v1) / 5.0 AS decimal(18,2)) AS RatePerSecond;

نکته کاربردی: در سامانه پایش، زمان واقعی بین دو نمونه را ثبت کنید؛ فرض ثابت پنج ثانیه در صورت تأخیر Job می‌تواند نرخ را منحرف کند.

مثال 3: محاسبه نرخ از جدول تاریخچه با LAG

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

DECLARE @History table
(
    SampleTime datetime2(0),
    CounterValue bigint
);

INSERT @History VALUES
('2026-07-22T10:00:00', 100000),
('2026-07-22T10:00:10', 100010),
('2026-07-22T10:00:20', 100050);

WITH S AS
(
    SELECT SampleTime, CounterValue,
           LAG(SampleTime) OVER (ORDER BY SampleTime) AS PrevTime,
           LAG(CounterValue) OVER (ORDER BY SampleTime) AS PrevValue
    FROM @History
)
SELECT SampleTime,
       CAST((CounterValue - PrevValue) /
            NULLIF(DATEDIFF_BIG(millisecond, PrevTime, SampleTime) / 1000.0, 0)
            AS decimal(18,2)) AS RatePerSecond
FROM S
WHERE PrevValue IS NOT NULL;

نکته کاربردی: استفاده از DATEDIFF_BIG برای بازه‌های طولانی و ثبت datetime2 از سرریز و خطای گردکردن جلوگیری می‌کند.

مثال 4: نمایش مقدار همراه زمان شروع سرویس

چون شمارنده تجمعی بعد از Restart صفر می‌شود، زمان شروع SQL Server کنار Snapshot قرار می‌گیرد تا Reset شدن سری زمانی با افت واقعی اشتباه نشود.

SELECT osi.sqlserver_start_time, pc.cntr_value
FROM sys.dm_os_sys_info AS osi
CROSS JOIN
(
    SELECT cntr_value
    FROM sys.dm_os_performance_counters
    WHERE object_name LIKE N'%:Locks'
  AND counter_name = N'Number of Deadlocks/sec'
  AND instance_name = N'_Total'
) AS pc;

نکته کاربردی: جمع‌آورنده باید با تغییر sqlserver_start_time خط پایه جدید بسازد و اختلاف منفی را نرخ منفی تلقی نکند.

مثال 5: مقایسه با شمارنده مرتبط

تفکیک مقدار تجمعی به ازای Instanceها کمک می‌کند پایگاه داده یا نوع قفل پرترافیک بدون دوباره‌شماری _Total مشخص شود.

SELECT instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE object_name LIKE N'%:Locks'
  AND counter_name = N'Number of Deadlocks/sec'
ORDER BY cntr_value DESC;

نکته کاربردی: هم‌بستگی زمانی از مقایسه دو مقدار منفرد معتبرتر است؛ هر دو سری را با فاصله نمونه‌برداری یکسان جمع‌آوری کنید.

مثال 6: مدیریت مقدار NULL یا Counter غایب

در بعضی نسخه‌ها، Editionها یا هنگام اشتباه تایپی ممکن است ردیف شمارنده پیدا نشود. OUTER APPLY و COALESCE خروجی قابل‌کنترل برای Collector ایجاد می‌کنند.

SELECT COALESCE(pc.cntr_value, 0) AS SafeCounterValue,
       CASE WHEN pc.cntr_value IS NULL THEN N'شمارنده یافت نشد' ELSE N'موجود' END AS CounterState
FROM (VALUES (1)) AS seed(n)
OUTER APPLY
(
    SELECT TOP (1) cntr_value
    FROM sys.dm_os_performance_counters
    WHERE object_name LIKE N'%:Locks'
  AND counter_name = N'Number of Deadlocks/sec'
  AND instance_name = N'_Total'
) AS pc;

نکته کاربردی: صفر جایگزین‌شده را در لایه پایش با برچسب Missing نگه دارید؛ صفر واقعی و نبود داده دو وضعیت متفاوت هستند.

مثال 7: تشخیص Reset یا سرریز در سری زمانی

اگر مقدار جدید از مقدار قبلی کوچک‌تر باشد، احتمال Restart سرویس یا Reset وجود دارد. این Query به‌جای تولید نرخ منفی، وضعیت نمونه را مشخص می‌کند.

DECLARE @Previous bigint = 985000,
        @Current  bigint = 420;

SELECT CASE
           WHEN @Current < @Previous THEN N'ResetDetected'
           ELSE N'ValidDelta'
       END AS SampleStatus,
       CASE WHEN @Current >= @Previous THEN @Current - @Previous END AS SafeDelta;

نکته کاربردی: در صورت Reset، نخستین نمونه فقط خط پایه است و تا رسیدن نمونه بعدی نباید برای آن نرخ منتشر شود.

مثال 8: ساخت وضعیت هشدار بر پایه نرخ

در این مثال یک نرخ محاسبه‌شده با آستانه نمونه مقایسه می‌شود. آستانه واقعی Deadlocks/sec باید از Baseline همان سامانه و ظرفیت سخت‌افزار استخراج شود.

DECLARE @Rate decimal(18,2) = 2;

SELECT @Rate AS ObservedRate,
       CASE
           WHEN @Rate >= 5 THEN N'بحرانی'
           WHEN @Rate >= 1 THEN N'نیازمند بررسی'
           ELSE N'عادی'
       END AS HealthState;

نکته کاربردی: هشدار باید حداقل چند نمونه پیوسته، زمان پاسخ و شمارنده‌های مرتبط را در نظر بگیرد تا از Alert Storm جلوگیری شود.

مثال 9: نمایش روش اشتباه و نسخه اصلاح‌شده

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

DECLARE @OldValue bigint = 120000,
        @NewValue bigint = 126400,
        @ElapsedSeconds decimal(10,2) = 8.0;

SELECT @NewValue AS WrongRate,
       CAST((@NewValue - @OldValue) / NULLIF(@ElapsedSeconds, 0)
            AS decimal(18,2)) AS CorrectRate;

نکته کاربردی: نام Counter با پسوند /sec به این معنا نیست که DMV همیشه نرخ آماده تحویل می‌دهد؛ cntr_type مرجع تصمیم است.

مثال 10: Collector کم‌هزینه با فیلتر دقیق

در محیط پرترافیک بهتر است همه Counterها یک بار در Snapshot خوانده شوند و انتخاب نام‌های لازم در همان Query انجام شود. فیلتر صریح حجم انتقال و پردازش را کاهش می‌دهد.

SELECT SYSDATETIME() AS SampleTime,
       counter_name, instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE object_name LIKE N'%:Locks'
  AND counter_name = N'Number of Deadlocks/sec'
  AND instance_name = N'_Total'
OPTION (RECOMPILE);

نکته کاربردی: نمونه‌برداری هر یک تا پانزده ثانیه برای عیب‌یابی کوتاه و هر سی تا شصت ثانیه برای روند بلندمدت معمول است؛ هزینه نگهداری تاریخچه را نیز بسنجید.

خطاهای رایج و روش اصلاح

نخستین خطا در Deadlocks/sec اعتماد مستقیم به نام Counter و نمایش cntr_value بدون بررسی cntr_type است. پسوند /sec همیشه تضمین نمی‌کند مقدار آماده نرخ باشد و Counterهای Fraction نیز Base لازم دارند. Formula را در Metadata تعریف کنید و برای هر نوع، آزمون واحد با داده ثابت بنویسید.

خطای دوم، نادیده‌گرفتن دامنه Instance است. در گروه‌های Locks و Databases، _Total و ردیف‌های جزئی هم‌زمان وجود دارند. جمع‌کردن همه ردیف‌ها معمولاً دوباره‌شماری می‌سازد. برای شمارنده Deadlocks/sec نام Instance انتخاب‌شده را همراه داده ذخیره و در عنوان نمودار نمایش دهید.

خطای سوم، تفسیر یک نقطه بدون Baseline است. وضعیت Deadlocks/sec بین سامانه OLTP، انبار داده، گزارش شبانه و دوره نگهداری متفاوت است. حد هشدار را از صدک‌های تاریخچه سالم استخراج کنید و رخداد را تنها زمانی بحرانی بدانید که چند نمونه ادامه یافته و یک سیگنال مکمل مانند Lock Waits/sec نیز آن را تأیید کند.

خطای چهارم، نادیده‌گرفتن Restart، Failover و شکاف داده است. Startup Time، نام Replica و Availability هر Snapshot را ثبت کنید. اختلاف منفی را نرخ منفی گزارش نکنید و داده Missing را با صفر واقعی یکی ندانید. این تفکیک برای نمودار، SLA و الگوریتم تشخیص ناهنجاری ضروری است.

نکات کارایی و طراحی Collector

خواندن هدفمند sys.dm_os_performance_counters معمولاً عملیات سبکی است، اما طراحی نامناسب Collector می‌تواند صدها Query تکراری، اتصال کوتاه‌عمر و حجم زیاد تاریخچه تولید کند. Counterهای لازم را در یک Statement بگیرید، زمان مشترک ثبت کنید و محاسبات Rate یا Ratio را در لایه‌ای قابل‌آزمون انجام دهید.

برای عیب‌یابی زنده می‌توان فاصله یک تا پنج ثانیه داشت، ولی نگهداری بلندمدت اغلب با سی تا شصت ثانیه آغاز می‌شود. داده خام قدیمی را به بازه‌های پنج‌دقیقه‌ای و ساعتی Rollup کنید و Min، Max، Avg، Count و در صورت امکان صدک را نگه دارید. Retention باید با نیاز قانونی و هزینه ذخیره‌سازی سازگار باشد.

در تحلیل Deadlocks/sec هرگز Counter را جایگزین Query Profiling نکنید. شمارنده ناحیه مشکل را مشخص می‌کند؛ برای علت ریشه‌ای باید Query Store، Actual Plan، Wait Stats، Extended Events و آمار فایل یا سیستم‌عامل به کار روند. این زنجیره از Metric به Evidence و سپس Action، Runbook حرفه‌ای را می‌سازد.

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

• نام SQL Server، Instance، Replica، نسخه و زمان شروع سرویس را همراه هر Snapshot نگه دارید.
• مقدار خام، cntr_type، واحد، Formula و مقدار تبدیل‌شده را از هم تفکیک کنید.
• Deadlocks/sec را حداقل با Lock Waits/sec و یک شاخص Latency یا Wait مرتبط مقایسه نمایید.
• Baseline ساعات عادی، اوج، Batch شبانه و پایان ماه را جدا بسازید؛ میانگین کلی به‌تنهایی کافی نیست.
• هشدار را بر اساس تداوم و دامنه اثر ایجاد کنید و برای آن مالک، شدت و Runbook تعیین نمایید.
• Collector را پس از ارتقای SQL Server، تغییر Edition، Failover یا تغییر Collation دوباره اعتبارسنجی کنید.
• Queryهای نمونه را ابتدا در محیط آزمایش اجرا کنید و از WAITFOR در Jobهای پرتعداد استفاده نکنید.
• به‌جای حذف تاریخچه، Rollup و فشرده‌سازی انجام دهید تا مقایسه فصلی و ظرفیت‌سنجی باقی بماند.

کاربردهای واقعی در سازمان

در یک سامانه فروش آنلاین، روند شمارنده Deadlocks/sec می‌تواند روی Timeline سفارش، Deploy و کمپین بازاریابی قرار گیرد. اگر تغییر شاخص فقط با افزایش سفارش رخ دهد، موضوع ظرفیت است؛ اگر بدون رشد کسب‌وکار و بعد از انتشار نسخه جدید ایجاد شود، Regression محتمل‌تر خواهد بود.

در گزارش ظرفیت ماهانه، به‌جای ارائه انبوه عدد خام، روند، صدک اوج، مدت وضعیت غیرعادی، اثر روی زمان پاسخ و اقدام اصلاحی را خلاصه کنید. این قالب میان تیم پایگاه داده، زیرساخت، توسعه و مدیریت زبان مشترک می‌سازد و تصمیم ارتقا یا اصلاح کد را مستند می‌کند.

برای عملیات روزانه، هشدار Deadlocks/sec باید لینک Query تشخیصی، Snapshot سیگنال‌های مکمل و راه بازگشت داشته باشد. تماس صرف با DBA بدون Evidence زمان بازیابی را افزایش می‌دهد؛ یک Runbook کوتاه با مرحله تأیید، تعیین دامنه، یافتن Query و اقدام کم‌خطر نتیجه بهتری دارد.

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

Deadlocks/sec چیست و چه چیزی را اندازه می‌گیرد؟

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

چگونه مقدار Deadlocks/sec را از SQL Server بخوانیم؟

نمای sys.dm_os_performance_counters منبع داخلی مناسب است. Object و counter_name را دقیق فیلتر کنید، Instance را در شمارنده‌های چندنمونه‌ای مشخص سازید و cntr_type را نیز ذخیره کنید. برای Counter تجمعی، اختلاف دو cntr_value را بر ثانیه واقعی تقسیم کنید.

آیا استفاده تجاری از داشبورد Deadlocks/sec ارزش دارد؟

بله؛ روند درست می‌تواند افت ظرفیت را پیش از تبدیل‌شدن به قطعی آشکار کند، زمان عیب‌یابی را کاهش دهد و برای تصمیم خرید سخت‌افزار شواهد بسازد. ارزش اقتصادی زمانی ایجاد می‌شود که هشدار به Runbook، مسئول و اقدام روشن متصل باشد.

برای گزارش مدیریتی Deadlocks/sec چه اطلاعاتی لازم است؟

حداقل مقدار جاری یا نرخ، Baseline، انحراف، بازه مشاهده و اثر روی سرویس گزارش شود. واحد بن‌بست در ثانیه باید صریح باشد و نمودار با Deploy، Backup و رخدادهای کسب‌وکار هم‌تراز گردد تا مدیر علت جهش را بهتر درک کند.

تفاوت Deadlocks/sec با Lock Waits/sec چیست؟

Deadlocks/sec بر «محاسبه نرخ Deadlockهای شناسایی‌شده توسط موتور قفل» تمرکز دارد، در حالی که Lock Waits/sec زاویه مکمل دیگری از همان سامانه ارائه می‌کند. هیچ‌یک جای دیگری را نمی‌گیرد و هم‌بستگی روند آن‌ها برای تشخیص فشار، ظرفیت یا رقابت قابل‌اعتمادتر است.

برای پیاده‌سازی حرفه‌ای پایش Deadlocks/sec از کجا شروع کنیم؟

ابتدا Counter را در محیط آزمایش کشف کنید، فرمول تبدیل و واحد را مستند سازید، سپس Collector زمان‌بندی‌شده و جدول تاریخچه بسازید. در پروژه‌های حساس می‌توان از خدمات مشاوره و اجرای پایش SQL Server برای طراحی Retention، داشبورد و Runbook استفاده کرد.

رایج‌ترین خطا هنگام خواندن Deadlocks/sec چیست؟

رایج‌ترین خطا نادیده‌گرفتن cntr_type، Instance یا Restart سرویس است. نام واقعی شمارنده در DMV معمولاً Number of Deadlocks/sec است و عدد به‌تنهایی Queryهای درگیر را مشخص نمی‌کند. همچنین نبود ردیف نباید به‌طور خام با صفر واقعی جایگزین شود؛ Availability باید جداگانه ذخیره گردد.

پایش Deadlocks/sec چه اثری بر Performance دارد؟

خواندن هدفمند این DMV معمولاً سبک است، ولی Poll بسیار پرتکرار، Queryهای تکراری و تاریخچه بدون Rollup هزینه ذخیره‌سازی و تحلیل می‌سازد. چند Counter را در یک Snapshot بخوانید و فاصله نمونه‌برداری را با سرعت تغییر سیگنال هماهنگ کنید.

بهترین روش هشداردهی برای Deadlocks/sec چیست؟

از Baseline همان سرور، آستانه چندسطحی، شرط تداوم چند نمونه و یک سیگنال مکمل استفاده کنید. هشدار باید مقدار، زمان، دامنه، لینک داشبورد و اقدام اولیه داشته باشد؛ یک حد ثابت اینترنتی برای همه سرورها Best Practice نیست.

Deadlocks/sec در کدام نسخه‌های SQL Server قابل استفاده است؟

نمای sys.dm_os_performance_counters در نسخه‌های پشتیبانی‌شده SQL Server در دسترس است، اما نام یا حضور برخی Counterها می‌تواند با نسخه، Edition، سیستم‌عامل و قابلیت فعال متفاوت باشد. همیشه فهرست همان Instance را کشف و کد Collector را در ارتقا آزمایش کنید.

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

چرا مقدار خام Deadlocks/sec همیشه قابل گزارش نیست؟

زیرا معنا به cntr_type وابسته است. Gauge مستقیم خوانده می‌شود، نرخ تجمعی به دو Snapshot و زمان نیاز دارد و Fraction باید با Base محاسبه شود. پاسخ حرفه‌ای همچنین Reset پس از Restart و Instanceهای چندگانه را ذکر می‌کند.

چگونه هشدار کاذب Deadlocks/sec را کم می‌کنید؟

با Baseline محلی، شرط تداوم، آستانه چندسطحی، حذف بازه نگهداری و تأیید به کمک Lock Waits/sec. سپس Alert با بازخورد رخدادها تنظیم می‌شود تا حساسیت و دقت به تعادل برسند.

چرا باید مقدار خام و تبدیل‌شده هر دو ذخیره شوند؟

مقدار خام امکان بررسی Formula، بازپردازش تاریخچه و مهاجرت ابزار را حفظ می‌کند؛ مقدار تبدیل‌شده نمایش و جست‌وجوی سریع را ساده می‌سازد. نگهداری Metadata نسخه Formula نیز برای Audit مفید است.

با تغییر sqlserver_start_time چه می‌کنید؟

Collector مرز سری زمانی جدید ثبت می‌کند، نخستین Snapshot را فقط Baseline می‌گیرد و Delta آن را با مقدار پیش از Restart حساب نمی‌کند. رخداد Restart یا Failover نیز روی نمودار علامت‌گذاری می‌شود.

برای ریشه‌یابی وضعیت غیرعادی Deadlocks/sec چه ابزارهایی لازم است؟

بسته به حوزه از Query Store، Wait Stats، Extended Events، Actual Execution Plan، DMVهای Session و Request، آمار فایل و Counterهای سیستم‌عامل استفاده می‌شود. Metric محل شروع است، نه علت قطعی.

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

• وجود Counter و نام واقعی آن روی Instance مقصد کنترل شده است.
• نوع Counter، Formula تبدیل و واحد خروجی مستند شده‌اند.
• Instance موردنظر صریح است و _Total دوباره جمع زده نمی‌شود.
• زمان نمونه و Startup Time در تاریخچه ذخیره می‌شوند.
• Baseline سالم و بازه‌های کسب‌وکار جداگانه وجود دارد.
• روند با Lock Waits/sec و حداقل یک نشانه Latency یا Wait مقایسه می‌شود.
• هشدار دارای شرط تداوم، مالک و Runbook عملیاتی است.
• Retention، Rollup، امنیت حساب Collector و تست بعد از Upgrade تعریف شده‌اند.

جمع‌بندی

شمارنده Deadlocks/sec زمانی مفید است که از یک عدد خام به سری زمانی قابل‌اعتماد تبدیل شود. شناسایی cntr_type، انتخاب Instance، ثبت زمان و Restart، ساخت Baseline و مقایسه با Lock Waits/sec پایه‌های این تبدیل هستند. مثال‌های مقاله نشان دادند چگونه Query اکتشافی، Snapshot، محاسبه امن، هشدار و Collector کم‌هزینه ساخته شود.

برای ادامه مسیر، مقاله مادر شمارنده‌های Performance در SQL Server را ببینید و شاخص‌های مکمل را به داشبورد خود اضافه کنید. برای آموزش پایگاه داده SQL Server، مشاوره و قبول سفارش پروژه‌های برنامه‌نویسی و پایگاه داده در اصفهان نیز می‌توانید با شماره 09131253620 تماس بگیرید.