MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT در SQL Server | آموزش تنظیم، مثال و نکات Performance

آموزش MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT در SQL Server؛ Percentile Memory Grant Feedback با مثال عملی

توسط admin | گروه SQL Server | 1405/05/01

نظرات 0

Percentile Memory Grant Feedback؛ آموزش کامل MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT در SQL Server

آخرین اجرا همیشه بهترین نماینده آینده نیست. وقتی اندازه ورودی Query بالا و پایین می‌شود، Grant مبتنی بر سابقه می‌تواند از واکنش افراطی به یک اجرای استثنایی جلوگیری کند.

در Queryهایی که مصرف حافظه بین اجراها تغییر می‌کند، نگاه به مجموعه اجراهای قبلی می‌تواند Grant باثبات‌تری بسازد و رفتار رفت‌وبرگشتی را کمتر کند. در این مقاله از Syntax و خواندن مقدار فعلی شروع می‌کنیم و بعد به سناریوی واقعی، روش اندازه‌گیری، خطاهای رایج و تصمیم Production می‌رسیم.

برای دیدن ارتباط این گزینه با سایر تنظیمات، راهنمای جامع Database Scoped Performance Configuration را هم ببینید.

تعریف و منطق فنی

محاسبه Memory Grant بر اساس توزیع اجراهای قبلی به‌جای تکیه ساده بر آخرین اجرا.

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

اصل عملی: تنظیم Performance فقط وقتی ارزش دارد که مسئله، معیار موفقیت و راه برگشت آن از قبل روشن باشد.

Syntax اصلی

ALTER DATABASE SCOPED CONFIGURATION SET MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT = ON;

مقادیر و رفتار

  • مقدار یا فرمان: ON یا OFF.
  • سناریوی مناسب: گزارش فروش با بازه تاریخ از یک روز تا چند سال و مصرف حافظه بسیار متفاوت
  • ریسک اصلی: اگر Query ماهیت کاملاً چندشکلی داشته باشد، یک Percentile هم برای همه الگوها مناسب نیست و Query Design مهم می‌ماند.
  • نکته نسخه: Percentile mode برای Memory Grant Feedback در SQL Server 2022 معرفی شد و با Query Store و Feedback جدید مرتبط است.
MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT - نمودار فنی 1نقشه معماری MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT و اجزای مرتبط در SQL ServerMEMORY_GRANT_FEEDBACK_PERCENTILE_GRANTPercentile GrantMemory GrantHistoryQuery StoreVarianceStabilityPercentile GrantMemory GrantHistoryQuery Store

این نقشه رابطه MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT را با Memory Grant، History و شاخص‌های Runtime نشان می‌دهد. تصویر برای فهم دامنه اثر است و جای Execution Plan واقعی را نمی‌گیرد.

چطور قبل از تغییر تصمیم بگیریم

قبل از اجرای تغییر، Queryهای نماینده را بر اساس اهمیت تجاری و مصرف منابع جدا کنید. Plan آنها را در Query Store نگه دارید و فقط یک متغیر را تغییر دهید. اگر هم‌زمان Index، Compatibility Level و MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT را عوض کنید، Attribution نتیجه از بین می‌رود.

معیار تک Query و معیار کل Workload را جدا ببینید. ممکن است یک Query سریع‌تر شود اما Throughput کل افت کند. اگر Query ماهیت کاملاً چندشکلی داشته باشد، یک Percentile هم برای همه الگوها مناسب نیست و Query Design مهم می‌ماند. به همین دلیل Concurrency و مصرف منابع باید کنار زمان پاسخ سنجیده شود.

اشتباه رایج: انتظار داشتن که Percentile Grant مشکل Predicate بد یا Statistics قدیمی را بدون اصلاح ریشه‌ای حل کند. راه حرفه‌ای این است که فرضیه، Baseline، Change و Rollback در یک سند کوتاه و قابل بازبینی ثبت شوند.

MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT - نمودار فنی 2جریان اجرای MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT از پیکربندی تا RuntimeMEMORY_GRANT_FEEDBACK_PERCENTILE_GRANTALTERPercentile GrantOptimizerHistoryRuntimeVarianceStabilityPercentile GrantMemory GrantHistoryQuery Store

جریان MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT از مشاهده وضعیت، اعمال Change، Compile یا Runtime Behavior و سپس Measure عبور می‌کند. نقاط اندازه‌گیری قبل و بعد باید یکسان باشند.

۱۰ مثال عملی و قابل اجرا

مثال 1: مشاهده وضعیت واقعی قبل از تغییر

برای Percentile Memory Grant Feedback اولین قدم تغییر نیست؛ ثبت وضعیت فعلی است. خروجی را همراه زمان، نسخه و نام Database نگه دارید تا Baseline قابل استناد باشد.

