Execution-Plan

Qualche settimana fa, mentre ero al lavoro, mi sono ritrovato a dover risolvere un problema apparentemente non molto strano, ma che tuttavia nasconde qualche retroscena interessante. I fatti sono stati più o meno questi:

Circa a metà mattinata mi è stato segnalato un problema di prestazioni su uno dei sistemi che abbiamo in gestione nel nostro team di lavoro; dopo alcuni semplici controlli è stato subito chiaro che il rallentamento era sostanzialmente dovuto ad un problema di contency sul tempdb. “Beh.. abbastanza semplice!” - ho subito pensato! - “la colpa è mia perché (ahi ahi ahi) non ho ancora fatto lo split del file dati sul tempdb!”.

“SQL Server Management Studio ha smesso di funzionare”, a volte succede di ottenere a video questo messaggio poco simpatico.

Nulla di grave, “basta solo” riavviare il programma.

Ed ecco che una volta riavviato SSMS alcun file è stato recuperato … GRRRRRR!!!!

La cosa meno divertente, quindi, è scoprire che la query/procedura che si stava scrivendo e provando, magari da qualche ora, è andata persa. Ovvero perse le ultime modifiche non salvate .. come dici!? non hai salvato lo script SQL prima di eseguirlo!? Ahhh, non hai proprio salvato nemmeno una volta!?

Chi si occupa di ottimizzare le performance delle query in SQL Server ha sicuramente avuto modo di apprezzare i tool della famiglia “Plan Explorer”, prodotti da SQL Sentry e rivolti sia agli sviluppatori che ai DBA per effettuare analisi approfondite sui piani di esecuzione in SQL Server.

Fino a qualche giorno fa, i tool della famiglia Plan Explorer erano suddivisi in:

Per chi svolge attività di Troubleshooting e Tuning delle Performance, Query Store è una delle feature più interessanti, introdotte con SQL Server 2016. Query Store memorizza tutti i piani di esecuzione generati per una determinata query, cattura le statistiche relative alle performance di esecuzione, fornisce al DBA gli strumenti per forzare, in modo estremamente semplice, il piano di esecuzione per una determinata query.

Vi è mai successo di avere il sito web aziendale talmente lento da essere inutilizzabile? Cosa sta succedendo? Avete mai aggiornato un’applicazione all’ultima versione di SQL Server e incontrato problemi di performance dovuti all’utilizzo di un diverso Piano di Esecuzione per determinate query? La scelta di un diverso piano di esecuzione può causare questi inconvenienti!

Una delle (tante) novità introdotte in SQL Server 2016 sono le Live Statistics che permettono di vedere lo stato di esecuzione di una query in tempo reale. Oltre che essere visivamente molto accattivante, la funzionalità è utile per capire quale parte di una query complessa deve essere ottimizzata.

Live Query Statistics

Sul canale SQLPASS TV è stata pubblicata la sessione “Skewed Data, Poor Cardinality Estimates, and Plans Gone Bad” tenuta da Kimberly Tripp (@KimberlyLTripp) durante lo scorso PASS Summit 2013.

Abstract

When data distribution is heavily skewed, cardinality estimation (how many rows the query optimizer expects each operator to process) can be wildly incorrect, resulting in poor quality query plans and degraded performance. You’ve probably seen the advice to update all statistics if a query plan looks wrong - but is that the right advice? In many cases, no! These are “sledgehammer” approaches, and while they might solve some problems (usually parameter sniffing problems), they don’t solve the actual problem. In this session, you’ll learn a generalized yet tailored-to-the-table way to solve query plan quality problems for very large tables (VLTs). Topics will include creating, using, and updating filtered statistics; using forced parameterization and templatized plan guides; and understanding stored procedures and how they can leverage filtered statistics.