آموزش جامع sys.query_store_options در SQL Server؛ از ساختار تا تحلیل عملی
sys.query_store_options یکی از موضوعهای تخصصی خانواده Query Store است که برای تنظیمات و وضعیت عملیاتی Query Store بهکار میرود. این مقاله از تعریف و ستونها آغاز میکند، رابطه آن را با سایر نماها توضیح میدهد و سپس ده مثال مستقل، خروجی نمونه، خطاهای رایج و نکات کارایی را ارائه میدهد.
نسخه و سازگاری: نمای صحیح sys.database_query_store_options از SQL Server 2016 در دسترس است. همه Queryها باید در همان پایگاه دادهای اجرا شوند که Query Store آن مورد بررسی است. برای بازگشت به نقشه کامل این مجموعه، راهنمای جامع نماهای کاتالوگ Query Store را مطالعه کنید.
sys.query_store_options چیست و چه اطلاعاتی میدهد؟
نام رایج ولی نادرست sys.query_store_options را اصلاح میکند و روش استفاده از نمای واقعی sys.database_query_store_options را آموزش میدهد. در عمل، این نما بخشی از زنجیرهای است که از متن Query شروع میشود، به هویت منطقی و طرح اجرایی میرسد و در نهایت آمار اجرا، انتظارها یا تنظیمات مدیریتی را قابل مشاهده میکند.
کاربرد محوری این مقاله، تشخیص READ_ONLY شدن Query Store، پرشدن فضا و بررسی سیاست Capture و پاکسازی. است. نتیجه مطلوب فقط نمایش چند ردیف نیست؛ هدف این است که مدیر پایگاه داده بتواند از داده کاتالوگی به یک فرضیه قابل آزمون و سپس یک اقدام کمریسک برسد.
نکته مهم: در SQL Server نمایی با نام sys.query_store_options وجود ندارد؛ استفاده مستقیم از آن خطای Invalid object name ایجاد میکند.
ساختار، ستونهای کلیدی و ارتباطها
ستونهای مهم این نما عبارتاند از actual_state_desc، desired_state_desc، readonly_reason، current_storage_size_mb، max_storage_size_mb، query_capture_mode_desc، interval_length_minutes. همه ستونها در هر سناریو لازم نیستند؛ انتخاب باید بر اساس سؤال تحلیلی انجام شود.
- actual_state_desc: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
- desired_state_desc: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
- readonly_reason: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
- current_storage_size_mb: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
- max_storage_size_mb: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
- query_capture_mode_desc: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
رابطه اصلی با سایر نماها چنین است: یک ردیف وضعیت در سطح پایگاه داده برمیگرداند و بهطور معمول نیاز به Join ندارد. این رابطه باید با کلیدهای رسمی برقرار شود تا ضرب ردیف، شمارش تکراری یا نسبتدادن اشتباه آمار رخ ندهد.
| بخش | نقش در تحلیل | نکته اجرایی |
|---|
| هویت | actual_state_desc | برای فیلتر و Join از کلید مناسب استفاده شود |
| مقدار اصلی | desired_state_desc | فقط در صورت نیاز به لایه نمایش منتقل شود |
| ارتباط | یک ردیف وضعیت در سطح پایگاه داده برمیگرداند و بهطور معمول نیاز به Join ندارد. | Join صریح و قابل ممیزی نوشته شود |
| نسخه | نمای صحیح sys.database_query_store_options از SQL Server 2016 در دسترس است | پیش از اجرا سازگاری کنترل شود |
تصویر نخست، جایگاه sys.query_store_options، ستونهای محوری و مسیر ارتباط آن با تحلیل Query Store را نشان میدهد.
نحو پایه و پیشنیازهای دسترسی
این موضوع یک Catalog View است و مانند جدول با SELECT خوانده میشود. نام قابل استفاده در Queryهای این مقاله «sys.database_query_store_options» است.
SELECT TOP (20)
actual_state_desc,
desired_state_desc
FROM sys.database_query_store_options
ORDER BY actual_state_desc DESC;
برای مشاهده دادههای Query Store معمولاً مجوزهای مشاهده وضعیت یا عملکرد پایگاه داده لازم است. سطح مجوز دقیق به نسخه SQL Server وابسته است؛ بنابراین اسکریپت تولیدی بهتر است با حساب کماختیار آزمایش و سپس حداقل مجوز لازم مستند شود.
ده مثال عملی و مستقل
مثال 1: نمایش نمونه ردیفها
در نخستین گام، ساختار واقعی sys.database_query_store_options را با تعداد محدودی ردیف مشاهده میکنیم تا نام ستونها و شکل داده روشن شود.
SELECT TOP (10) *
FROM sys.database_query_store_options
ORDER BY 1 DESC;
| خروجی نمونه | توضیح |
|---|
| ردیفهای بازگشتی | حداکثر ۱۰ |
| هدف | شناخت ساختار نما |
نکته کاربردی: در محیط عملی بهتر است بهجای ستاره فقط ستونهای لازم انتخاب شوند؛ این مثال عمداً برای شناسایی سریع ساختار نوشته شده است.
مثال 2: انتخاب ستونهای کلیدی actual_state_desc و desired_state_desc
این نمونه فقط دو ستون محوری actual_state_desc و desired_state_desc را میخواند تا نتیجه کوچک، قابل بررسی و مناسب ابزارهای مانیتورینگ باشد.
SELECT TOP (20)
actual_state_desc,
desired_state_desc
FROM sys.database_query_store_options
ORDER BY actual_state_desc DESC;
| خروجی نمونه | توضیح |
|---|
| actual_state_desc | شناسه یا مقدار کلیدی |
| desired_state_desc | ویژگی اصلی تحلیل |
نکته کاربردی: انتخاب ستون صریح هم خوانایی را بیشتر میکند و هم مانع انتقال دادههای سنگین یا غیرضروری میشود.
مثال 3: استفاده از فیلتر هدفمند
برای جلوگیری از اسکن بیدلیل، تحلیل را به مقدار مشخصی از actual_state_desc محدود میکنیم. مقدار نمونه را باید با مقدار موجود در پایگاه داده جایگزین کرد.
DECLARE @TargetState nvarchar(60) = N'READ_WRITE';
SELECT *
FROM sys.database_query_store_options
WHERE actual_state_desc = @TargetState;
| خروجی نمونه | توضیح |
|---|
| شرط | actual_state_desc = READ_WRITE |
| نتیجه | وضعیت عملیاتی در صورت تطبیق |
نکته کاربردی: در گزارش وضعیت، مقدار متنی state از تنظیمات جاری پایگاه داده خوانده میشود و نباید با شناسه عددی مقایسه شود.
تصویر دوم، جریان انتخاب داده، فیلتر، اتصال و تبدیل خروجی sys.query_store_options به گزارش فنی را نمایش میدهد.
مثال 4: اتصال به نمای مکمل
ارزش sys.database_query_store_options زمانی بیشتر میشود که کلیدهای آن با نمای مکمل Query Store متصل شوند. این Query رابطه اصلی مقاله را بهصورت عملی نشان میدهد.
SELECT
actual_state_desc,
desired_state_desc,
readonly_reason,
current_storage_size_mb,
max_storage_size_mb
FROM sys.database_query_store_options;
| خروجی نمونه | توضیح |
|---|
| نوع تحلیل | Join کاتالوگی |
| رابطه | یک ردیف وضعیت در سطح پایگاه داده برمیگرداند و بهطور معمول نیاز به Join ندارد. |
نکته کاربردی: Join باید روی کلید مستندشده انجام شود؛ اتصال بر اساس متن، زمان تقریبی یا ستونهای غیرکلیدی میتواند ردیفهای تکراری و نتیجه گمراهکننده بسازد.
مثال 5: مدیریت نتیجه خالی و NULL
برخی ستونها ممکن است NULL باشند یا نمای هدف هیچ ردیفی نداشته باشد. با COALESCE میتوان خروجی نمایشی کنترلشدهای برای گزارش ساخت.
SELECT TOP (20)
actual_state_desc,
COALESCE(CONVERT(nvarchar(4000), desired_state_desc), N'بدون مقدار') AS safe_value
FROM sys.database_query_store_options
ORDER BY actual_state_desc DESC;
| خروجی نمونه | توضیح |
|---|
| actual_state_desc | نمونه شناسه |
| safe_value | مقدار واقعی یا «بدون مقدار» |
نکته کاربردی: COALESCE برای نمایش مناسب است؛ اما نباید نوع داده و معنای NULL را در منطق تحلیلی پنهان کند.
مثال 6: کنترل سازگاری نسخه پیش از اجرا
از آنجا که دسترسپذیری sys.database_query_store_options به نسخه SQL Server وابسته است، Query زیر پیش از خواندن نما وجود آن را بررسی میکند.
IF OBJECT_ID(N'sys.database_query_store_options', N'V') IS NULL
BEGIN
SELECT N'این نما در نسخه یا پیکربندی فعلی در دسترس نیست.' AS message;
END
ELSE
BEGIN
SELECT TOP (5) *
FROM sys.database_query_store_options;
END;
| خروجی نمونه | توضیح |
|---|
| حالت اول | نما موجود است و نمونه داده خوانده میشود |
| حالت دوم | پیام سازگاری بازگردانده میشود |
نکته کاربردی: این الگو برای اسکریپتهایی که روی چند نسخه اجرا میشوند ضروری است و از توقف کامل عملیات مانیتورینگ جلوگیری میکند.
مثال 7: سناریوی واقعی عیبیابی
تشخیص READ_ONLY شدن Query Store، پرشدن فضا و بررسی سیاست Capture و پاکسازی.
SELECT
actual_state_desc,
readonly_reason,
current_storage_size_mb,
max_storage_size_mb,
CAST(100.0 * current_storage_size_mb /
NULLIF(max_storage_size_mb, 0) AS decimal(6,2)) AS used_percent
FROM sys.database_query_store_options;
| خروجی نمونه | توضیح |
|---|
| سناریو | تشخیص READ_ONLY شدن Query Store، پرشدن فضا و بررسی سیاست Capture و پاکسازی. |
| خروجی | فهرست اولویتدار برای اقدام |
نکته کاربردی: این خروجی نقطه شروع بررسی است؛ تصمیم نهایی باید با متن Query، طرح، آمار اجرا و شرایط محیط تولید تطبیق داده شود.
تصویر سوم، تفاوت خواندن گسترده با روش فیلترشده و قابل اتکا برای sys.query_store_options را مقایسه میکند.
مثال 8: روش اشتباه و نسخه اصلاحشده
خواندن بدون محدودیت تمام ستونها از sys.database_query_store_options در یک Job پرتکرار میتواند هزینه غیرضروری بسازد. نسخه اصلاحشده فقط ستون و ردیف لازم را دریافت میکند.
-- روش نامناسب برای اجرای پرتکرار
SELECT *
FROM sys.database_query_store_options;
-- نسخه کنترلشده
SELECT TOP (100)
actual_state_desc,
desired_state_desc
FROM sys.database_query_store_options
WHERE actual_state_desc IS NOT NULL
ORDER BY actual_state_desc DESC;
| خروجی نمونه | توضیح |
|---|
| روش نامناسب | حجم خروجی نامحدود |
| روش اصلاحشده | ستون و تعداد ردیف کنترلشده |
نکته کاربردی: در SQL Server نمایی با نام sys.query_store_options وجود ندارد؛ استفاده مستقیم از آن خطای Invalid object name ایجاد میکند.
مثال 9: الگوی مناسب برای داشبورد کارایی
برای داشبورد، ابتدا آخرین یا مهمترین ردیفها از sys.database_query_store_options انتخاب میشوند و تنها خروجی جمعوجور به لایه نمایش منتقل میشود.
DECLARE @RowLimit int = 50;
SELECT TOP (@RowLimit)
actual_state_desc,
desired_state_desc
FROM sys.database_query_store_options
WHERE actual_state_desc IS NOT NULL
ORDER BY actual_state_desc DESC
OPTION (RECOMPILE);
| خروجی نمونه | توضیح |
|---|
| حد ردیف | ۵۰ |
| هدف | پاسخ سریع و قابل پیشبینی |
نکته کاربردی: برای مانیتورینگ سبک فقط ستونهای لازم از sys.database_query_store_options را بخوانید و readonly_reason را بیتمحور تفسیر کنید.
مثال 10: اعتبارسنجی خروجی برای اتوماسیون
آخرین مثال تعداد ردیفهای قابل استفاده را در یک متغیر میریزد تا Job یا ابزار مانیتورینگ بتواند وضعیت sys.database_query_store_options را بهصورت صریح گزارش کند.
DECLARE @AvailableRows bigint;
SELECT @AvailableRows = COUNT_BIG(*)
FROM sys.database_query_store_options;
SELECT
@AvailableRows AS available_rows,
CASE
WHEN @AvailableRows = 0 THEN N'دادهای ثبت نشده است'
ELSE N'داده برای تحلیل موجود است'
END AS status_message;
| خروجی نمونه | توضیح |
|---|
| available_rows | تعداد ردیف |
| status_message | پیام قابل استفاده در مانیتورینگ |
نکته کاربردی: در سامانه هشدار بهتر است وضعیت Query Store، زمان آخرین Capture و علت خالی بودن احتمالی نیز همراه این عدد ذخیره شود.
خطاهای رایج
- فرض اینکه هر ردیف sys.query_store_options بهتنهایی تصویر کامل عملکرد را نشان میدهد؛ در حالی که Join با لایههای مرتبط لازم است.
- در SQL Server نمایی با نام sys.query_store_options وجود ندارد؛ استفاده مستقیم از آن خطای Invalid object name ایجاد میکند.
- جمعکردن میانگینها بدون توجه به وزن تعداد اجرا یا بازه زمانی.
- اجرای Query بدون فیلتر روی پایگاه داده پرترافیک و انتقال خروجی حجیم به ابزار گزارشگیری.
- نادیدهگرفتن تفاوت نسخهها و استفاده از ستون یا نمایی که در مقصد وجود ندارد.
ملاحظات کارایی و بهترین روشها
برای مانیتورینگ سبک فقط ستونهای لازم از sys.database_query_store_options را بخوانید و readonly_reason را بیتمحور تفسیر کنید.
- سؤال تحلیلی را قبل از نوشتن Query مشخص کنید؛ گزارش بدون سؤال فقط حجم داده تولید میکند.
- ابتدا شناسهها و بازههای لازم را محدود کنید و ستونهای سنگین را در مرحله آخر بخوانید.
- برای روندهای تاریخی، Snapshot کنترلشده با زمان نمونهبرداری بسازید و از کپی کامل داده خام بپرهیزید.
- Query تحلیلی را روی محیط مشابه تولید آزمایش کنید و هزینه IO، CPU و زمان را ثبت کنید.
- هر Hint، Plan Forcing یا تغییر تنظیمات را با خط مبنا، مسئول تغییر و برنامه بازگشت مستند کنید.
کاربرد در یک پروژه واقعی
فرض کنید سامانه فروش در ساعات اوج کند میشود. تیم پشتیبانی ابتدا query_id یا plan_idهای پرهزینه را پیدا میکند، سپس از sys.query_store_options برای تشخیص READ_ONLY شدن Query Store، پرشدن فضا و بررسی سیاست Capture و پاکسازی. استفاده میکند. خروجی با متن Query، Plan، آمار Runtime و Waitها تطبیق داده میشود تا مشخص شود مشکل از تغییر طرح، افزایش حجم، قفل، IO، حافظه یا تنظیم مدیریتی است.
در مرحله بعد یک گزارش دورهای ساخته میشود که فقط انحرافهای معنادار را نگهداری میکند. این رویکرد از انباشتهشدن داده بیمصرف جلوگیری میکند و زمان واکنش تیم را کاهش میدهد. معیار موفقیت نیز باید قابل اندازهگیری باشد؛ برای نمونه کاهش صدک ۹۵ مدت اجرا، افت CPU یا حذف بازگشت مکرر به طرح نامطلوب.
سؤالات متداول
sys.database_query_store_options دقیقاً چه مسئلهای را حل میکند؟
این نما نام رایج ولی نادرست sys.query_store_options را اصلاح میکند و روش استفاده از نمای واقعی sys.database_query_store_options را آموزش میدهد. و برای تبدیل دادههای داخلی Query Store به گزارش قابل تحلیل استفاده میشود.
برای شروع کار با sys.database_query_store_options کدام ستونها مهمترند؟
ستونهای actual_state_desc، desired_state_desc، readonly_reason، current_storage_size_mb نقطه شروع مناسبی هستند؛ سپس بر اساس سناریو ستونهای تکمیلی افزوده میشوند.
آیا استفاده از sys.database_query_store_options برای گزارش مدیریتی مناسب است؟
بله، به شرط آنکه داده فنی خام به شاخصهایی مانند روند، رتبه، تغییر نسبت به بازه قبل و اقدام پیشنهادی تبدیل شود.
چطور میتوان از داده sys.database_query_store_options در پروژه سازمانی استفاده کرد؟
میتوان یک Job جمعآوری، جدول Snapshot و داشبورد ساخت تا سناریوی «تشخیص READ_ONLY شدن Query Store، پرشدن فضا و بررسی سیاست Capture و پاکسازی.» بهصورت دورهای پایش شود.
sys.database_query_store_options با نماهای دیگر Query Store چه تفاوتی دارد؟
تمرکز این نما روی «تنظیمات و وضعیت عملیاتی Query Store» است؛ در حالی که نماهای متن، query، plan، runtime و wait هر کدام لایه متفاوتی از زنجیره تحلیل را ارائه میکنند.
برای پیادهسازی گزارش حرفهای sys.database_query_store_options چه خدمتی لازم است؟
طراحی Query، مدل نگهداری Snapshot، کنترل دسترسی، ساخت داشبورد و تعریف آستانه هشدار معمولاً به تحلیل و پیادهسازی تخصصی SQL Server نیاز دارد.
رایجترین خطا در کار با sys.database_query_store_options چیست؟
در SQL Server نمایی با نام sys.query_store_options وجود ندارد؛ استفاده مستقیم از آن خطای Invalid object name ایجاد میکند.
مهمترین نکته Performance برای sys.database_query_store_options چیست؟
برای مانیتورینگ سبک فقط ستونهای لازم از sys.database_query_store_options را بخوانید و readonly_reason را بیتمحور تفسیر کنید.
بهترین روش نگهداری گزارشهای مبتنی بر sys.database_query_store_options چیست؟
خروجی خام را بیهدف کپی نکنید؛ فقط شاخصهای موردنیاز را با زمان نمونهبرداری، شناسه پایگاه داده و نسخه موتور در جدول تاریخچه ذخیره کنید.
sys.database_query_store_options در چه نسخههایی در دسترس است؟
نمای صحیح sys.database_query_store_options از SQL Server 2016 در دسترس است. پیش از استقرار اسکریپت روی چند سرور، وجود نما و ستونهای مورد استفاده را کنترل کنید.
سؤالات مصاحبه SQL Server
- توضیح دهید sys.query_store_options چه دادهای میدهد و در چه مرحلهای از تحلیل Query Store استفاده میشود.
- کلید اصلی اتصال sys.query_store_options به نمای مکمل چیست و Join اشتباه چه اثری دارد؟
- چگونه یک Query پرهزینه روی sys.query_store_options را به نسخه سبکتر تبدیل میکنید؟
- برای کنترل سازگاری نسخه sys.query_store_options چه الگویی پیشنهاد میدهید؟
- چگونه نتیجه حاصل از sys.query_store_options را با آمار Runtime یا Waitها اعتبارسنجی میکنید؟
چکلیست نهایی
- فعال بودن Query Store و وجود داده کنترل شده است.
- وجود نمای sys.database_query_store_options و ستونهای مورد استفاده بررسی شده است.
- فیلتر شناسه و بازه زمانی قبل از Joinهای سنگین اعمال شده است.
- خروجی نمونه با متن Query، Plan یا شاخص مکمل تطبیق داده شده است.
- نتیجه، فرضیه و اقدام پیشنهادی بهصورت قابل ممیزی ثبت شده است.
جمعبندی
sys.query_store_options برای تنظیمات و وضعیت عملیاتی Query Store یک ابزار تخصصی و ارزشمند است. استفاده درست از آن نیازمند شناخت ستونها، اتصال دقیق به سایر نماها، رعایت تفاوت نسخهها و تفسیر داده در بستر زمان و بار کاری است. ده مثال این مقاله مسیر را از خواندن پایه تا گزارش عملیاتی و کنترل Performance پوشش داد.
برای مشاهده جایگاه این نما در کل معماری، به مقاله مادر نماهای کاتالوگ Query Store بازگردید.
خدمات برنامهنویسی و پایگاه داده
برنامهنویسی در اصفهان؛ قبول سفارشهای برنامهنویسی و پایگاه داده با شماره 09131253620.
انجام پروژه و آموزش تخصصی
انجام پروژههای برنامهنویسی، آموزش برنامهنویسی و آموزش پایگاه داده SQL Server برای اشخاص، شرکتها و مجموعههای آموزشی انجام میشود.
مجموعهای معتبر با سابقه فعالیت حرفهای از سال ۱۳۷۵ شمسی
از سال ۱۳۷۵ شمسی تاکنون در زمینه طراحی و اجرای پروژههای برنامهنویسی، پایگاه داده، سیستمهای تحت وب، وبسایت و راهکارهای نرمافزاری فعالیت میکنیم.
برای سفارش پروژههای برنامهنویسی و پایگاه داده، سیستمهای تحت وب، وبسایت و راهکارهای نرمافزاری جدید، با شماره تلفن همراه 09131253620 تماس حاصل فرمایید.
ایتا، واتساپ و تماس مستقیم: +989131253620
تماس با ما