Correzione automatica del piano in SQL Server

Quanto tempo dedichi alla risoluzione dei problemi di prestazioni come amministratore di database o sviluppatore? L'hai mai rintracciato? Come percentuale totale media della tua giornata, potrebbe non sembrare molto tempo, ma quando il problema è serio, puoi passare ore a rintracciarlo e lavorare attraverso l'analisi della causa principale. A volte il problema scompare e non si conosce la vera origine. E anche peggio? Quando devi combattere questi problemi nel cuore della notte o nel fine settimana. Non solo stai lottando per risolvere un problema, ma stai perdendo il tuo tempo libero personale. Come alleviarlo? In che modo togliamo tempo e fatica dall'equazione e allo stesso tempo aggiustiamo le prestazioni?

La funzionalità di ottimizzazione automatica in SQL Server 2017 Enterprise Edition e nel database SQL di Azure è il primo passaggio per ridurre il tempo dedicato ai professionisti dei dati per la risoluzione dei problemi e delle prestazioni. La funzionalità include la correzione automatica del piano e la gestione automatica dell'indice (disponibile solo nel database SQL di Azure), che sono abilitate in modo indipendente. In questo post voglio concentrarmi sulla funzione di correzione automatica del piano. Con la correzione automatica del piano, se SQL Server rileva che una query è regredita in modo significativo, forzerà l'ultimo piano valido noto affinché la query stabilizzi le prestazioni. In sostanza, piuttosto che tu, il DBA o lo sviluppatore, che vieni chiamato nel fine settimana per le prestazioni del sistema, SQL Server lo affronterà per te. Sembra troppo facile, vero? Diamo un'occhiata.

Sotto le coperte

Innanzitutto, è essenziale comprendere che la correzione automatica del piano utilizza Query Store, quindi deve essere abilitata per il database. In secondo luogo, la correzione automatica del piano è semplicemente una forzatura automatica del piano. Sebbene Query Store sia commercializzato come registratore di volo per il tuo database che tiene traccia del testo della query, dei piani, delle statistiche di runtime e delle statistiche di attesa, ti consente anche di forzare un piano per una query per consentire prestazioni coerenti. La correzione automatica del piano è la forzatura del piano senza il tuo intervento.

Abilitazione della correzione automatica del piano

Come accennato, Query Store deve essere prima abilitato per il database utente. Questa operazione può essere eseguita in SSMS, con T-SQL e con l'API REST per Azure SQL DB. Tieni presente che Query Store è abilitato per impostazione predefinita per i database in Azure e lo è dal 4° trimestre 2016.

Abilitazione di Query Store tramite SSMS

USE [master];
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE = ON;
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

Abilitazione di Query Store tramite T-SQL

Il codice sopra è il T-SQL predefinito da SSMS se lo si scrive. Nel database SQL di Azure non si esegue l'istruzione USE. Se desideri modificare una delle opzioni predefinite, leggi il mio post sulle impostazioni di Query Store su quali sono queste opzioni e considerazioni sui valori alternativi.

Una volta abilitato Query Store, puoi usare il portale di Azure, l'API T-SQL o EST per abilitare la correzione automatica del piano nel database SQL di Azure ((e C# e PowerShell sono in lavorazione). Può essere abilitato solo con T-SQL in SQL Server 2017.

Abilitazione della correzione automatica del piano nel portale di Azure

ALTER DATABASE [WideWorldImporters] 
	SET AUTOMATIC_TUNING (
		FORCE_LAST_GOOD_PLAN = ON
	);
GO

Abilitazione della correzione automatica del piano in T-SQL

Si noti che la correzione automatica del piano sarà abilitata per impostazione predefinita per i nuovi database in Azure nel prossimo futuro. A partire da gennaio 2018, l'ottimizzazione automatica viene abilitata per i database SQL di Azure che non lo avevano già abilitato, con notifiche inviate agli amministratori in modo che l'opzione possa essere disabilitata se lo si desidera.

Come funziona

Con la correzione automatica del piano abilitata, SQL Server monitora le prestazioni delle query utilizzando i dati dell'archivio query. Cerca un cambiamento significativo* nelle prestazioni della CPU** con una finestra di 48 ore***. Nota gli asterischi in quella frase... quelli sono apposta:

*La soglia per ciò che costituisce una modifica significativa non è documentata perché Microsoft si riserva il diritto di modificarla.
**La metrica utilizzata per determinare la modifica delle prestazioni (CPU) non è documentata perché Microsoft si riserva il diritto di modificarla. Ciò significa che Microsoft potrebbe prendere in considerazione dimensioni aggiuntive per esaminare le prestazioni se ciò fosse migliore/prestazioni migliori della sola CPU.
***Il periodo di tempo durante il quale vengono confrontati i dati sulle prestazioni della query non è documentato per lo stesso motivo, Microsoft si riserva il diritto di modificarlo.
Nota:sebbene gli elementi di cui sopra non siano documentati, ho confermato con le persone appropriate di Microsoft che queste informazioni potrebbero essere condivise con la violazione di qualsiasi NDA. È estremamente importante capire che i valori non sono fissi e possono cambiare, con l'aspettativa che cambino per migliorare l'affidabilità della funzione.

