Quel avantage y a-t-il à activer Query Store sur msdb?

De la base de données du système SQL (maître, modèle, msdb, tempdb), le magasin de requêtes ne peut être utilisé que sur msdb. J'ai regardé et ne trouve aucune documentation sur le magasin de requêtes sur msdb.

Bien que vous ne puissiez pas le voir dans l'interface graphique, il peut être validé sur votre instance SQL 2016

La validation du magasin de requêtes est désactivée

USE msdb
SELECT * FROM sys.database_query_store_options; 

Activer le magasin de requêtes

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

Valider le magasin de requêtes est activé

USE msdb
SELECT * FROM sys.database_query_store_options; 

De toutes les bases de données système, pourquoi msdb est-il le seul à pouvoir utiliser le magasin de requêtes, et quelle valeur ajoute-t-il?

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

Microsoft activer une fonctionnalité ne signifie pas qu'elle sera utile à tout le monde. Pour les systèmes utilisant certaines des fonctionnalités, cela peut signifier se fier aux informations stockées dans MSDB. Dans ces cas, Query Store peut être utile.

Voici quelques articles sur l'utilisation et le réglage des objets de base de données MSDB.

Base de données msdb de livres en ligne.

Réglage des performances MSDB par Geoff N. Hiten

L'importance de la maintenance sur MSDB par Tim Radney où il a mentionné ce qui suit:

L'optimisation des index dans msdb est tout aussi importante que vos bases de données utilisateur. Plusieurs fois, j'ai trouvé des clients qui optimisent les bases de données utilisateur mais pas les bases de données système. Étant donné que la base de données msdb est largement utilisée par l'Agent SQL Server, l'envoi de journaux, Service Broker, SSIS, la sauvegarde et la restauration et d'autres processus, les index peuvent être très fragmentés. Assurez-vous que vos travaux d'optimisation d'index incluent également vos bases de données système, ou au moins msdb. J'ai vu des optimisations d'index libérer plusieurs gigaoctets d'espace à partir d'index hautement fragmentés dans msdb.

Je peux voir comment le magasin de requêtes peut vous aider à optimiser votre stratégie d'indexation et à interroger / agréger / purger de manière optimale certaines des informations stockées dans MSDB.

@SqlWorldWide a répondu à la partie "pourquoi [msdb]" de la question, donc je ne reproduis pas cela ici. Mais pour répondre à la « pourquoi pas [master], [model], [tempdb]» une partie de la question:

• [tempdb]est un stockage temporaire et, de par sa nature même, ne semble jamais bénéficier d'une optimisation automatisée ou de la possibilité de fournir une analyse historique. Si Query Store suit les statistiques d'exécution sur les procédures stockées, cela n'aidera pas ici lorsque les procédures stockées existent ailleurs. Et bien qu'il soit possible de créer des procédures stockées temporaires, les procs stockés temporaires locaux n'en bénéficieraient probablement pas étant donné que leur nom comprend un code de hachage unique pour séparer les noms similaires sur plusieurs sessions. Et bien que les processus stockés temporaires globaux aient un nom cohérent entre les sessions, étant donné la nature temporaire, il n'y a aucun moyen de supposer que les processus stockés temporaires globaux du même nom entre les sessions (supposons qu'ils ne sont pas en même temps) auront même le même code, et ne peut donc pas avoir de sens /statistiques corrélables .

• [model]est le modèle de création de nouvelles bases de données (y compris [tempdb], qui est recréé à chaque démarrage / redémarrage de l'instance SQL Server). Les requêtes ne s'exécutent pas à partir d'ici. Cependant, je suppose qu'il pourrait être judicieux d'autoriser Query Store à être activé ici afin qu'il soit activé par défaut lors de la création de nouvelles bases de données. Mais, cependant que cependant, cela signifierait la requête magasin serait activé [tempdb], et qui est tout simplement ridicule (voir point directement au- dessus).

  MISE À JOUR:
  Woah, Nelly! Je viens de relire la question initiale qui a conduit à celle-ci et j'ai remarqué quelque chose d'étrange: il n'y avait que des messages d'erreur pour [master]et [tempdb]; aucune erreur n'a été signalée pour [model]. Il est possible que l'OP ait simplement omis ce message d'erreur lors de la copie dans la question, j'ai donc exécuté ce qui suit sur SQL Server 2016 SP1-CU7-GDR (13.0.4466.4) pour voir par moi-même:

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

  Et les résultats? [model]et [IsQueryStoreEnabledByDefault]sont retournés, mais [tempdb]n'est pas dans les résultats! Ainsi, une somme supplémentaire cependant aux deux premiers « cependant » s, il semble que [model] peut avoir la requête magasin activé qui a) par défaut requête stockée Enablement (oui, il est un mot, j'ai même vérifié ;-) pour nouvellement créé BDs, et b) est ignoré pour la recréation de [tempdb]lors du démarrage du service (il ne s'agit donc pas d'une porte dérobée pour l'activer dans [tempdb]).  

• [master]est la base de données système principale et vous ne devriez pas avoir de code en cours d'exécution ici. De plus, les procédures stockées qui existent ici et qui sont fréquemment utilisées ne bénéficieraient pas de l'optimisation ou s'exécuteraient dans le contexte de la base de données des utilisateurs où elles sont invoquées (c'est-à-dire que les procs stockés par le système commençant par sp_sont un cas spécial où ils "apparaissent" dans tous Les bases de données - n'ont pas besoin d'être pleinement qualifiées avec [master]..- et s'exécutent comme si elles existent réellement dans chaque base de données) et sont probablement régies par le magasin de requêtes dans la ou les bases de données utilisateur où elles sont invoquées.