Query-Optimizer

Le performance di una soluzione database sono spesso oggetto di diatriba tra chi fornisce la soluzione e chi la personalizza. Scrivere codice T-SQL ottimizzato, in grado di scalare all’aumentare dei dati e degli utenti, non è affatto semplice e quando la complessità aumenta, le attività di manutenzione del codice diventano difficili da attuare anche per l’autore stesso.

In questo articolo, condivido la metodologia di tuning e alcuni script che utilizzo per ottenere informazioni sulle performance delle query che utilizzano le viste presenti nel database oggetto dell’analisi. La presenza di viste nidificate contenenti query non ottimizzate può diventare oggetto di analisi specifica, gli script contenuti in questo articolo hanno l’obiettivo di fornire alcuni indicatori sull’utilizzo e sulle performance delle viste di un DB.

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.