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

شمارنده Buffer Cache Hit Ratio یکی از موضوع‌های مهم پایش Microsoft SQL Server است. هدف آن محاسبه سهم درخواست‌های صفحه که از حافظه پاسخ گرفته‌اند است. در یک سامانه عملیاتی، عدد این شاخص زمانی ارزش دارد که همراه زمان نمونه‌برداری، بار کاری، رخدادهای استقرار و وضعیت منابع تحلیل شود؛ در غیر این صورت یک مقدار جدا می‌تواند هم هشدار کاذب بسازد و هم یک مشکل واقعی را پنهان کند.

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

اصل کلیدی در تحلیل Buffer Cache Hit Ratio این است که ابتدا نوع Counter مشخص شود. نسبت نزدیک به صد معمولاً مطلوب است اما میانگین بلندمدت می‌تواند افت‌های کوتاه و مهم را پنهان کند. همچنین باید دانست که مقدار numerator باید بر Buffer cache hit ratio base تقسیم شود؛ خواندن مستقیم cntr_value درصد واقعی نیست. این دو نکته جلوی رایج‌ترین برداشت‌های اشتباه در داشبوردهای دست‌ساز را می‌گیرند.

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

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

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

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

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

نحو پایه

WITH C AS
(
    SELECT counter_name, cntr_value
    FROM sys.dm_os_performance_counters
    WHERE object_name LIKE N'%:Buffer Manager'
      AND counter_name IN
          (N'Buffer cache hit ratio', N'Buffer cache hit ratio base')
)
SELECT CAST(100.0 *
       MAX(CASE WHEN counter_name = N'Buffer cache hit ratio' THEN cntr_value END) /
       NULLIF(MAX(CASE WHEN counter_name = N'Buffer cache hit ratio base' THEN cntr_value END), 0)
       AS decimal(6,2)) AS CacheHitPercent
FROM C;

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

• 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 یا درصد باشد. درباره Buffer Cache Hit Ratio، نسبت نزدیک به صد معمولاً مطلوب است اما میانگین بلندمدت می‌تواند افت‌های کوتاه و مهم را پنهان کند. اگر تبدیل انجام می‌شود، مقدار خام را نیز نگه دارید تا امکان بازحساب، بررسی Formula و مهاجرت ابزار مانیتورینگ وجود داشته باشد.

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

مثال 1: خواندن Numerator و Base

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

SELECT counter_name, cntr_value, cntr_type
FROM sys.dm_os_performance_counters
WHERE object_name LIKE N'%:Buffer Manager'
  AND counter_name IN
      (N'Buffer cache hit ratio', N'Buffer cache hit ratio base');

نکته کاربردی: cntr_type نشان می‌دهد این Counter از نوع fraction است و Base مکمل محاسبه محسوب می‌شود.

مثال 2: محاسبه درصد صحیح

Numerator بر Base تقسیم و در صد ضرب می‌شود. Decimal مانع تقسیم صحیح و حذف بخش اعشاری می‌گردد.

WITH C AS
(
    SELECT counter_name, cntr_value
    FROM sys.dm_os_performance_counters
    WHERE object_name LIKE N'%:Buffer Manager'
      AND counter_name IN
          (N'Buffer cache hit ratio', N'Buffer cache hit ratio base')
)
SELECT CAST(100.0 *
       MAX(CASE WHEN counter_name = N'Buffer cache hit ratio' THEN cntr_value END) /
       NULLIF(MAX(CASE WHEN counter_name = N'Buffer cache hit ratio base' THEN cntr_value END), 0)
       AS decimal(6,2)) AS CacheHitPercent
FROM C;

نکته کاربردی: درصد بالا را به‌تنهایی نشانه نبود مشکل ندانید؛ حجم داده و Page Reads/sec نیز اهمیت دارد.

مثال 3: جلوگیری از تقسیم بر صفر

NULLIF مخرج صفر را به NULL تبدیل می‌کند تا Collector به‌جای خطای اجرا، نبود نسبت معتبر را ثبت کند.

DECLARE @Numerator bigint = 0, @Base bigint = 0;
SELECT CAST(100.0 * @Numerator / NULLIF(@Base, 0) AS decimal(6,2)) AS SafePercent;

نکته کاربردی: NULL را با صفر درصد جایگزین نکنید؛ صفر واقعی با نبود Sample تفاوت معنایی دارد.

مثال 4: نمونه‌برداری زمان‌دار از نسبت

در هر Snapshot، Numerator و Base همان لحظه ثبت می‌شوند تا جفت‌بودن داده‌ها حفظ شود.

