Quali sono i vantaggi dell'attivazione dell'archivio query su msdb?

Del database di sistema SQL (master, modello, msdb, tempdb) l'archivio query può essere utilizzato solo su msdb. Ho cercato e non ho trovato alcuna documentazione su Query Store su msdb.

Sebbene non sia possibile visualizzarlo nella GUI, può essere convalidato nell'istanza di SQL 2016

Convalida archivio query è disattivato

USE msdb
SELECT * FROM sys.database_query_store_options; 

Attiva Query Store

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

Convalida archivio query è attivo

USE msdb
SELECT * FROM sys.database_query_store_options; 

Di tutti i database di sistema perché msdb è l'unico con l'opzione di usare Query Store e quale valore aggiunge?

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

L'abilitazione di una funzione da parte di Microsoft non significa che sarà utile per tutti. Per i sistemi che utilizzano alcune delle funzionalità può significare fare affidamento sulle informazioni archiviate in MSDB. In questi casi, Query Store può essere utile.

Ecco alcuni articoli sull'utilizzo e l'ottimizzazione degli oggetti del database MSDB.

Database msdb dai libri online.

MSDB Performance Tuning di Geoff N. Hiten

L'importanza della manutenzione su MSDB di Tim Radney dove ha menzionato quanto segue:

L'ottimizzazione degli indici in msdb è importante tanto quanto i database degli utenti. Molte volte ho trovato client che stanno ottimizzando i database degli utenti ma non i database di sistema. Poiché il database msdb è molto utilizzato da SQL Server Agent, Log Shipping, Service Broker, SSIS, backup e ripristino e altri processi, gli indici possono essere molto frammentati. Assicurarsi che i lavori di ottimizzazione dell'indice includano anche i database di sistema o almeno msdb. Ho visto ottimizzazioni di indice liberare diversi gigabyte di spazio da indici altamente frammentati all'interno di msdb.

Vedo come l'archivio di query può aiutarti a ottimizzare la tua strategia di indicizzazione e a interrogare / aggravare / eliminare in modo ottimale alcune delle informazioni archiviate in MSDB.

@SqlWorldWide ha risposto alla parte "perché [msdb]" della domanda, quindi non la duplicherò qui. Ma per rispondere alla "Perché no [master], [model], [tempdb]" parte della domanda:

• [tempdb]è una memoria temporanea e per sua stessa natura non sembrerebbe mai beneficiare né dell'ottimizzazione automatizzata né della capacità di fornire analisi storiche. Se Query Store tiene traccia delle statistiche di esecuzione su Stored Procedures, ciò non sarà utile qui quando le Stored Procedure esistono altrove. E mentre è possibile creare Stored procedure temporanee, probabilmente le Stored Procs temporanee locali non trarrebbero beneficio da questo dato che il loro nome include un codice hash univoco per separare nomi simili in più sessioni. E mentre i Proc memorizzati temporanei globali hanno un nome coerente tra le sessioni, data la natura temporanea, non c'è modo di presumere che i Proc memorizzati temporanei globali con lo stesso nome tra sessioni (supponendo non allo stesso tempo) avranno anche lo stesso codice, e quindi non può avere significato /statistiche correlabili .

• [model]è il modello per la creazione di nuovi database (incluso [tempdb], che viene ricreato ogni volta che viene avviata / riavviata l'istanza di SQL Server). Le query non vengono eseguite da qui. Tuttavia, suppongo che potrebbe avere senso consentire l'archivio query da abilitare qui in modo che sia ATTIVATO per impostazione predefinita durante la creazione di nuovi DB. Ma, comunque , che tuttavia, ciò significherebbe Query negozio sarebbe essere abilitato [tempdb], e questo è solo stupido (vedi punto direttamente sopra).

  AGGIORNAMENTO:
  Woah, Nelly! Ho appena riletto la domanda iniziale che ha portato a questo e ho notato qualcosa di strano: c'erano solo messaggi di errore per [master]e [tempdb]; non è stato segnalato alcun errore [model]. È possibile che l'OP abbia semplicemente lasciato fuori quel messaggio di errore durante la copia nella domanda, quindi ho eseguito quanto segue su SQL Server 2016 SP1-CU7-GDR (13.0.4466.4) per vedere di persona:

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

  E i risultati? [model]e [IsQueryStoreEnabledByDefault]vengono restituiti, ma non[tempdb] è nei risultati! Quindi, un ulteriore tuttavia ai primi due "tuttavia" s, sembra che possa avere Query Conservare abilitato che a) inadempienze query di abilitazione memorizzate (sì, è una parola, ho anche verificato ;-) per DB appena creato e b) viene ignorato per la ricostruzione dell'inizio del servizio (quindi questa non è una backdoor per l'attivazione ).  [model] [tempdb][tempdb]

• [master]è il database di sistema principale e non dovresti avere il codice in esecuzione qui. Inoltre, le Stored procedure che esistono qui e che vengono frequentemente utilizzate o non trarrebbero beneficio dall'ottimizzazione, oppure eseguite nel contesto del Database utenti in cui vengono invocate (ovvero i processi memorizzati nel sistema che iniziano con sp_sono un caso speciale in cui "compaiono" in tutto DB - non è necessario essere pienamente qualificati con [master]..- ed eseguire come se esistessero effettivamente in ciascun DB) e sono probabilmente governati da Query Store nel Database Utente (i) in cui vengono invocati.