آموزش جامع گزارش‌های Query Store با مثال‌های عملی SQL Server

Query Store Reports یکی از ابزارها یا قابلیت‌های مهم اکوسیستم Microsoft SQL Server برای تحلیل تاریخچه اجرای کوئری‌ها و مقایسه تغییرات پلن است. این مقاله از تعریف پایه آغاز می‌کند و سپس به ساخت خط مبنا، خواندن خروجی، کنترل سربار و تبدیل مشاهده فنی به اقدام قابل سنجش می‌رسد. تمام مثال‌ها برای همین موضوع طراحی شده‌اند تا متن با مقاله‌های دیگر مجموعه هم‌پوشانی محتوایی نداشته باشد.

منبع اصلی داده در این موضوع «داده‌های ذخیره‌شده در Query Store هر پایگاه داده» است و خروجی‌های شاخص آن شامل مصرف CPU، مدت اجرا، تعداد اجرا، پلن‌های جایگزین و رگرسیون می‌شود. بنابراین پیش از فعال‌سازی ابزار باید پرسش عملکردی مشخص باشد؛ برای نمونه، آیا تیم در پی کشف رگرسیون پس از انتشار نسخه جدید است یا می‌خواهد مقایسه پلن‌های یک QueryID را ارزیابی کند؟

مسیر دسترسی سریع مقاله Query Store Reports: بازگشت به راهنمای ابزارهای گرافیکی و خارجی پایش عملکرد SQL Server.

تعریف و جایگاه Query Store Reports

جایگاه Query Store Reports در چرخه عیب‌یابی بین مشاهده، تفسیر و اقدام قرار می‌گیرد. مشاهده خام تنها می‌گوید چه چیزی رخ داده است؛ تفسیر باید آن رخداد را با ظرفیت سرور، الگوی مصرف و تغییرات نرم‌افزار مرتبط کند؛ اقدام نیز باید فرضیه‌ای قابل بازگشت داشته باشد. این ابزار برای تحلیل تاریخچه اجرای کوئری‌ها و مقایسه تغییرات پلن مناسب است، اما به‌تنهایی علت ریشه‌ای را تضمین نمی‌کند.

در یک فرایند حرفه‌ای، ابتدا بازه زمانی و معیار موفقیت ثبت می‌شود. سپس داده از داده‌های ذخیره‌شده در Query Store هر پایگاه داده جمع‌آوری می‌گردد و شاخص‌هایی مانند مصرف CPU، مدت اجرا، تعداد اجرا، پلن‌های جایگزین و رگرسیون کنار هم قرار می‌گیرند. اگر نتیجه با تجربه کاربران سازگار نبود، باید از ابزار مکمل در لایه سیستم‌عامل، موتور داده یا برنامه کاربردی کمک گرفت.

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

نحو و الگوی خواندن داده در Query Store Reports

همه قابلیت‌های Query Store Reports یک دستور واحد ندارند، اما Query زیر نقطه شروع عملی برای مشاهده بخشی از داده مرتبط است. آن را ابتدا در محیط آزمایش اجرا کنید و نام پایگاه، مجوزها و نسخه موتور را با شرایط واقعی تطبیق دهید.

-- نمونه 1 اختصاصی Query Store Reports
        SELECT TOP (10) q.query_id, qt.query_sql_text, SUM(rs.count_executions) AS executions, AVG(rs.avg_duration) AS avg_duration_us FROM sys.query_store_query_text AS qt JOIN sys.query_store_query AS q ON q.query_text_id=qt.query_text_id JOIN sys.query_store_plan AS p ON p.query_id=q.query_id JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id GROUP BY q.query_id,qt.query_sql_text ORDER BY avg_duration_us DESC;

ده مثال عملی و غیرتکراری برای Query Store Reports

مثال 1: ساخت خط مبنای اولیه با Query Store Reports

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

-- نمونه 1 اختصاصی Query Store Reports
        SELECT TOP (10) q.query_id, qt.query_sql_text, SUM(rs.count_executions) AS executions, AVG(rs.avg_duration) AS avg_duration_us FROM sys.query_store_query_text AS qt JOIN sys.query_store_query AS q ON q.query_text_id=qt.query_text_id JOIN sys.query_store_plan AS p ON p.query_id=q.query_id JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id GROUP BY q.query_id,qt.query_sql_text ORDER BY avg_duration_us DESC;