SELECT SYSDATETIME() AS SampleTime,
       MAX(CASE WHEN counter_name = N'Buffer cache hit ratio' THEN cntr_value END) AS Numerator,
       MAX(CASE WHEN counter_name = N'Buffer cache hit ratio base' THEN cntr_value END) AS BaseValue
FROM sys.dm_os_performance_counters
WHERE object_name LIKE N'%:Buffer Manager'
  AND counter_name IN
      (N'Buffer cache hit ratio', N'Buffer cache hit ratio base');

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

مثال 5: مقایسه درصد با Page Reads/sec

نسبت Cache و خواندن فیزیکی کنار هم قرار می‌گیرند. افت نسبت همراه رشد Read فیزیکی سیگنال قوی‌تری از فشار I/O است.

WITH P AS
(
    SELECT counter_name, cntr_value
    FROM sys.dm_os_performance_counters
    WHERE object_name LIKE N'%:Buffer Manager'
      AND counter_name IN
          (N'Buffer cache hit ratio', N'Buffer cache hit ratio base', N'Page reads/sec')
)
SELECT MAX(CASE WHEN counter_name = N'Page reads/sec' THEN cntr_value END) AS PageReadsRaw,
       CAST(100.0 * MAX(CASE WHEN counter_name = N'Buffer cache hit ratio' THEN cntr_value END) /
            NULLIF(MAX(CASE WHEN counter_name = N'Buffer cache hit ratio base' THEN cntr_value END), 0) AS decimal(6,2)) AS HitPercent
FROM P;

نکته کاربردی: برای Page Reads/sec مقدار خام تجمعی است؛ در داشبورد نرخ آن را از Delta محاسبه کنید.

مثال 6: محاسبه چند Snapshot تاریخی

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

DECLARE @H table
(
    SampleTime datetime2(0),
    Numerator bigint,
    BaseValue bigint
);
INSERT @H VALUES
('2026-07-22T10:00:00', 9900, 10000),
('2026-07-22T10:01:00', 9400, 10000),
('2026-07-22T10:02:00', 9850, 10000);
SELECT SampleTime,
       CAST(100.0 * Numerator / NULLIF(BaseValue, 0) AS decimal(6,2)) AS HitPercent
FROM @H
ORDER BY SampleTime;

نکته کاربردی: ذخیره Numerator و Base امکان بازحساب و کنترل کیفیت را بهتر از ذخیره تنها درصد فراهم می‌کند.

مثال 7: یافتن افت بیش از دو درصد

LAG درصد قبلی را می‌سازد و Query افت ناگهانی را مشخص می‌کند؛ این روش از آستانه ثابت حساس‌تر است.

WITH H AS
(
    SELECT * FROM (VALUES
      (CONVERT(datetime2(0), '2026-07-22T10:00:00'), CAST(99.1 AS decimal(5,2))),
      (CONVERT(datetime2(0), '2026-07-22T10:01:00'), CAST(96.4 AS decimal(5,2))),
      (CONVERT(datetime2(0), '2026-07-22T10:02:00'), CAST(98.2 AS decimal(5,2)))
    ) v(SampleTime, HitPercent)
), D AS
(
    SELECT *, LAG(HitPercent) OVER (ORDER BY SampleTime) AS PreviousPercent
    FROM H
)
SELECT SampleTime, HitPercent, PreviousPercent
FROM D
WHERE PreviousPercent - HitPercent >= 2.0;

نکته کاربردی: افت را با Deploy، ETL، Backup یا اسکن گزارش هم‌زمان تطبیق دهید.

مثال 8: طبقه‌بندی وضعیت برای داشبورد

یک درصد محاسبه‌شده با مرزهای نمونه دسته‌بندی می‌شود. این مرزها باید بر اساس Baseline و بار کاری بازتنظیم شوند.

DECLARE @HitPercent decimal(6,2) = 96.40;
SELECT @HitPercent AS HitPercent,
       CASE
         WHEN @HitPercent >= 99 THEN N'مطلوب'
         WHEN @HitPercent >= 95 THEN N'قابل بررسی'
         ELSE N'بحرانی'
       END AS HealthState;

نکته کاربردی: برای جلوگیری از هشدار کاذب، چند نمونه متوالی و نرخ Page Reads را شرط دوم قرار دهید.

مثال 9: روش اشتباه خواندن مستقیم Counter

در روش اشتباه Numerator به‌عنوان درصد نمایش داده می‌شود. نسخه صحیح Base را نیز وارد فرمول می‌کند.

DECLARE @Numerator bigint = 98765, @Base bigint = 100000;
SELECT @Numerator AS WrongPercent,
       CAST(100.0 * @Numerator / NULLIF(@Base, 0) AS decimal(6,2)) AS CorrectPercent;

