Benjamin Nevarez è un consulente indipendente con sede a Los Angeles, California, specializzato nell'ottimizzazione e nell'ottimizzazione delle query di SQL Server. È autore di "SQL Server 2014 Query Tuning &Optimization" e "Inside the SQL Server Query Optimizer" e coautore di "SQL Server 2012 Internals". Con oltre 20 anni di esperienza nei database relazionali, Benjamin è stato anche relatore in molte conferenze su SQL Server, tra cui il PASS Summit, SQL Server Connections e SQLBits. Il blog di Benjamin può essere trovato su http://www.benjaminnevarez.com e può anche essere raggiunto via e-mail all'indirizzo admin di benjaminnevarez dot com e su Twitter all'indirizzo @BenjaminNevarez.
Hai mai trovato una regressione del piano dopo un aggiornamento di SQL Server e volevi sapere qual era il piano di esecuzione precedente? Hai mai avuto un problema di prestazioni della query dovuto al fatto che una query ha ricevuto inaspettatamente un nuovo piano di esecuzione? All'ultimo PASS Summit, Conor Cunningham ha scoperto una nuova funzionalità di SQL Server, che può essere utile per risolvere i problemi di prestazioni relativi a questi e altri cambiamenti nei piani di esecuzione.
Questa funzionalità, denominata Query Store, può aiutarti con problemi di prestazioni relativi alle modifiche del piano e sarà presto disponibile in SQL Azure e successivamente nella prossima versione di SQL Server. Anche se dovrebbe essere disponibile nell'edizione Enterprise di SQL Server, non è ancora noto se sarà disponibile in Standard o in qualsiasi altra edizione. Per comprendere i vantaggi del Query Store, vorrei parlare brevemente del processo di risoluzione dei problemi delle query.
Perché una query è lenta?
Dopo aver rilevato che un problema di prestazioni è dovuto al fatto che una query è lenta, il passaggio successivo consiste nel scoprire il motivo. Ovviamente non tutti i problemi sono legati ai cambiamenti di piano. Potrebbero esserci diversi motivi per cui una query che ha funzionato bene è improvvisamente lenta. A volte ciò potrebbe essere correlato al blocco o a un problema con altre risorse di sistema. Qualcos'altro potrebbe essere cambiato, ma la sfida potrebbe essere scoprire cosa. Molte volte non abbiamo una linea di base sull'utilizzo delle risorse di sistema, sulle statistiche di esecuzione delle query o sulla cronologia delle prestazioni. E di solito non abbiamo idea di quale fosse il vecchio piano. È possibile che alcune modifiche, ad esempio dati, schema o parametri di query, abbiano indotto il Query Processor a produrre un nuovo piano.
Modifiche al piano
Durante la sessione, Conor ha utilizzato lo strumento Picasso Database Query Optimizer Visualizer, sebbene non lo abbia menzionato per nome, per mostrare perché i piani nella stessa query sono cambiati e ha spiegato il fatto che è possibile selezionare piani diversi per la stessa query in base a la selettività dei loro predicati. Ha anche menzionato che il team di Query Optimizer utilizza questo strumento, che è stato sviluppato dall'Indian Institute of Science. Un esempio della visualizzazione (clicca per ingrandire):
Visualizzatore Query Optimizer del database Picasso
Ogni colore nel diagramma è un piano diverso e ogni piano viene selezionato in base alla selettività dei predicati. Un fatto importante è che quando un confine viene superato nel grafico e viene selezionato un piano diverso, il più delle volte il costo e le prestazioni di entrambi i piani dovrebbero essere simili, poiché la selettività o il numero stimato di righe cambia solo leggermente. Ciò potrebbe accadere, ad esempio, quando una nuova riga viene aggiunta a una tabella che si qualifica per il predicato utilizzato. Tuttavia, in alcuni casi, principalmente a causa di limitazioni nel modello di costo di Query Optimizer in cui non è in grado di modellare qualcosa in modo corretto, il nuovo piano può presentare una notevole differenza di prestazioni rispetto al precedente, creando un problema per l'applicazione. A proposito, i piani mostrati nel diagramma sono il piano finale selezionato da Query Optimizer, non confonderlo con le numerose alternative che l'ottimizzatore deve considerare per selezionarne solo una.
Un fatto importante, secondo me, che Conor non ha trattato direttamente, è stato il cambio di piani dovuto a regressioni dopo modifiche su aggiornamenti cumulativi (CU), service pack o aggiornamenti di versione. Una delle principali preoccupazioni che viene in mente con le modifiche all'interno di Query Optimizer sono le regressioni dei piani. La paura delle regressioni del piano è stata considerata il più grande ostacolo ai miglioramenti di Query Optimizer. Le regressioni sono problemi introdotti dopo che è stata applicata una correzione a Query Optimizer e talvolta vengono definiti i classici "due o più errori fanno una cosa giusta". Questo può accadere quando, ad esempio, due stime sbagliate, una che sopravvaluta un valore e l'altra che lo sottovaluta, si annullano a vicenda, dando fortunatamente una buona stima. La correzione di uno solo di questi valori ora può portare a una stima errata che può influire negativamente sulla scelta della selezione del piano, causando una regressione.
Che cosa fa il Query Store?
Conor ha menzionato che il Query Store funziona e può aiutare con quanto segue:
- Memorizza la cronologia dei piani di query nel sistema;
- Cattura le prestazioni di ogni piano di query nel tempo;
- Identifica le query che sono "diventate più lente di recente";
- Consentono di forzare i piani rapidamente; e,
- Assicurati che funzioni su riavvii del server, aggiornamenti e ricompilazione di query.
Quindi questa funzione non solo memorizza i piani e le relative informazioni sulle prestazioni delle query, ma può anche aiutarti a forzare facilmente un vecchio piano delle query, che in molti casi può risolvere un problema di prestazioni.
Come utilizzare il Query Store
È necessario abilitare il Query Store utilizzando ALTER DATABASE CURRENT SET QUERY_STORE = ON; dichiarazione. L'ho provato nel mio attuale abbonamento a SQL Azure, ma l'istruzione ha restituito un errore poiché sembra che la funzionalità non sia ancora disponibile. Ho contattato Conor e mi ha detto che la funzione sarà presto disponibile.
Una volta abilitato, Query Store inizierà a raccogliere i piani e i dati sulle prestazioni delle query e potrai analizzare tali dati esaminando le tabelle di Query Store. Al momento posso vedere quelle tabelle su SQL Azure ma, poiché non sono stato in grado di abilitare il Query Store, i cataloghi non hanno restituito dati.
È possibile analizzare le informazioni raccolte in modo proattivo per comprendere le modifiche alle prestazioni delle query nell'applicazione o in modo retroattivo in caso di problemi di prestazioni. Una volta identificato il problema, puoi utilizzare le tradizionali tecniche di ottimizzazione delle query per provare a risolvere il problema, oppure puoi utilizzare il sp_query_store_force_plan stored procedure per forzare un piano precedente. Il piano deve essere acquisito nel Query Store per essere forzato, il che ovviamente significa che è un piano valido (almeno quando è stato raccolto; ne parleremo più avanti) ed è stato generato da Query Optimizer in precedenza. Per forzare un piano è necessario il plan_id , disponibile nel sys.query_store_plan Catalogare. Dopo aver esaminato le diverse metriche memorizzate, che sono molto simili a quelle memorizzate ad esempio in sys.dm_exec_query_stats , puoi decidere di ottimizzare per una metrica specifica, come CPU, I/O, ecc. Quindi puoi semplicemente utilizzare un'istruzione come questa:
EXEC sys.sp_query_store_force_plan @query_id = 1, @plan_id = 1;
Questo sta dicendo a SQL Server di forzare il piano 1 sulla query 1. Tecnicamente potresti fare la stessa cosa usando una guida al piano, ma sarebbe più complicato e in primo luogo dovresti raccogliere e trovare manualmente il piano richiesto.
Come funziona il Query Store?
In realtà, la forzatura di un piano utilizza le guide del piano in background. Conor ha affermato che "quando si compila una query, aggiungiamo implicitamente un suggerimento USE PLAN con il frammento del piano XML associato a tale affermazione". Quindi non è più necessario utilizzare una guida del piano. Tieni anche a mente che, come usare una guida del piano, non è garantito che abbia esattamente il piano forzato ma almeno qualcosa di simile ad esso. Per un promemoria su come funzionano le guide dei piani, dai un'occhiata a questo articolo. Inoltre, dovresti essere consapevole del fatto che ci sono alcuni casi in cui la forzatura di un piano non funziona, un tipico esempio è quando lo schema è cambiato, ad esempio se un piano archiviato utilizza un indice ma l'indice non esiste più. In questo caso SQL Server non può forzare il piano, eseguirà una normale ottimizzazione e registrerà il fatto che l'operazione di forzatura del piano non è riuscita nel sys.query_store_plan catalogo.
Architettura
Ogni volta che SQL Server compila o esegue una query, viene inviato un messaggio al Query Store. Questo viene mostrato di seguito.
Panoramica del flusso di lavoro di Query Store
Le informazioni di compilazione ed esecuzione vengono prima conservate in memoria e poi salvate su disco, a seconda della configurazione del Query Store (i dati vengono aggregati secondo il INTERVAL_LENGTH_MINUTES parametro, che per impostazione predefinita è un'ora, e scaricato su disco in base a DATA_FLUSH_INTERVAL_SECONDS parametro). I dati possono anche essere scaricati su disco se c'è una pressione di memoria sul sistema. In ogni caso potrai accedere a tutti i dati, sia in memoria che su disco, quando esegui il sys.query_store_runtime_stats catalogo.
Cataloghi
I dati raccolti vengono mantenuti su disco e archiviati nel database utente in cui è abilitato Query Store (e le impostazioni sono archiviate in sys.database_query_store_options . I cataloghi Query Store sono:
sys.query_store_query_text | Richiedere informazioni sul testo |
sys.query_store_query | Testo della query più il piano utilizzato che influisce sulle opzioni SET |
sys.query_store_plan | Piani di esecuzione, inclusa la cronologia |
sys.query_store_runtime_stats | Query statistiche di runtime |
sys.query_store_runtime_stats_interval | Ora di inizio e fine degli intervalli |
sys.query_context_settings | Richiedere informazioni sulle impostazioni del contesto |
Viste di Query Store
Le statistiche di runtime acquisiscono un'intera serie di metriche, tra cui media, ultima, minima, massima e deviazione standard. Ecco il set completo di colonne per sys.query_store_runtime_stats :
runtime_stats_id | plan_id | runtime_stats_interval_id | ||
execution_type | execution_type_desc | first_execution_time | last_execution_time | count_executions |
avg_duration | last_duration | min_duration | max_duration | stdev_duration |
avg_cpu_time | last_cpu_time | min_cpu_time | max_cpu_time | stdev_cpu_time |
avg_logical_io_reads | last_logical_io_reads | min_logical_io_reads | max_logical_io_reads | stdev_logical_io_reads |
avg_logical_io_writes | last_logical_io_writes | min_logical_io_writes | max_logical_io_writes | stdev_logical_io_writes |
avg_physical_io_reads | last_physical_io_reads | min_physical_io_reads | max_physical_io_reads | stdev_physical_io_reads |
avg_clr_time | last_clr_time | min_clr_time | max_clr_time | stdev_clr_time |
avg_dop | last_dop | min_dop | max_dop | stdev_dop |
avg_query_max_used_memory | last_query_max_used_memory | min_query_max_used_memory | max_query_max_used_memory | stdev_query_max_used_memory |
avg_rowcount | last_rowcount | min_rowcount | max_rowcount | stdev_rowcount |
Colonne in sys.query_store_runtime_stats
Questi dati vengono acquisiti solo al termine dell'esecuzione della query. Il Query Store considera anche il SET della query opzioni, che possono influire sulla scelta di un piano di esecuzione, poiché influiscono su cose come i risultati della valutazione delle espressioni costanti durante il processo di ottimizzazione. Tratto questo argomento in un post precedente.
Conclusione
Questa sarà sicuramente un'ottima funzionalità e qualcosa che vorrei provare il prima possibile (a proposito, la demo di Conor mostra "SQL Server 15 CTP1" ma quei bit non sono disponibili pubblicamente). L'archivio query può essere utile per gli aggiornamenti che possono essere una versione CU, service pack o SQL Server, in quanto è possibile analizzare le informazioni raccolte dall'archivio query prima e dopo per vedere se una query è stata regredita. (E se la funzione è disponibile nelle edizioni inferiori, potresti anche farlo in uno scenario di aggiornamento SKU.) Sapere questo può aiutarti a intraprendere alcune azioni specifiche a seconda del problema e una di queste soluzioni potrebbe essere quella di forzare il piano precedente come spiegato prima.