نکته فنی نمونه 1 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره شناسایی کوئری‌های پرمصرف در بازه زمانی تصمیم بگیرید.

مثال 2: تحلیل داده نمونه در محیط آزمایش با Query Store Reports

در این سناریوی اختصاصی، هدف آن است که تحلیل تاریخچه اجرای کوئری‌ها و مقایسه تغییرات پلن به شکلی قابل اندازه‌گیری بررسی شود. نمونه شماره 2 روی موضوع «مقایسه پلن‌های یک QueryID» تمرکز دارد و خروجی آن برای تصمیم‌گیری عملیاتی استفاده می‌شود.

-- نمونه 2 اختصاصی Query Store Reports
        SELECT q.query_id,p.plan_id,p.is_forced_plan,p.last_execution_time FROM sys.query_store_query AS q JOIN sys.query_store_plan AS p ON p.query_id=q.query_id WHERE q.query_id=(SELECT MIN(query_id) FROM sys.query_store_query);

نکته فنی نمونه 2 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره بررسی تغییر رفتار پس از به‌روزرسانی آمار تصمیم بگیرید.

مثال 3: استفاده در گزارش روزانه با Query Store Reports

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

-- نمونه 3 اختصاصی Query Store Reports
        SELECT TOP (20) p.query_id,COUNT(DISTINCT p.plan_id) AS plan_count FROM sys.query_store_plan AS p GROUP BY p.query_id HAVING COUNT(DISTINCT p.plan_id)>1 ORDER BY plan_count DESC;

نکته فنی نمونه 3 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره انتخاب پلن مناسب برای Force Plan تصمیم بگیرید.

مثال 4: اعمال فیلتر هدفمند با Query Store Reports

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

-- نمونه 4 اختصاصی Query Store Reports
        SELECT rsi.start_time,rsi.end_time,SUM(rs.count_executions) AS executions FROM sys.query_store_runtime_stats_interval AS rsi JOIN sys.query_store_runtime_stats AS rs ON rs.runtime_stats_interval_id=rsi.runtime_stats_interval_id GROUP BY rsi.start_time,rsi.end_time ORDER BY rsi.start_time DESC;

نکته فنی نمونه 4 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره کشف رگرسیون پس از انتشار نسخه جدید تصمیم بگیرید.

مثال 5: ترکیب با نمای سیستمی مکمل با Query Store Reports

در این سناریوی اختصاصی، هدف آن است که تحلیل تاریخچه اجرای کوئری‌ها و مقایسه تغییرات پلن به شکلی قابل اندازه‌گیری بررسی شود. نمونه شماره 5 روی موضوع «انتخاب پلن مناسب برای Force Plan» تمرکز دارد و خروجی آن برای تصمیم‌گیری عملیاتی استفاده می‌شود.

-- نمونه 5 اختصاصی Query Store Reports
        SELECT TOP (10) p.query_id,MAX(rs.avg_cpu_time) AS max_cpu_us FROM sys.query_store_plan AS p JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id GROUP BY p.query_id ORDER BY max_cpu_us DESC;

نکته فنی نمونه 5 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره مقایسه پلن‌های یک QueryID تصمیم بگیرید.

تصویر دوم، جریان اجرای Query Store Reports را از دریافت ورودی تا تولید مشاهده قابل مقایسه برای شناسایی کوئری‌های پرمصرف در بازه زمانی ترسیم می‌کند.

مثال 6: بررسی نبود داده یا مقدار NULL با Query Store Reports

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

-- نمونه 6 اختصاصی Query Store Reports
        SELECT actual_state_desc,desired_state_desc,current_storage_size_mb,max_storage_size_mb,readonly_reason FROM sys.database_query_store_options;

نکته فنی نمونه 6 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره شناسایی کوئری‌های پرمصرف در بازه زمانی تصمیم بگیرید.

مثال 7: آزمون وضعیت مرزی و بار غیرمعمول با Query Store Reports