La mancanza di documentazione e la possibilità di modifiche alla soglia può essere frustrante per alcune persone, ma ecco cosa è veramente importante ricordare:

Microsoft acquisisce quotidianamente terabyte di dati di telemetria operativa dai database di SQL Azure e tali dati sono fondamentali per le funzionalità automatiche in fase di sviluppo. Questi dati includono elementi come query_id, query_plan_id e query_hash e Microsoft NON acquisisce query_text o query_plan (non stanno guardando i tuoi dati effettivi). Microsoft non archivia semplicemente la telemetria operativa o la utilizza per la risoluzione dei problemi, ma estrae tali dati e li utilizza per sviluppare algoritmi e modelli per consentire a SQL ServerSQL Server di prendere decisioni indipendenti e intelligenti.

SQL ServerSQL Server può sfruttare la pletora di dati in Query Store che descrivono in dettaglio le prestazioni delle query e la correzione automatica del piano inizia confrontando le prestazioni correnti di una query con le prestazioni passate per determinare se è presente una regressione delle prestazioni. Le prestazioni sono diminuite o peggiorate e, in tal caso, è di un importo significativo?

Se si è verificata una regressione nelle prestazioni della query, SQL Server imporrà l'ultimo piano valido noto per tale query, che ovviamente viene estratto da Query Store. Ma non si ferma qui. SQL Server continua quindi a monitorare le prestazioni, sempre usando Query Store, per confermare che il piano forzato è ancora un buon piano per quella query, il che significa che la query con il piano forzato ha prestazioni migliori rispetto alla versione regredita. Se quella query non funziona meglio, annullerà la forza del piano. Un piano può anche essere annullato se è presente una ricompilazione o se la forzatura non riesce.

Questo ciclo continua; se una query ha un piano forzato, e quindi quel piano non è forzato per uno dei motivi sopra menzionati, quello stesso piano può essere forzato di nuovo in un secondo momento, oppure potrebbe esserci un altro piano forzato per quella query in un secondo momento. Questo è un processo continuo che si verifica fintanto che l'opzione di correzione automatica del piano è abilitata per il database. Ora, la cosa interessante è che puoi guardare le stesse informazioni che questa funzione acquisisce e usarle forzare i piani manualmente. Cioè, in SQL Server 2017 Enterprise Edition e nel database SQL di Azure, questi dati vengono raccolti nella DMV sys.dm_db_tuning_recommendations anche quando la funzionalità di correzione automatica del piano non è abilitata, quindi puoi esaminare quei dati e seguirne i consigli per forzare i piani per domande specifiche da solo. Tieni presente che se forzi un piano utilizzando i consigli di sys.dm_db_tuning_recommendations, non verrà mai automaticamente annullato. Inoltre, se hai attivato la correzione automatica del piano e forzi manualmente un piano, non verrà mai annullato automaticamente. Solo i piani forzati con la funzione di correzione automatica del piano verranno annullati automaticamente.

Lascerò davvero il controllo a SQL Server?

Se sei scettico e ti stai chiedendo se puoi davvero fidarti di SQL Server per prendere una decisione di pianificazione, ecco cosa ti incoraggio a ricordare:

Questa funzionalità è stata sviluppata con un'incredibile quantità di dati acquisiti da quasi due milioni di database SQL di Azure. È una nuova funzionalità di SQL Server 2017, ma è diventata disponibile a livello globale nel 2016 in Azure, quindi questa funzionalità è davvero disponibile da oltre un anno ed è stata perfezionata.
Gli ingegneri hanno apportato modifiche all'algoritmo nel tempo, poiché hanno acquisito più dati. Potrebbe non trovare tutte le regressioni che si verificano, perché una regressione potrebbe non essere abbastanza grave, ma scommetto che molti di voi preferirebbero avere questa forza caratteristica meno spesso che troppo spesso.
Inoltre, se un piano viene forzato ma finisce per causare un problema, la capacità di SQL Server di riprendersi e annullare il piano è estremamente affidabile e si verifica molto rapidamente.

Riepilogo

Potresti non essere a tuo agio con l'idea che SQL Server affronti i problemi di prestazioni per te. Ma questo disagio è dovuto al fatto che pensi che prenderà una decisione sbagliata? O sei preoccupato che l'automazione prenda il controllo del tuo lavoro? Domanda piuttosto diretta, lo so. Se è il primo, la mia raccomandazione è di esaminare i dati acquisiti in sys.dm_db_tuning_recommendations (senza abilitare la correzione automatica del piano) e vedere cosa vorrebbe fare SQL Server. È in linea con quello che faresti? Trova regressioni che potresti perdere? Se non vuoi abilitare la funzione perché hai paura di non avere abbastanza da fare, ti incoraggio a leggere il recente post di Conor Cunningham, Come la velocità del cloud aiuta i DBA di SQL Server. Microsoft non sta cercando di codificarti fuori da un lavoro. Stanno semplicemente cercando di gestire i frutti a bassa quota in modo che tu possa concentrarti su compiti più importanti.