کنترل Row Mode Memory Grant Feedback؛ آموزش کامل ROW_MODE_MEMORY_GRANT_FEEDBACK در SQL Server
در بسیاری از OLTPها Row Mode غالب است؛ بنابراین Memory Grant فقط مسئله Columnstore نیست. Sort و Hash روی تخمین اشتباه میتوانند حافظه و tempdb را تحت فشار بگذارند.
Row Mode Memory Grant Feedback دامنه اصلاح Grant را به Queryهای Row Mode گسترش میدهد و برای Sort و Hashهای تکراری با Grant نامناسب کاربرد دارد. در این مقاله از Syntax و خواندن مقدار فعلی شروع میکنیم و بعد به سناریوی واقعی، روش اندازهگیری، خطاهای رایج و تصمیم Production میرسیم.
برای دیدن ارتباط این گزینه با سایر تنظیمات، راهنمای جامع Database Scoped Performance Configuration را هم ببینید.
تعریف و منطق فنی
تنظیم تطبیقی Memory Grant برای Queryهایی که در Row Mode اجرا میشوند.
Row Mode Memory Grant Feedback دامنه اصلاح Grant را به Queryهای Row Mode گسترش میدهد و برای Sort و Hashهای تکراری با Grant نامناسب کاربرد دارد.
اصل عملی: تنظیم Performance فقط وقتی ارزش دارد که مسئله، معیار موفقیت و راه برگشت آن از قبل روشن باشد.
Syntax اصلی
ALTER DATABASE SCOPED CONFIGURATION SET ROW_MODE_MEMORY_GRANT_FEEDBACK = ON;
مقادیر و رفتار
- مقدار یا فرمان: ON یا OFF.
- سناریوی مناسب: گزارش عملیاتی روی Rowstore با Sortهای بزرگ و Hash Aggregate تکراری
- ریسک اصلی: تغییر شدید Cardinality بین اجراها میتواند Feedback را ناپایدار کند؛ Query Store و Runtime باید بررسی شوند.
- نکته نسخه: Row Mode Memory Grant Feedback در SQL Server 2019 معرفی شد و بخشی از Intelligent Query Processing است.
این نقشه رابطه ROW_MODE_MEMORY_GRANT_FEEDBACK را با Memory Grant، Sort و شاخصهای Runtime نشان میدهد. تصویر برای فهم دامنه اثر است و جای Execution Plan واقعی را نمیگیرد.
چطور قبل از تغییر تصمیم بگیریم
قبل از اجرای تغییر، Queryهای نماینده را بر اساس اهمیت تجاری و مصرف منابع جدا کنید. Plan آنها را در Query Store نگه دارید و فقط یک متغیر را تغییر دهید. اگر همزمان Index، Compatibility Level و ROW_MODE_MEMORY_GRANT_FEEDBACK را عوض کنید، Attribution نتیجه از بین میرود.
معیار تک Query و معیار کل Workload را جدا ببینید. ممکن است یک Query سریعتر شود اما Throughput کل افت کند. تغییر شدید Cardinality بین اجراها میتواند Feedback را ناپایدار کند؛ Query Store و Runtime باید بررسی شوند. به همین دلیل Concurrency و مصرف منابع باید کنار زمان پاسخ سنجیده شود.
اشتباه رایج: خاموشکردن Feedback به دلیل یک نوسان مقطعی بدون بررسی الگوی تکرارشونده در Query Store. راه حرفهای این است که فرضیه، Baseline، Change و Rollback در یک سند کوتاه و قابل بازبینی ثبت شوند.
جریان ROW_MODE_MEMORY_GRANT_FEEDBACK از مشاهده وضعیت، اعمال Change، Compile یا Runtime Behavior و سپس Measure عبور میکند. نقاط اندازهگیری قبل و بعد باید یکسان باشند.
۱۰ مثال عملی و قابل اجرا
مثال 1: مشاهده وضعیت واقعی قبل از تغییر
برای کنترل Row Mode Memory Grant Feedback اولین قدم تغییر نیست؛ ثبت وضعیت فعلی است. خروجی را همراه زمان، نسخه و نام Database نگه دارید تا Baseline قابل استناد باشد.
SELECT name, value, value_for_secondary
FROM sys.database_scoped_configurations
WHERE name = N'ROW_MODE_MEMORY_GRANT_FEEDBACK';
| name | value | برداشت |
|---|
| ROW_MODE_MEMORY_GRANT_FEEDBACK | مقدار فعلی | از همان سرور خوانده شود |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
مثال 2: فعالسازی کنترلشده در محیط آزمایشی
در این سناریو ROW_MODE_MEMORY_GRANT_FEEDBACK را فقط جایی تغییر میدهیم که Baseline داریم. یک اجرای سریع برای تصمیم نهایی کافی نیست و باید چند چرخه کاری قابل مقایسه سنجیده شود.
ALTER DATABASE SCOPED CONFIGURATION SET ROW_MODE_MEMORY_GRANT_FEEDBACK = ON;
| عملیات | خروجی نمونه | کنترل |
|---|
| ROW_MODE_MEMORY_GRANT_FEEDBACK | Command completed successfully | مقدار دوباره خوانده شود |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
مثال 3: بازگشت مستند به رفتار قبلی
Performance Change بدون Rollback کامل نیست. چون تغییر شدید Cardinality بین اجراها میتواند Feedback را ناپایدار کند؛ Query Store و Runtime باید بررسی شوند.، فرمان بازگشت باید پیش از Deployment آماده باشد و تیم در زمان Incident بداههکاری نکند.
ALTER DATABASE SCOPED CONFIGURATION SET ROW_MODE_MEMORY_GRANT_FEEDBACK = OFF;
| Rollback | خروجی نمونه | معیار |
|---|
| ROW_MODE_MEMORY_GRANT_FEEDBACK | Command completed successfully | رفتار قبلی تأیید شود |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
مثال 4: بررسی Compatibility Level
بسیاری از قابلیتها به Compatibility Level وابستهاند. پیش از نتیجهگیری درباره ROW_MODE_MEMORY_GRANT_FEEDBACK، نسخه Engine و سطح سازگاری Database را کنار هم ثبت کنید.
SELECT DB_NAME() AS DatabaseName, compatibility_level
FROM sys.databases
WHERE database_id = DB_ID();
| Database | compatibility_level | نکته |
|---|
| CurrentDatabase | 150/160/170 | وابسته به نسخه و محیط |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
مثال 5: مقایسه قبل و بعد با Query Store
Query Store امکان دیدن Plan و Runtime را در دو بازه زمانی میدهد. برای کنترل Row Mode Memory Grant Feedback این داده تاریخی بسیار قابل اعتمادتر از یک Screenshot یا حس کلی کاربر است.
SELECT TOP (20) qsq.query_id, qsp.plan_id, rs.avg_duration, rs.avg_cpu_time
FROM sys.query_store_query AS qsq
JOIN sys.query_store_plan AS qsp ON qsp.query_id = qsq.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = qsp.plan_id
ORDER BY rs.avg_duration DESC;
| منبع | خروجی | تفسیر |
|---|
| Query Store | Plan/Runtime rows | بازه قبل و بعد همسطح باشد |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
مثال 6: ساخت Workload کوچک و قابل تکرار
Workload آزمایشی باید همان رفتاری را تحریک کند که Feature برای آن ساخته شده است: تنظیم تطبیقی Memory Grant برای Queryهایی که در Row Mode اجرا میشوند. 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 | وابسته به داده | چند اجرا مقایسه شود |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
مثال 7: خواندن شاخص Runtime مرتبط
یک DMV بهتنهایی حقیقت کامل Performance نیست. برای ROW_MODE_MEMORY_GRANT_FEEDBACK داده 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 | نمونه | برداشت |
|---|
| Sort | قابل اندازهگیری | روند مهمتر از Snapshot است |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
مثال 8: پیداکردن Queryهای پرریسک
بهجای جستوجوی تصادفی، Queryهای پرتکرار یا پرمصرف را جدا کنید و ببینید آیا مشکل واقعاً با تنظیم تطبیقی Memory Grant برای Queryهایی که در Row Mode اجرا میشوند ارتباط دارد یا علت اصلی Statistics، Index، Blocking یا طراحی Query است.
SELECT TOP (20) qs.execution_count, qs.total_worker_time, qs.total_elapsed_time,
SUBSTRING(st.text,1,300) AS sample_sql
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY qs.total_worker_time DESC;
| Query | نشانه | اقدام |
|---|
| Top workload | CPU/Duration/Spill | Plan واقعی بررسی شود |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
مثال 9: قرار دادن Guard در Deployment
Deployment حرفهای باید Fail Fast باشد. Guard نسخهای کمک میکند تغییر ROW_MODE_MEMORY_GRANT_FEEDBACK روی محیطی که ارزیابی نشده اجرا نشود و رفتار غیرمنتظره نسازد.
IF CAST(SERVERPROPERTY('ProductMajorVersion') AS int) >= 13
BEGIN
ALTER DATABASE SCOPED CONFIGURATION SET ROW_MODE_MEMORY_GRANT_FEEDBACK = ON;
END
ELSE
THROW 50010, N'نسخه موتور برای این Deployment بررسی شود.', 1;
| Deployment | Result | Safety |
|---|
| Version guard | Pass/Throw | اجرای کنترلشده |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
مثال 10: Rollback و تأیید مقدار نهایی
Rollback فقط اجرای Command معکوس نیست. مقدار نهایی، Planهای مهم و Metricهای Baseline باید دوباره کنترل شوند تا بازگشت واقعاً تأیید شود.
-- Rollback کنترلشده
ALTER DATABASE SCOPED CONFIGURATION SET ROW_MODE_MEMORY_GRANT_FEEDBACK = OFF;
SELECT name, value, value_for_secondary
FROM sys.database_scoped_configurations
WHERE name = N'ROW_MODE_MEMORY_GRANT_FEEDBACK';
| مرحله | خروجی | معیار پایان |
|---|
| Rollback | تنظیم قبلی | Baseline دوباره کنترل شود |
خروجی جدول فقط شکل نمونه نتیجه را نشان میدهد. مقدار واقعی ROW_MODE_MEMORY_GRANT_FEEDBACK به نسخه، داده و بار سیستم شما وابسته است؛ خروجی واقعی را با Timestamp ذخیره کنید.
خطاهای رایج
- خاموشکردن Feedback به دلیل یک نوسان مقطعی بدون بررسی الگوی تکرارشونده در Query Store.
- اعمال چند تغییر Performance در یک Release و از دست دادن امکان تشخیص علت.
- مقایسه Warm Cache با Cold Cache و نتیجهگیری قطعی.
- نادیده گرفتن تفاوت نسخه، CU و Compatibility Level بین Test و Production.
- تمرکز فقط روی Duration و ندیدن CPU، Reads، Memory، Spill، Blocking یا Throughput.
Performance Considerations
اثر ROW_MODE_MEMORY_GRANT_FEEDBACK را با Metric همان Feature بسنجید. مفاهیم کلیدی این مقاله: Row Mode, Memory Grant, Sort, Hash, Feedback. اگر معیار انتخابی با این زنجیره ارتباطی ندارد، آزمایش ممکن است نتیجه گمراهکننده بدهد.
تغییر شدید Cardinality بین اجراها میتواند Feedback را ناپایدار کند؛ Query Store و Runtime باید بررسی شوند. این ریسک دلیل طراحی آزمایش بهتر است، نه دلیل تصمیم عجولانه. Query Store، Actual Plan و DMVهای Runtime را کنار هم ببینید.
بهترین روشها
- مقدار فعلی، نسخه Engine و Compatibility Level را ثبت کنید.
- Baseline Queryهای حیاتی را بگیرید.
- تغییر را ابتدا در محیط مشابه Production یا بازه کمریسک اجرا کنید.
- فقط یک متغیر Performance را عوض کنید.
- Rollback را پیش از Deployment بنویسید.
- Plan و Runtime را در چند بازه بررسی کنید.
- اگر نتیجه مبهم است تغییر را دائمی نکنید.
سناریوی عملی ROW_MODE_MEMORY_GRANT_FEEDBACK سه بخش دارد: Baseline، تغییر کنترلشده و تصمیم بر اساس Measure. حذف هر کدام کیفیت تصمیم را پایین میآورد.
سؤالات متداول
ROW_MODE_MEMORY_GRANT_FEEDBACK دقیقاً چه مشکلی را هدف میگیرد؟
برای تنظیم تطبیقی Memory Grant برای Queryهایی که در Row Mode اجرا میشوند طراحی شده است. ارزش آن زمانی روشن میشود که قبل از تغییر Baseline داشته باشید و اثر را روی Workload واقعی بسنجید.
مقدار فعلی ROW_MODE_MEMORY_GRANT_FEEDBACK را چگونه ببینیم؟
از sys.database_scoped_configurations شروع کنید و خروجی را کنار نسخه Engine، Compatibility Level و وضعیت Query Store ثبت کنید.
آیا ROW_MODE_MEMORY_GRANT_FEEDBACK همیشه SQL Server را سریعتر میکند؟
خیر. تغییر شدید Cardinality بین اجراها میتواند Feedback را ناپایدار کند؛ Query Store و Runtime باید بررسی شوند. بنابراین CPU، Duration، Reads و Metric مرتبط با Feature باید قبل و بعد مقایسه شوند.
چه سناریوی تجاری برای ROW_MODE_MEMORY_GRANT_FEEDBACK مناسب است؟
نمونه روشن: گزارش عملیاتی روی Rowstore با Sortهای بزرگ و Hash Aggregate تکراری. در پروژه واقعی Change Window، Rollback و معیار موفقیت را قبل از تغییر تعریف کنید.
ROW_MODE_MEMORY_GRANT_FEEDBACK چه تفاوتی با تنظیم سراسری دارد؟
Database Scoped Configuration دامنه اثر را محدودتر میکند و برای Instanceهای چند Workload کنترل دقیقتری میدهد؛ با این حال Hintهای Query و تنظیمات دیگر ممکن است رفتار نهایی را تغییر دهند.
برای پیادهسازی حرفهای ROW_MODE_MEMORY_GRANT_FEEDBACK چه کاری لازم است؟
بررسی Query Store، Execution Plan، Baseline، تست بار و Rollback. آموزش و مشاوره زمانی مفید است که تصمیم بر اساس داده همان سامانه گرفته شود.
رایجترین خطا درباره ROW_MODE_MEMORY_GRANT_FEEDBACK چیست؟
خاموشکردن Feedback به دلیل یک نوسان مقطعی بدون بررسی الگوی تکرارشونده در Query Store. این کار اغلب یک درمان موقت را به سیاست دائمی تبدیل میکند.
اثر Performance ROW_MODE_MEMORY_GRANT_FEEDBACK را چگونه بسنجیم؟
بازههای همسطح را مقایسه کنید و CPU، Duration، Reads و Metric تخصصی Feature را بسنجید. Query Store برای Plan Regression بسیار مفید است.
Best Practice تغییر ROW_MODE_MEMORY_GRANT_FEEDBACK چیست؟
تغییر را کوچک، مستند و قابل برگشت نگه دارید؛ فقط یک متغیر Performance را در هر آزمایش عوض کنید و نتیجه را چند بار بسنجید.
ROW_MODE_MEMORY_GRANT_FEEDBACK با چه نسخههایی سازگار است؟
Row Mode Memory Grant Feedback در SQL Server 2019 معرفی شد و بخشی از Intelligent Query Processing است. مستندات همان نسخه و Compatibility Level محیط خود را ملاک نهایی قرار دهید.
سؤالات مصاحبه
- چرا برای ROW_MODE_MEMORY_GRANT_FEEDBACK Baseline لازم است؟
- اگر بعد از تغییر ROW_MODE_MEMORY_GRANT_FEEDBACK یک Query بهتر و چند Query بدتر شوند چه میکنید؟
- Query Store در ارزیابی کنترل Row Mode Memory Grant Feedback چه نقشی دارد؟
- چطور مشکل Statistics را از اثر ROW_MODE_MEMORY_GRANT_FEEDBACK جدا میکنید؟
- Rollback شما برای ROW_MODE_MEMORY_GRANT_FEEDBACK در Production چیست؟
چکلیست نهایی
- مقدار فعلی ROW_MODE_MEMORY_GRANT_FEEDBACK ثبت شده است.
- Baseline مشخص است.
- نسخه و Compatibility Level کنترل شدهاند.
- معیار موفقیت و شکست نوشته شدهاند.
- Rollback آماده است.
- Query Store و Planهای مهم بعد از تغییر بررسی میشوند.
جمعبندی
کنترل Row Mode Memory Grant Feedback زمانی مفید است که با مسئله واقعی و قابل اندازهگیری استفاده شود. تنظیم تطبیقی Memory Grant برای Queryهایی که در Row Mode اجرا میشوند. بهجای تغییر بر اساس توصیه عمومی، Workload خودتان را بسنجید و تغییر را قابل برگشت نگه دارید.
برای مقایسه این گزینه با سایر اعضای همین خانواده به مقاله مادر تنظیمات Performance در سطح Database برگردید.
خدمات برنامهنویسی و پایگاه داده
برنامهنویسی در اصفهان؛ قبول سفارشهای برنامهنویسی و پایگاه داده: 09131253620. انجام پروژه، آموزش برنامهنویسی و آموزش پایگاه داده SQL Server برای پروژههای آموزشی، سازمانی و تجاری.
مجموعهای معتبر با سابقه فعالیت حرفهای از سال ۱۳۷۵ شمسی
از سال ۱۳۷۵ شمسی تاکنون در زمینه طراحی و اجرای پروژههای برنامهنویسی، پایگاه داده، سیستمهای تحت وب، وبسایت و راهکارهای نرمافزاری فعالیت میکنیم.
برای سفارش پروژههای برنامهنویسی و پایگاه داده، سیستمهای تحت وب، وبسایت و راهکارهای نرمافزاری جدید با شماره 09131253620 تماس حاصل فرمایید.
ایتا، واتساپ و تماس مستقیم: +989131253620
تماس با ما