در این سناریوی اختصاصی، هدف آن است که تحلیل تاریخچه اجرای کوئری‌ها و مقایسه تغییرات پلن به شکلی قابل اندازه‌گیری بررسی شود. نمونه شماره 7 روی موضوع «مقایسه پلن‌های یک QueryID» تمرکز دارد و خروجی آن برای تصمیم‌گیری عملیاتی استفاده می‌شود.

-- نمونه 7 اختصاصی Query Store Reports
        SELECT TOP (10) q.query_id,qt.query_sql_text FROM sys.query_store_query AS q JOIN sys.query_store_query_text AS qt ON qt.query_text_id=q.query_text_id WHERE qt.query_sql_text LIKE N'%SELECT%';

نکته فنی نمونه 7 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره بررسی تغییر رفتار پس از به‌روزرسانی آمار تصمیم بگیرید.

مثال 8: سناریوی عملیاتی سازمانی با Query Store Reports

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

-- نمونه 8 اختصاصی Query Store Reports
        SELECT TOP (10) p.query_id,p.plan_id,rs.avg_logical_io_reads,rs.avg_duration FROM sys.query_store_plan AS p JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id ORDER BY rs.avg_logical_io_reads DESC;

نکته فنی نمونه 8 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره انتخاب پلن مناسب برای Force Plan تصمیم بگیرید.

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

در این سناریوی اختصاصی، هدف آن است که تحلیل تاریخچه اجرای کوئری‌ها و مقایسه تغییرات پلن به شکلی قابل اندازه‌گیری بررسی شود. نمونه شماره 9 روی موضوع «بررسی تغییر رفتار پس از به‌روزرسانی آمار» تمرکز دارد و خروجی آن برای تصمیم‌گیری عملیاتی استفاده می‌شود. روش اشتباه، اجرای پایش بدون فیلتر و بدون تعیین مدت است؛ نسخه اصلاح‌شده Query را محدود می‌کند تا داده مرتبط با Query Store Reports استخراج شود.

-- نمونه 9 اختصاصی Query Store Reports
        EXEC sys.sp_query_store_flush_db; SELECT actual_state_desc,interval_length_minutes,stale_query_threshold_days FROM sys.database_query_store_options;

نکته فنی نمونه 9 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره کشف رگرسیون پس از انتشار نسخه جدید تصمیم بگیرید.

مثال 10: کنترل کارایی و هزینه پایش با Query Store Reports

در این سناریوی اختصاصی، هدف آن است که تحلیل تاریخچه اجرای کوئری‌ها و مقایسه تغییرات پلن به شکلی قابل اندازه‌گیری بررسی شود. نمونه شماره 10 روی موضوع «انتخاب پلن مناسب برای Force Plan» تمرکز دارد و خروجی آن برای تصمیم‌گیری عملیاتی استفاده می‌شود.

-- نمونه 10 اختصاصی Query Store Reports
        SELECT TOP (10) p.query_id,p.plan_id,p.is_forced_plan,p.force_failure_count,p.last_force_failure_reason_desc FROM sys.query_store_plan AS p ORDER BY p.force_failure_count DESC;

نکته فنی نمونه 10 در Query Store Reports آن است که نتیجه نباید جدا از بازه زمانی، بار جاری و پیکربندی سرور تفسیر شود. برای جلوگیری از نتیجه‌گیری شتاب‌زده، مقدار به‌دست‌آمده را با یک نمونه پیشین مقایسه کنید و سپس درباره مقایسه پلن‌های یک QueryID تصمیم بگیرید. در محیط پرترافیک، ابتدا هزینه خود ابزار را بسنجید؛ زیرا فعال نبودن Query Store یا پاک‌سازی زودهنگام داده‌ها باعث از بین رفتن خط مبنا می‌شود.

خطاهای رایج در کار با Query Store Reports

• در Query Store Reports، جمع‌آوری داده بدون سؤال مشخص خروجی حجیمی می‌سازد که هیچ تصمیمی را پشتیبانی نمی‌کند.
• نادیده گرفتن هشدار اصلی این ابزار: فعال نبودن Query Store یا پاک‌سازی زودهنگام داده‌ها باعث از بین رفتن خط مبنا می‌شود.
• در تحلیل Query Store Reports، مقایسه دو بازه با حجم Workload متفاوت نتیجه بهبود یا افت را مخدوش می‌کند.
• پس از مشاهده Query Store Reports، اعمال تغییر مستقیم در تولید بدون Baseline و معیار Rollback خطرناک است.
• تفسیر Query Store Reports با تمرکز روی یک عدد و حذف زمینه‌هایی مانند Wait، I/O، Lock و رفتار برنامه ناقص می‌ماند.