نکته کاربردی: Dashboard باید فرمول Counterهای fraction را در Metadata داشته باشد، نه اینکه همه cntr_valueها را یکسان نمایش دهد.

مثال 10: Query نهایی کم‌هزینه و دقیق

یک CTE کوچک تنها دو نام لازم را می‌خواند و درصد را در همان Statement محاسبه می‌کند.

WITH C AS
(
    SELECT counter_name, cntr_value
    FROM sys.dm_os_performance_counters
    WHERE object_name LIKE N'%:Buffer Manager'
      AND counter_name IN
          (N'Buffer cache hit ratio', N'Buffer cache hit ratio base')
)
SELECT CAST(100.0 *
       MAX(CASE WHEN counter_name = N'Buffer cache hit ratio' THEN cntr_value END) /
       NULLIF(MAX(CASE WHEN counter_name = N'Buffer cache hit ratio base' THEN cntr_value END), 0)
       AS decimal(6,2)) AS CacheHitPercent
FROM C;
-- این Query را در Collector زمان‌بندی‌شده اجرا کنید.

نکته کاربردی: فاصله نمونه‌برداری و Retention را متناسب با نیاز عیب‌یابی تعیین کنید؛ Poll بی‌دلیل در هر میلی‌ثانیه ارزش تحلیلی ایجاد نمی‌کند.

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

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

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

خطای سوم، تفسیر یک نقطه بدون Baseline است. وضعیت Buffer Cache Hit Ratio بین سامانه OLTP، انبار داده، گزارش شبانه و دوره نگهداری متفاوت است. حد هشدار را از صدک‌های تاریخچه سالم استخراج کنید و رخداد را تنها زمانی بحرانی بدانید که چند نمونه ادامه یافته و یک سیگنال مکمل مانند Page reads/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 باید با نیاز قانونی و هزینه ذخیره‌سازی سازگار باشد.

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

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

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

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

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

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

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

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

Buffer Cache Hit Ratio چیست و چه چیزی را اندازه می‌گیرد؟

محاسبه سهم درخواست‌های صفحه که از حافظه پاسخ گرفته‌اند است. نسبت نزدیک به صد معمولاً مطلوب است اما میانگین بلندمدت می‌تواند افت‌های کوتاه و مهم را پنهان کند. این Counter باید در کنار زمان نمونه، نوع شمارنده و شرایط بارکاری ثبت شود تا عدد خام به اطلاعات عملیاتی تبدیل گردد.

چگونه مقدار Buffer Cache Hit Ratio را از SQL Server بخوانیم؟

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

آیا استفاده تجاری از داشبورد Buffer Cache Hit Ratio ارزش دارد؟

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

برای گزارش مدیریتی Buffer Cache Hit Ratio چه اطلاعاتی لازم است؟

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

تفاوت Buffer Cache Hit Ratio با Page reads/sec چیست؟

Buffer Cache Hit Ratio بر «محاسبه سهم درخواست‌های صفحه که از حافظه پاسخ گرفته‌اند» تمرکز دارد، در حالی که Page reads/sec زاویه مکمل دیگری از همان سامانه ارائه می‌کند. هیچ‌یک جای دیگری را نمی‌گیرد و هم‌بستگی روند آن‌ها برای تشخیص فشار، ظرفیت یا رقابت قابل‌اعتمادتر است.

برای پیاده‌سازی حرفه‌ای پایش Buffer Cache Hit Ratio از کجا شروع کنیم؟

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

رایج‌ترین خطا هنگام خواندن Buffer Cache Hit Ratio چیست؟

رایج‌ترین خطا نادیده‌گرفتن cntr_type، Instance یا Restart سرویس است. مقدار numerator باید بر Buffer cache hit ratio base تقسیم شود؛ خواندن مستقیم cntr_value درصد واقعی نیست. همچنین نبود ردیف نباید به‌طور خام با صفر واقعی جایگزین شود؛ Availability باید جداگانه ذخیره گردد.

پایش Buffer Cache Hit Ratio چه اثری بر Performance دارد؟

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

بهترین روش هشداردهی برای Buffer Cache Hit Ratio چیست؟

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

Buffer Cache Hit Ratio در کدام نسخه‌های SQL Server قابل استفاده است؟

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

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

چرا مقدار خام Buffer Cache Hit Ratio همیشه قابل گزارش نیست؟

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

چگونه هشدار کاذب Buffer Cache Hit Ratio را کم می‌کنید؟

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

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

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

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

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

برای ریشه‌یابی وضعیت غیرعادی Buffer Cache Hit Ratio چه ابزارهایی لازم است؟

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

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

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

جمع‌بندی

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

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