SELECT name, value, value_for_secondary
FROM sys.database_scoped_configurations
WHERE name = N'MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT';
namevalueبرداشت
MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANTمقدار فعلیاز همان سرور خوانده شود

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

مثال 2: فعال‌سازی کنترل‌شده در محیط آزمایشی

در این سناریو MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT را فقط جایی تغییر می‌دهیم که Baseline داریم. یک اجرای سریع برای تصمیم نهایی کافی نیست و باید چند چرخه کاری قابل مقایسه سنجیده شود.

ALTER DATABASE SCOPED CONFIGURATION SET MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT = ON;
عملیاتخروجی نمونهکنترل
MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANTCommand completed successfullyمقدار دوباره خوانده شود

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

مثال 3: بازگشت مستند به رفتار قبلی

Performance Change بدون Rollback کامل نیست. چون اگر Query ماهیت کاملاً چندشکلی داشته باشد، یک Percentile هم برای همه الگوها مناسب نیست و Query Design مهم می‌ماند.، فرمان بازگشت باید پیش از Deployment آماده باشد و تیم در زمان Incident بداهه‌کاری نکند.

ALTER DATABASE SCOPED CONFIGURATION SET MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT = OFF;
Rollbackخروجی نمونهمعیار
MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANTCommand completed successfullyرفتار قبلی تأیید شود

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

مثال 4: بررسی Compatibility Level

بسیاری از قابلیت‌ها به Compatibility Level وابسته‌اند. پیش از نتیجه‌گیری درباره MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT، نسخه Engine و سطح سازگاری Database را کنار هم ثبت کنید.

SELECT DB_NAME() AS DatabaseName, compatibility_level
FROM sys.databases
WHERE database_id = DB_ID();
Databasecompatibility_levelنکته
CurrentDatabase150/160/170وابسته به نسخه و محیط

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

مثال 5: مقایسه قبل و بعد با Query Store

Query Store امکان دیدن Plan و Runtime را در دو بازه زمانی می‌دهد. برای Percentile Memory Grant Feedback این داده تاریخی بسیار قابل اعتمادتر از یک Screenshot یا حس کلی کاربر است.

SELECT desired_state_desc, actual_state_desc, readonly_reason
FROM sys.database_query_store_options;
منبعخروجیتفسیر
Query StorePlan/Runtime rowsبازه قبل و بعد هم‌سطح باشد

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

مثال 6: ساخت Workload کوچک و قابل تکرار

Workload آزمایشی باید همان رفتاری را تحریک کند که Feature برای آن ساخته شده است: محاسبه Memory Grant بر اساس توزیع اجراهای قبلی به‌جای تکیه ساده بر آخرین اجرا. Query خیلی کوچک ممکن است هیچ تفاوتی نشان ندهد.

SET STATISTICS IO ON;
SET STATISTICS TIME ON;
SELECT TOP (1000) object_id, name, type_desc
FROM sys.objects
ORDER BY object_id DESC;
SET STATISTICS TIME OFF;
SET STATISTICS IO OFF;
Metricنمونهنکته
Elapsed/CPU/Readsوابسته به دادهچند اجرا مقایسه شود

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

مثال 7: خواندن شاخص Runtime مرتبط

یک DMV به‌تنهایی حقیقت کامل Performance نیست. برای MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT داده Runtime را کنار Execution Plan، Query Store و وضعیت منابع قرار دهید.

SELECT TOP (20) session_id, requested_memory_kb, granted_memory_kb, required_memory_kb, used_memory_kb
FROM sys.dm_exec_query_memory_grants
ORDER BY requested_memory_kb DESC;
Runtime signalنمونهبرداشت
Historyقابل اندازه‌گیریروند مهم‌تر از Snapshot است

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

مثال 8: پیداکردن Queryهای پرریسک

به‌جای جست‌وجوی تصادفی، Queryهای پرتکرار یا پرمصرف را جدا کنید و ببینید آیا مشکل واقعاً با محاسبه Memory Grant بر اساس توزیع اجراهای قبلی به‌جای تکیه ساده بر آخرین اجرا ارتباط دارد یا علت اصلی Statistics، Index، Blocking یا طراحی Query است.

SELECT TOP (50) *
FROM sys.query_store_plan_feedback
ORDER BY last_updated_time DESC;
Queryنشانهاقدام
Top workloadCPU/Duration/SpillPlan واقعی بررسی شود

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

مثال 9: قرار دادن Guard در Deployment

