Яка користь від включення Query Store у msdb?

З системної бази даних SQL (майстер, модель, msdb, tempdb) сховище запитів може використовуватися лише у msdb. Я переглянув і не знайшов жодної документації про магазин запитів на msdb.

Хоча ви не бачите його в графічному інтерфейсі, він може бути перевірений у вашому екземплярі SQL 2016

Підтверджений магазин запитів вимкнено

USE msdb
SELECT * FROM sys.database_query_store_options; 

Увімкніть магазин запитів

USE [master]
GO
ALTER DATABASE msdb SET QUERY_STORE = ON
GO
ALTER DATABASE msdb SET QUERY_STORE (OPERATION_MODE = READ_WRITE
, INTERVAL_LENGTH_MINUTES = 30
, MAX_STORAGE_SIZE_MB = 1000
, QUERY_CAPTURE_MODE = AUTO)
GO

Увімкнено магазин підтвердження запитів

USE msdb
SELECT * FROM sys.database_query_store_options; 

З усіх системних баз даних, чому msdb є єдиним із можливістю використовувати магазин запитів, і яке значення він додає?

-- Stop Query Store
USE [master]
GO
ALTER DATABASE msdb SET QUERY_STORE = OFF
GO

Увімкнення функції Microsoft не означає, що вона буде корисною для всіх. Для систем, що використовують деякі функції, може означати покладання на інформацію, що зберігається в MSDB. У цих випадках магазин запитів може бути корисним.

Ось кілька статей про використання та налаштування об’єктів бази даних MSDB.

MSDB База даних з книг в Інтернеті.

Налаштування продуктивності MSDB від Джеффа Н. Хітена

Важливість обслуговування на MSDB Тім Радні, де він згадував наступне:

Оптимізація індексів у msdb так само важлива, як і ваші користувацькі бази даних. Я багато разів знаходив клієнтів, які оптимізують користувацькі бази даних, але не системні бази даних. Оскільки база даних MSDB активно використовується агентом SQL Server, доставкою журналів, службовим посередником, SSIS, резервним копіюванням та відновленням та іншими процесами, індекси можуть отримати дуже фрагментарний характер. Переконайтеся, що ваші завдання з оптимізації індексу також містять ваші системні бази даних або принаймні msdb. Я бачив, що оптимізація індексів звільняє кілька гігабайт простору від сильно фрагментованих індексів в msdb.

Я бачу, як магазин запитів може допомогти в оптимізації вашої стратегії індексації та оптимальному запиті / агрегації / очищенні частини інформації, що зберігається в MSDB.

@SqlWorldWide відповів на питання "чому [msdb]", тому я не буду дублювати це тут. Але , щоб відповісти на «чому немає [master], [model], [tempdb]» частина питання:

• [tempdb]це тимчасове зберігання і, за своєю суттю, здавалося б, ніколи не виграє ні автоматизованої оптимізації, ні можливості надання історичного аналізу. Якщо Query Store відстежує статистику виконання на Збережених процедурах, це не допоможе тут, коли збережені процедури існують в іншому місці. І хоча можливо створити тимчасові збережені процедури, локальні тимчасові збережені програми, ймовірно, не отримають користі від цього, враховуючи те, що їх ім'я включає унікальний хеш-код для розділення подібних імен на кілька сеансів. І хоча глобальні тимчасові збережені програми мають послідовну назву протягом сеансів, враховуючи тимчасовий характер, не можна припустити, що глобальні тимчасові збережені програми з тим самим іменем протягом сеансів (припустимо, не одночасно) матимуть навіть той самий код, а значить, не може мати змістовного /корельована статистика.

• [model]- це шаблон для створення нових баз даних (у тому числі [tempdb], який заново створюється кожного разу при запуску / перезапуску екземпляра SQL Server). Звідси запити не виконуються. Однак, я думаю, може бути доцільним дозволити тут увімкнути магазин запитів, щоб воно було за замовчуванням увімкнено під час створення нових БД. Але, однак, до цього, однак, це означає, що магазин запитів буде включений [tempdb], і це просто нерозумно (див. Пункт прямо вище).

  ОНОВЛЕННЯ:
  Вау, Неллі! Я просто перечитав початкове запитання, яке веде до цього, і помітив щось дивне: було лише повідомлення про помилку для [master]та [tempdb]; не було повідомлено про помилки [model]. Можливо, що ОП просто залишив це повідомлення про помилку під час копіювання у запитання, тому я запустив наступне на SQL Server 2016 SP1-CU7-GDR (13.0.4466.4), щоб переконатися в собі:

  ALTER DATABASE [model] SET QUERY_STORE = ON; -- completes successfully!
  
  -- Restart instance to force recreation of [tempdb];
  
  CREATE DATABASE [IsQueryStoreEnabledByDefault];
  
  SELECT * FROM sys.databases WHERE [is_query_store_on] = 1;
  
  DROP DATABASE [IsQueryStoreEnabledByDefault];

  А результати? [model]і [IsQueryStoreEnabledByDefault]повертаються, але [tempdb]це не в результатах! Таким чином, додатковий , проте в перших двох «проте» s, здається , що [model] може бути включений запит магазин , який а) по замовчуванням Query Stored МОЖЛИВОСТЕЙ (так, це слово, я навіть перевірив ;-) для новоствореної БД, і б) ігнорується для відновлення [tempdb]після запуску послуги (отже, це не зворотна дверцята для її включення [tempdb]).  

• [master]є основною системною базою даних, і тут у вас не повинно працювати код. Також збережені процедури, які існують тут і часто використовуються, не принесуть користі від оптимізації, або виконуються в контексті Бази даних користувачів, де вони викликаються (тобто системні збережені програми, починаючи з sp_- це особливий випадок, коли вони "з'являються" у всіх БД - не потрібно їх повністю кваліфікувати [master]..- і виконувати так, ніби вони насправді існують у кожній БД) і, ймовірно, керуються магазином запитів у базах даних користувачів, де вони викликаються.