Execution-Plan

Degree of parallelism (DOP) feedback è una delle nuove feature di SQL Server 2022 e si colloca nella famiglia di funzionalità conosciuta con il nome di Intelligent Query Processing. Queste funzionalità intelligenti e adattive migliorano le prestazioni dei carichi di lavoro esistenti senza modifiche al codice applicativo. Intelligent Query Processing potenziato anche in SQL Server 2019 è l’erede della precedente tecnologia nota con il nome di Adaptive Query Processing.

Degree of parallelism (DOP) feedback

Degree of parallelism (DOP) feedback in SQL Server 2022 potenzia ulteriormente Intelligent Query Processing affrontando lo scenario che si verifica quando una query OLTP viene eseguita ripetutamente in parallel mode e vengono riscontrati problemi di prestazioni. Il parallelismo nel piano di esecuzione di una query è spesso utile per le query analitiche o per le query che gestiscono grandi quantità di dati. Al contrario, le query tipiche di un carico di lavoro OLTP eseguite in parallel mode potrebbero riscontrare problemi di prestazioni quando il tempo impiegato per coordinare i thread interessati supera i vantaggi dell’utilizzo di un piano di esecuzione parallelo.

Introduzione

Parameter Sensitive Plan (PSP) Optimization è una delle funzionalità introdotte da SQL Server 2022 e si colloca nella famiglia di funzionalità note con il nome di Intelligent Query Processing che migliorano le prestazioni dei carichi di lavoro esistenti senza modifiche al codice applicativo. Intelligent Query Processing (potenziato anche in SQL Server 2019) è l’erede della precedente tecnologia nota con il nome di Adaptive Query Processing di cui è disponibile il video Query Processing improvements in the latest versions of SQL Server sul canale UGISS di Vimeo.

In questo articolo verranno trattati i due metodi di elaborazione delle query conosciuti come Row mode execution e Batch mode execution per SQL Server 2019. Verrà inoltre descritto un meccanismo per attivare Batch mode execution su SQL Server 2017 anche quando non si possono creare indici columnstore “effettivi”.

Row mode execution

Row mode execution è un metodo di elaborazione delle query utilizzato con le tabelle tradizionali disk-based, in cui i dati vengono archiviati in formato riga. Le tabelle che utilizzano questo tradizionale formato di archiviazione vengono anche dette “rowstore table”. Quando una query viene eseguita e accede ai dati archiviati in formato riga, gli operatori previsti nel piano di esecuzione leggono ogni riga richiesta dalla query. Da ogni riga letta, SQL Server recupera quindi le colonne necessarie, specificate nell’istruzione SELECT, in un predicato di JOIN, in un predicato di filtro, ecc..

Dal portale redgate è possibile scaricare, gratuitamente (in formato PDF), la terza edizione dell’eBook SQL Server Execution Plans di Grant Fritchey.

Questo libro non può mancare nella vostra libreria!

Buona lettura!

Nell’articolo Conversioni implicite: cosa sono e che impatto hanno sulle nostre query, Luca Bruni (@mrg3d) ci ha parlato delle conversioni implicite che avvengono, a nostra insaputa, all’interno dell’Engine di SQL Server. Tali conversioni, possono costringere il Query Optimizer ad accedere alle tabelle con operazioni di scansione (Table Scan, Index Scan) in alternativa alle più efficienti operazioni di Seek (Index Seek), e quando una parte significativa del carico di lavoro è interessata da conversioni implicite, le performance degradano visibilmente!

Come credo alla maggior parte di voi, spesso, anche a me capita di dover mantenere codice scritto da qualcun altro. Uno degli aspetti che (ri)trovo con una certa frequenza è che, spesso, non prestiamo attenzione a come scriviamo le nostre query, sottovalutando l’impatto che queste possono avere sul nostro sistema.

Proprio recentemente mi sono imbattuto in una serie di batch (dalle semplici query a complesse procedure) dove non si era prestata la dovuta attenzione all’utilizzo dei tipi dato (ad esempio nella definizione di variabili e costanti, ma anche nelle colonne delle stesse tabelle), andando di fatto a creare qualche inconveniente, oltre che di mera natura estetica (e quindi di qualità del codice), anche (e soprattutto) di natura prestazionale. Buona parte di questi problemi era dovuta all’utilizzo frequente delle funzioni di conversione CAST e CONVERT (dovuti a probabili errori di modellazione delle tabelle come ad esempio stessa colonna in due tabelle differenti ma con differente tipo dato), ma la parte più critica e rilevante era dovuta  alla presenza di una miriade di conversioni implicite.

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!”.

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:

• Plan Explorer (versione gratuita)
• Plan Explorer PRO (versione a pagamento)
• Plan Explorer ULTIMATE (con le funzionalità della versione PRO arricchite di due nuove feature: Index Analysis e Performance Profiling, a pagamento)

Greg Gonzalez (@SQLsensei), CEO di SQL Sentry, invece di aumentare le feature a pagamento ha deciso di fondere i tre prodotti in un unico strumento, con tutte le funzionalità, gratuito per tutti gli utenti!

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

Quello che con tutti sanno è che la funzionalità è basata su una feature inserita già dalla SP1 di SQL Server 2014, la DMV

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.