Deployment حرفه‌ای باید Fail Fast باشد. Guard نسخه‌ای کمک می‌کند تغییر MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT روی محیطی که ارزیابی نشده اجرا نشود و رفتار غیرمنتظره نسازد.

IF CAST(SERVERPROPERTY('ProductMajorVersion') AS int) >= 13
BEGIN
    ALTER DATABASE SCOPED CONFIGURATION SET MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT = ON;
END
ELSE
    THROW 50010, N'نسخه موتور برای این Deployment بررسی شود.', 1;
DeploymentResultSafety
Version guardPass/Throwاجرای کنترل‌شده

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

مثال 10: Rollback و تأیید مقدار نهایی

Rollback فقط اجرای Command معکوس نیست. مقدار نهایی، Planهای مهم و Metricهای Baseline باید دوباره کنترل شوند تا بازگشت واقعاً تأیید شود.

-- Rollback کنترل‌شده
ALTER DATABASE SCOPED CONFIGURATION SET MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT = OFF;
SELECT name, value, value_for_secondary
FROM sys.database_scoped_configurations
WHERE name = N'MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT';
مرحلهخروجیمعیار پایان
Rollbackتنظیم قبلیBaseline دوباره کنترل شود

خروجی جدول فقط شکل نمونه نتیجه را نشان می‌دهد. مقدار واقعی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.

خطاهای رایج

  • انتظار داشتن که Percentile Grant مشکل Predicate بد یا Statistics قدیمی را بدون اصلاح ریشه‌ای حل کند.
  • اعمال چند تغییر Performance در یک Release و از دست دادن امکان تشخیص علت.
  • مقایسه Warm Cache با Cold Cache و نتیجه‌گیری قطعی.
  • نادیده گرفتن تفاوت نسخه، CU و Compatibility Level بین Test و Production.
  • تمرکز فقط روی Duration و ندیدن CPU، Reads، Memory، Spill، Blocking یا Throughput.

Performance Considerations

اثر MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT را با Metric همان Feature بسنجید. مفاهیم کلیدی این مقاله: Percentile Grant, Memory Grant, History, Query Store, Variance. اگر معیار انتخابی با این زنجیره ارتباطی ندارد، آزمایش ممکن است نتیجه گمراه‌کننده بدهد.

اگر Query ماهیت کاملاً چندشکلی داشته باشد، یک Percentile هم برای همه الگوها مناسب نیست و Query Design مهم می‌ماند. این ریسک دلیل طراحی آزمایش بهتر است، نه دلیل تصمیم عجولانه. Query Store، Actual Plan و DMVهای Runtime را کنار هم ببینید.

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

  1. مقدار فعلی، نسخه Engine و Compatibility Level را ثبت کنید.
  2. Baseline Queryهای حیاتی را بگیرید.
  3. تغییر را ابتدا در محیط مشابه Production یا بازه کم‌ریسک اجرا کنید.
  4. فقط یک متغیر Performance را عوض کنید.
  5. Rollback را پیش از Deployment بنویسید.
  6. Plan و Runtime را در چند بازه بررسی کنید.
  7. اگر نتیجه مبهم است تغییر را دائمی نکنید.
MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT - نمودار فنی 3سناریوی Baseline و Best Practice برای MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANTMEMORY_GRANT_FEEDBACK_PERCENTILE_GRANTBaselinePercentile GrantAfter ChangeQuery StoreMeasureVarianceBest Practice: StabilityPercentile GrantMemory GrantHistoryQuery Store

سناریوی عملی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT سه بخش دارد: Baseline، تغییر کنترل‌شده و تصمیم بر اساس Measure. حذف هر کدام کیفیت تصمیم را پایین می‌آورد.

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

MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT دقیقاً چه مشکلی را هدف می‌گیرد؟

برای محاسبه Memory Grant بر اساس توزیع اجراهای قبلی به‌جای تکیه ساده بر آخرین اجرا طراحی شده است. ارزش آن زمانی روشن می‌شود که قبل از تغییر Baseline داشته باشید و اثر را روی Workload واقعی بسنجید.

مقدار فعلی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT را چگونه ببینیم؟

از sys.database_scoped_configurations شروع کنید و خروجی را کنار نسخه Engine، Compatibility Level و وضعیت Query Store ثبت کنید.

آیا MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT همیشه SQL Server را سریع‌تر می‌کند؟

خیر. اگر Query ماهیت کاملاً چندشکلی داشته باشد، یک Percentile هم برای همه الگوها مناسب نیست و Query Design مهم می‌ماند. بنابراین CPU، Duration، Reads و Metric مرتبط با Feature باید قبل و بعد مقایسه شوند.

چه سناریوی تجاری برای MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT مناسب است؟