ملاحظات کارایی و بهترین روش‌ها در Query Store Reports

هزینه پایش باید بخشی از طراحی باشد. برای Query Store Reports دامنه داده را به رویداد، Database، Session یا بازه لازم محدود کنید. نرخ تولید داده را در پنج دقیقه نخست اندازه بگیرید؛ اگر رشد خروجی از انتظار بیشتر بود، فیلتر یا فاصله نمونه‌برداری را اصلاح کنید. نتیجه معتبر زمانی ایجاد می‌شود که خود ابزار باعث تغییر محسوس در رفتار Workload نشود.

بهترین روش، ایجاد دفترچه تصمیم است: پرسش اولیه، زمان جمع‌آوری، نسخه SQL Server، تغییرات اخیر، معیارهای مصرف CPU، مدت اجرا، تعداد اجرا، پلن‌های جایگزین و رگرسیون، تفسیر، اقدام و نتیجه پس از اقدام ثبت شوند. برای سناریوی بررسی تغییر رفتار پس از به‌روزرسانی آمار بهتر است داده قبل و بعد از تغییر با یک بار کاری مشابه مقایسه شود.

تصویر سوم، تصمیم فنی میان Baseline، مشاهده، هشدار Performance و Best Practice را برای Query Store Reports و سناریوی انتخاب پلن مناسب برای Force Plan خلاصه می‌کند.

سؤالات متداول اختصاصی Query Store Reports

پرسش 1: Query Store Reports دقیقاً چه مسئله‌ای را حل می‌کند؟

در زمینه Query Store Reports، این ابزار برای تحلیل تاریخچه اجرای کوئری‌ها و مقایسه تغییرات پلن طراحی شده است و داده را از داده‌های ذخیره‌شده در Query Store هر پایگاه داده می‌گیرد. ارزش اصلی آن زمانی آشکار می‌شود که نتیجه با خط مبنا و هدف کسب‌وکار مقایسه شود.

پرسش 2: برای شروع کار با Query Store Reports چه پیش‌نیازی لازم است؟

در زمینه Query Store Reports، دسترسی مشاهده DMVها یا مجوز مناسب ابزار، تعیین بازه پایش و شناخت بار عادی سامانه لازم است. پیش از اجرا نیز باید مشخص شود کدام‌یک از خروجی‌های «مصرف CPU، مدت اجرا، تعداد اجرا، پلن‌های جایگزین و رگرسیون» واقعاً اهمیت دارد.

پرسش 3: آیا Query Store Reports برای پروژه تجاری کوچک هم ارزش دارد؟

در زمینه Query Store Reports، بله، اما دامنه جمع‌آوری باید متناسب با اندازه سامانه باشد. در پروژه کوچک می‌توان از یک سناریوی محدود مانند کشف رگرسیون پس از انتشار نسخه جدید شروع کرد و تنها در صورت نیاز جزئیات بیشتری ثبت کرد.

پرسش 4: چگونه خروجی Query Store Reports به کاهش هزینه عملیاتی کمک می‌کند؟

در زمینه Query Store Reports، با شناسایی دقیق منبع مصرف یا رگرسیون، تیم از تغییرات حدسی دور می‌شود. این موضوع زمان عیب‌یابی، ریسک توقف سرویس و هزینه تهیه سخت‌افزار بدون ضرورت را کاهش می‌دهد.

پرسش 5: Query Store Reports با ابزارهای نزدیک چه تفاوتی دارد؟

در زمینه Query Store Reports، تمایز اصلی در منبع داده و عمق تحلیل است؛ این موضوع بر داده‌های ذخیره‌شده در Query Store هر پایگاه داده تکیه دارد، در حالی که ابزار دیگر ممکن است فقط نمای لحظه‌ای یا گزارش سطح سیستم‌عامل ارائه کند.

پرسش 6: برای پیاده‌سازی حرفه‌ای Query Store Reports چه خدماتی مفید است؟

