web-dev-qa-db-fra.com

Quel avantage existe-t-il de l'activation du magasin de requêtes sur MSDB?

De la base de données SQL System (Master, Model, MSDB, TEMPDB), la requête ne peut être utilisée que sur MSDB. J'ai regardé et ne trouvez 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.

Valider le magasin de requêtes est éteint

USE msdb
SELECT * FROM sys.database_query_store_options;

Transformez le magasin de requêtes sur

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 sur

USE msdb
SELECT * FROM sys.database_query_store_options;

De toute la base de données système Pourquoi MSDB est-il le seul avec l'option d'utiliser la requête de requête et quelle valeur ajoute-t-il?

-- Stop Query Store
USE [master]
GO
ALTER DATABASE msdb SET QUERY_STORE = OFF
GO
sql-serversql-server-2016msdbquery-store
9
James Jenkins

Microsoft Activation d'une fonctionnalité ne signifie pas que ce sera utile pour tout le monde. Pour les systèmes utilisant certaines des fonctionnalités, vous pouvez signifier s'appuyer sur des informations stockées dans MSDB. Dans ces cas, le magasin de requêtes peut être utile.

Voici quelques articles sur l'utilisation et la syntonisation des objets de base de données MSDB.

base de données MSDB des livres en ligne.

Tuning de performance MSDB par Geoff N. Hitten

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

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 fortement utilisée par SQL Server Agent, Log Shipping, Service Broker, SSIS, Sauvegarde et restauration, ainsi que 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 d'index très fragmentés au sein de MSDB.

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

7
SqlWorldWide

@Sqlworldwide a répondu à la "Pourquoi [msdb] "Une partie de la question donc je ne vais donc pas dupliquer cela ici. Mais pour répondre au" Pourquoi pas [master], [model], [tempdb] "Une partie de la question:

  • [tempdb] est un stockage temporaire et de par sa nature même ne semblerait jamais bénéficier d'une optimisation automatisée ni de la capacité de fournir une analyse historique. Si Query Store suit des statistiques d'exécution sur les procédures stockées, cela ne vous 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 PROC à stockage temporaire local ne bénéficieraient probablement pas de cela que leur nom comprend un code de hachage unique pour séparer des noms similaires dans plusieurs sessions. Et tandis que les PROC globaux de stockage temporaire mondial ont un nom cohérent entre les sessions, compte tenu de la nature temporaire, il n'existe aucun moyen de supposer que les PROC globaux de la même nom de même nom entre les sessions (supposeront pas en même temps) auront même le même code, et donc ne peut pas avoir significatif/ corrélable Statistiques.

  • [model] est le modèle de création de nouvelles bases de données (y compris [tempdb], qui est ré-créé chaque fois que l'instance SQL Server commence/redémarre). Les requêtes n'exécutent pas d'ici. Cependant, je suppose que cela Peut-être Consentement à autoriser la mise en place de la requête à émettre ici de manière à ce qu'il soit sur défaut lors de la création de nouveaux DBS. Mais, cependant, to ça Cependant, cela signifierait que la requête serait activée dans [tempdb], et c'est juste idiot (voir point directement au-dessus).

    Mise à jour:
    [.____] Woah, Nelly! Je viens de relire la question initiale qui mène à celui-ci et remarqua quelque chose d'étrange: il n'y avait que le message d'erreur pour [master] et [tempdb]; Il n'y avait aucune erreur signalée pour [model]. Il est possible que le O.P. a simplement laissé de côté 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 pour 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] is pas dans les résultats! Donc, un fichier supplémentaire Cependant aux deux premiers "Toutefois" S, il semble que [model] peut Demandez à Query Store activé dans lequel A) par défaut l'activation stockée de requête (Oui, c'est un mot, j'ai même vérifié ;-) Pour les DBS nouvellement créés, et B) est ignoré pour la ré- création de [tempdb] Sur le service commençant (il ne s'agit donc pas d'une porte arrière pour la transformer en [tempdb]).

  • [master] est la base de données du système principal et vous ne devez pas avoir de code ici. En outre, les procédures stockées qui existent ici et sont fréquemment utilisées, ne bénéficieraient pas de l'optimisation ou n'exécutent pas dans le contexte de la base de données de l'utilisateur où ils sont invoqués (c'est-à-dire des Procs stockés du système commençant par sp_ Sont un cas particulier où ils "apparaissent" dans tous les DBS - n'ont pas besoin d'être pleinement qualifiés avec [master].. - et exécuter comme si elles existent réellement dans chaque dB) et sont probablement régies par le magasin de requêtes dans la ou les bases de données d'utilisateurs où elles sont invoquées.

5
Solomon Rutzky