¿Qué beneficio hay de habilitar Query Store en msdb?

Del almacén de consultas de la base de datos del sistema SQL (maestro, modelo, msdb, tempdb) solo se puede usar en msdb. Miré y no encuentro ninguna documentación sobre el almacén de consultas en msdb.

Si bien no puede verlo en la GUI, se puede validar en su instancia de SQL 2016

Validar tienda de consultas está desactivado

USE msdb
SELECT * FROM sys.database_query_store_options; 

Activar el almacén de consultas

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

Validar consulta está activada

USE msdb
SELECT * FROM sys.database_query_store_options; 

De toda la base de datos del sistema, ¿por qué es msdb el único con la opción de usar Query Store, y qué valor agrega?

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

Microsoft habilitar una función no significa que será útil para todos. Para los sistemas que utilizan algunas de las funciones, puede depender de la información almacenada en MSDB. En esos casos, Query Store puede ser útil.

Aquí hay algunos artículos sobre el uso y ajuste de los objetos de la base de datos MSDB.

Base de datos msdb de libros en línea.

Ajuste de rendimiento de MSDB por Geoff N. Hiten

La importancia del mantenimiento en MSDB por Tim Radney donde mencionó lo siguiente:

Optimizar índices en msdb es tan importante como sus bases de datos de usuario. Muchas veces he encontrado clientes que están optimizando las bases de datos de los usuarios, pero no las bases de datos del sistema. Dado que la base de datos msdb es muy utilizada por el Agente SQL Server, Log Shipping, Service Broker, SSIS, copia de seguridad y restauración, y otros procesos, los índices pueden fragmentarse mucho. Asegúrese de que sus trabajos de optimización de índice también incluyan las bases de datos de su sistema, o al menos msdb. He visto que las optimizaciones de índice liberan varios gigabytes de espacio de índices altamente fragmentados dentro de msdb.

Puedo ver cómo el almacén de consultas puede ayudarlo a optimizar su estrategia de indexación y a consultar / agregar / purgar de manera óptima parte de la información almacenada en MSDB.

@SqlWorldWide respondió la parte "por qué [msdb]" de la pregunta, así que no la duplicaré aquí. Pero para responder a los "por qué no [master], [model], [tempdb]" parte de la pregunta:

• [tempdb]es un almacenamiento temporal y, por su propia naturaleza, parece que nunca se beneficiaría de la optimización automatizada o la capacidad de proporcionar análisis históricos. Si Query Store rastrea las estadísticas de ejecución de los procedimientos almacenados, eso no ayudará aquí cuando los procedimientos almacenados existan en otro lugar. Y si bien es posible crear procedimientos almacenados temporales, los procedimientos almacenados temporales locales probablemente no se beneficiarían de esto dado que su nombre incluye un código hash único para separar nombres similares en varias sesiones. Y si bien los procedimientos almacenados temporales globales tienen un nombre coherente en todas las sesiones, dada la naturaleza temporal, no hay forma de suponer que los procedimientos almacenados temporales globales del mismo nombre en todas las sesiones (supongamos que no al mismo tiempo) tendrán el mismo código, y por lo tanto no puede tener sentido /estadísticas correlacionables

• [model]es la plantilla para crear nuevas bases de datos (incluido [tempdb], que se vuelve a crear cada vez que se inicia / reinicia la instancia de SQL Server). Las consultas no se ejecutan desde aquí. Sin embargo, supongo que podría tener sentido permitir que el Almacén de consultas se habilite aquí para que esté ENCENDIDO de forma predeterminada al crear nuevas bases de datos. Pero, sin embargo, a que sin embargo, eso significaría Consulta tienda tendría que habilitar [tempdb], y eso es una tontería (véase el punto directamente encima).

  ACTUALIZACIÓN:
  Woah, Nelly! Acabo de releer la pregunta inicial que condujo a esta y noté algo extraño: solo había un mensaje de error para [master]y [tempdb]; no hubo ningún error reportado para [model]. Es posible que el OP simplemente omitiera ese mensaje de error al copiar en la pregunta, por lo que ejecuté lo siguiente en SQL Server 2016 SP1-CU7-GDR (13.0.4466.4) para verlo por mí mismo:

  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];
  

  ¿Y los resultados? [model]y [IsQueryStoreEnabledByDefault]son devueltos, pero no[tempdb] está en los resultados! Por lo tanto, un adicional de embargo a los dos primeros "sin embargo" s, parece que puede tener habilitada la consulta de tienda que: a) los valores predeterminados de consulta de habilitación almacenado (sí, es una palabra, incluso nos registramos ;-) para DBs de nueva creación, y b) se ignora para la recreación del inicio del servicio (por lo tanto, esto no es una puerta trasera para activarlo ).  [model] [tempdb][tempdb]

• [master]es la base de datos del sistema principal y no debería tener código ejecutándose aquí. Además, los procedimientos almacenados que existen aquí y se usan con frecuencia no se beneficiarían de la optimización o se ejecutarían en el contexto de la base de datos del usuario donde se invocan (es decir, los procesos almacenados del sistema que comienzan con sp_un caso especial donde "aparecen" en todos Las bases de datos (no es necesario que estén completamente calificadas [master]..) y se ejecutan como si realmente existieran en cada base de datos) y probablemente estén gobernadas por el Almacén de consultas en las bases de datos de usuario donde se invocan.