در زمینه Query Store Reports، طراحی Baseline، انتخاب فیلتر، ساخت گزارش، تحلیل خروجی و مستندسازی اقدام اصلاحی از خدمات رایج مشاوره SQL Server هستند. این مراحل باید با نیاز واقعی پروژه هماهنگ شوند.

پرسش 7: رایج‌ترین خطا هنگام استفاده از Query Store Reports چیست؟

در زمینه Query Store Reports، رایج‌ترین خطا تفسیر یک نمونه منفرد بدون زمینه است. همچنین باید به این هشدار توجه شود که فعال نبودن Query Store یا پاک‌سازی زودهنگام داده‌ها باعث از بین رفتن خط مبنا می‌شود.

پرسش 8: اثر Performance خود Query Store Reports چگونه کنترل می‌شود؟

در زمینه Query Store Reports، رویدادها یا Counterها را محدود، مدت جمع‌آوری را مشخص و حجم خروجی را اندازه‌گیری کنید. سپس مصرف CPU، I/O و فضای ذخیره‌سازی ابزار را جدا از Workload اصلی ثبت کنید.

پرسش 9: بهترین روش عملی برای Query Store Reports چیست؟

در زمینه Query Store Reports، با یک پرسش مشخص مانند «مقایسه پلن‌های یک QueryID» شروع کنید، داده حداقلی لازم را جمع‌آوری کنید، نتیجه را با Baseline بسنجید و اقدام اصلاحی را همراه با معیار بازگشت ثبت کنید.

پرسش 10: سازگاری نسخه‌ای Query Store Reports را چگونه بررسی کنیم؟

در زمینه Query Store Reports، قابلیت‌ها و نام DMVها میان نسخه‌های SQL Server، Azure SQL و SSMS می‌توانند تفاوت داشته باشند. قبل از اجرای اسکریپت در تولید، آن را روی همان Edition و Compatibility Level آزمایش کنید.

سؤالات مصاحبه درباره Query Store Reports

1. توضیح دهید چرا Query Store Reports برای کشف رگرسیون پس از انتشار نسخه جدید مناسب است.
2. چگونه سربار Query Store Reports را در یک سرور پرترافیک اندازه‌گیری می‌کنید؟
3. بین خروجی‌های مصرف CPU، مدت اجرا، تعداد اجرا، پلن‌های جایگزین و رگرسیون کدام معیار را برای تشخیص اولیه انتخاب می‌کنید و چرا؟
4. اگر داده Query Store Reports با تجربه کاربر ناسازگار باشد، چه منابع مکملی را بررسی می‌کنید؟
5. یک برنامه بازگشت برای تغییری که بر اساس Query Store Reports پیشنهاد شده طراحی کنید.

چک‌لیست نهایی Query Store Reports

• در Query Store Reports پرسش پایش برای کشف رگرسیون پس از انتشار نسخه جدید نوشته شده است.
• برای Query Store Reports مجوز دسترسی به داده‌های ذخیره‌شده در Query Store هر پایگاه داده بررسی شده است.
• بازه زمانی و حجم خروجی Query Store Reports محدود شده است.
• برای Query Store Reports حداقل دو معیار از مصرف CPU، مدت اجرا، تعداد اجرا، پلن‌های جایگزین و رگرسیون ثبت شده است.
• تأثیر Query Store Reports بر CPU، I/O و فضای دیسک سنجیده شده است.
• اقدام اصلاحی مبتنی بر Query Store Reports و برنامه بازگشت مستند شده است.

جمع‌بندی آموزش Query Store Reports

Query Store Reports زمانی بیشترین ارزش را دارد که برای یک مسئله محدود مانند کشف رگرسیون پس از انتشار نسخه جدید به کار رود و خروجی آن با Baseline سنجیده شود. داده‌های مصرف CPU، مدت اجرا، تعداد اجرا، پلن‌های جایگزین و رگرسیون باید در کنار زمینه Workload تفسیر شوند. با رعایت فیلتر، زمان‌بندی و کنترل سربار می‌توان از این قابلیت برای تصمیم‌های قابل دفاع در SQL Server استفاده کرد.

برای مقایسه Query Store Reports با تمام گزینه‌های مجموعه، راهنمای جامع ابزارهای گرافیکی و خارجی عملکرد SQL Server را مطالعه کنید.