نمونه روشن: گزارش فروش با بازه تاریخ از یک روز تا چند سال و مصرف حافظه بسیار متفاوت. در پروژه واقعی Change Window، Rollback و معیار موفقیت را قبل از تغییر تعریف کنید.

MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT چه تفاوتی با تنظیم سراسری دارد؟

Database Scoped Configuration دامنه اثر را محدودتر می‌کند و برای Instanceهای چند Workload کنترل دقیق‌تری می‌دهد؛ با این حال Hintهای Query و تنظیمات دیگر ممکن است رفتار نهایی را تغییر دهند.

برای پیاده‌سازی حرفه‌ای MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT چه کاری لازم است؟

بررسی Query Store، Execution Plan، Baseline، تست بار و Rollback. آموزش و مشاوره زمانی مفید است که تصمیم بر اساس داده همان سامانه گرفته شود.

رایج‌ترین خطا درباره MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT چیست؟

انتظار داشتن که Percentile Grant مشکل Predicate بد یا Statistics قدیمی را بدون اصلاح ریشه‌ای حل کند. این کار اغلب یک درمان موقت را به سیاست دائمی تبدیل می‌کند.

اثر Performance MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT را چگونه بسنجیم؟

بازه‌های هم‌سطح را مقایسه کنید و CPU، Duration، Reads و Metric تخصصی Feature را بسنجید. Query Store برای Plan Regression بسیار مفید است.

Best Practice تغییر MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT چیست؟

تغییر را کوچک، مستند و قابل برگشت نگه دارید؛ فقط یک متغیر Performance را در هر آزمایش عوض کنید و نتیجه را چند بار بسنجید.

MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT با چه نسخه‌هایی سازگار است؟

Percentile mode برای Memory Grant Feedback در SQL Server 2022 معرفی شد و با Query Store و Feedback جدید مرتبط است. مستندات همان نسخه و Compatibility Level محیط خود را ملاک نهایی قرار دهید.

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

  1. چرا برای MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT Baseline لازم است؟
  2. اگر بعد از تغییر MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT یک Query بهتر و چند Query بدتر شوند چه می‌کنید؟
  3. Query Store در ارزیابی Percentile Memory Grant Feedback چه نقشی دارد؟
  4. چطور مشکل Statistics را از اثر MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT جدا می‌کنید؟
  5. Rollback شما برای MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT در Production چیست؟

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

  • مقدار فعلی MEMORY_GRANT_FEEDBACK_PERCENTILE_GRANT ثبت شده است.
  • Baseline مشخص است.
  • نسخه و Compatibility Level کنترل شده‌اند.
  • معیار موفقیت و شکست نوشته شده‌اند.
  • Rollback آماده است.
  • Query Store و Planهای مهم بعد از تغییر بررسی می‌شوند.

جمع‌بندی

Percentile Memory Grant Feedback زمانی مفید است که با مسئله واقعی و قابل اندازه‌گیری استفاده شود. محاسبه Memory Grant بر اساس توزیع اجراهای قبلی به‌جای تکیه ساده بر آخرین اجرا. به‌جای تغییر بر اساس توصیه عمومی، Workload خودتان را بسنجید و تغییر را قابل برگشت نگه دارید.

برای مقایسه این گزینه با سایر اعضای همین خانواده به مقاله مادر تنظیمات Performance در سطح Database برگردید.

خدمات برنامه‌نویسی و پایگاه داده

برنامه‌نویسی در اصفهان؛ قبول سفارش‌های برنامه‌نویسی و پایگاه داده: 09131253620. انجام پروژه، آموزش برنامه‌نویسی و آموزش پایگاه داده SQL Server برای پروژه‌های آموزشی، سازمانی و تجاری.

مجموعه‌ای معتبر با سابقه فعالیت حرفه‌ای از سال ۱۳۷۵ شمسی

از سال ۱۳۷۵ شمسی تاکنون در زمینه طراحی و اجرای پروژه‌های برنامه‌نویسی، پایگاه داده، سیستم‌های تحت وب، وب‌سایت و راهکارهای نرم‌افزاری فعالیت می‌کنیم.

برای سفارش پروژه‌های برنامه‌نویسی و پایگاه داده، سیستم‌های تحت وب، وب‌سایت و راهکارهای نرم‌افزاری جدید با شماره 09131253620 تماس حاصل فرمایید.

ایتا، واتساپ و تماس مستقیم: +989131253620

تماس با ما

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

نظرات محترم شما در خدمات رسانی بهتر ما را یاری می نمایند. لطفا اگر مایل بودید یک نظر ما را مهمان فرمائید. آدرس ایمیل و وب سایت شما نمایش داده نخواهد شد.

حرف 500 حداکثر