Optimiza tus queries desde abajo

Enrique Catalá Bañuls

MAP/MCT/MCITP/MCTS

Optimiza tus queries desde abajo

• Ingeniero Informático

• Mentor en Solid Quality Mentors

• Microsoft Active Professional 2010

• Microsoft Certified Trainer

• Microsoft Certified IT Professional – Database Developer 2008

– Database Administrator 2008

• Arquitecto de entre otros

Health Check y SCODA

¿Quién es Enrique Catala?

Agenda Optimiza desde abajo

SQLU Summit

• Entender el motor de consulta relacional

• Planes de ejecución

– Leer planes de ejecución

– Foco especial en los operadores join

• Trucos prácticos

– Estrategias y situaciones que conviene conocer

El optimizador de consultas

SQLU Summit

• Encargado de planificar la navegación de los datos almacenados físicamente

• Debe tener numerosas variables en cuenta: – ¿Qué objetos están involucrados? – ¿Qué tamaño tienen? (si son tablas) – ¿Qué índices y estadísticas hay definidos para ellos? – ¿Cómo está dispuesta la información físicamente? – ¿Qué operadores se utilizarán? – …

• Puede producir N^n soluciones posibles • Es el culpable de que en cada versión, nuestro código sea

más rápido.

Query plan vs execution context

SQLU Summit

• Query plan (conocido como «plan de ejecución») – Método de acceso (El «algoritmo» por decirlo de alguna forma) – Depende del patrón de consulta – Solo lectura y reentrables – Compartido con múltiples usuarios – Dos versiones en ocasiones

• Versión en serie • Versión paralela

• Execution context (conocido como «contexto de ejecucion») – Lo que se ejecuta finalmente y obtiene resultados – Depende de los valores de parámetros – Son reutilizables pero no reentrables – Dependen completamente del user token y login token

• Mismos parámetros crean execution contexts diferentes con distintos usuarios

¿Se puede descartar un plan de ejecución?

SQLU Summit

• El valor de un plan de ejecución que se decrementa, se calcula en nº de ticks y tiene un valor máximo de 31, de forma que: – COSTE = (coste E/S) + (coste cambio contexto CPU) + (coste memoria) – Siendo

• Dos operaciones E/S = 1 tick (máximo 19) • Dos cambios de contexto CPU = 1 tick (máximo 8) • 128kb necesario = 1 tick (máximo 4)

– Para ad-hoc siempre es 0 y se incrementa en 1 cada vez que se reutiliza

• A partir de 2005 existe separación data-cache y plan-cache y lazywritter solo decrementa data-cache por lo que… – Tan pronto se llega al 50% del tamaño disponible para el buffer pool, el

siguiente plan de ejecución nuevo que entra en el plan-cache, decrementa una unidad el contador de todos los planes de ejecución que existan en el plan-cache.

– Si se llega al 75% del tamaño, se activa un gestor de recursos que decrementa el contador de todos los planes de ejecución en 1

¿Qué afecta a los planes de ejecución?

SQLU Summit

• Tipo de ejecución – Consultas ad-hoc – Procedimientos almacenados

• Tienen en cuenta – Valores dados a los filtros y variables en su creación – Estadísticas

• No tienen en cuenta – Bloqueos en curso – Uso de memoria en curso

• Les afecta y mucho la presión de CPU

select occurrence from sys.dm_exec_query_optimizer_info where counter = 'timeout'

Nested loops

SQLU Summit

• Pseudocódigo

• Operador join mas simple

• Doble bucle

• … R1 inner join R2 …

for each row R1 in the outer table for each row R2 in the inner table if R1 joins with R2 return (R1, R2)

Hash join

SQLU Summit

• Ejecución en dos fases – Build: Cálculo de clave hash del inner – Prueba: Lee la outer, crea su hash y compara con hash precalculado en fase

build

• Si se estima menos memoria para hash, aparecen los hash warnings y carga en tempdb

for each row R1 in the build table begin calculate hash value on R1 join key(s) insert R1 into the appropriate hash bucket end for each row R2 in the probe table begin calculate hash value on R2 join key(s) for each row R1 in the corresponding hash bucket if R1 joins with R2 return (R1, R2) end

Merge join

SQLU Summit

• Pseudocódigo versión uno a muchos

• Lee simultáneamente las dos entradas

get first row R1 from input 1 get first row R2 from input 2 while not at the end of either input begin if R1 joins with R2 begin return (R1, R2) get next row R2 from input 2 end else if R1 < R2 get next row R1 from input 1 else get next row R2 from input 2 end

Operadores de join

SQLU Summit

• Nested Loops: – Útiles para conjuntos pequeños de resultados. – Su eficiencia depende del producto de tabla inner (arriba) * tabla outer (abajo) – Puede escupir resultados inmediatamente – soporta cualquier tipo de join – Es el que más frecuentemente se encuentra – Es altamente ineficiente si los conjuntos de datos son grandes

• Merge join: – Util para conjuntos relativamente medianos de resultados. – Es el mejor cuando hablamos de grandes valores de datos en tabla inner y outer porque su eficiencia depende de la suma de filas de

ambas tablas – Puede escupir resultados inmediatamente – Solo soporta equijoin – Los datos deben ser ordenados "the inputs to the merge join must be sorted on the join keys. For example, if we have a join predicate

“T1.a = T2.b,” table T1 must be sorted on T1.a and table T2 must be sorted on T2.b"

• Hash join: – Util para grandes conjuntos de resultados no ordenados y cuando la tabla que manda (inner) tiene sustancialmente menos filas que la

dependiente. – Hasta no estar todo calculado, no escupe resultados – Ineficiente si las dos tablas son muy grandes – Su existencia indica:

• Falta un índice o el que existe no nos sirve • Falta WHERE • Alguna condicion no satisface al indice (en caso de haberlo) por culpa de algun calculo o algo...

Podemos forzar su uso

¿Qué información me da un operador?

SQLU Summit

Copyright © 2010, SQL PASS Chile. All rights reserved.

Demo ¿Cómo leer un plan de

ejecución?

Herramientas de análisis de rendimiento

SQLU Summit

• Monitor de rendimiento

• SQL Server profiler

– Trazas de servidor

• DMVs y DMFs

• Eventos extendidos

• Books Online

Mejorar escenarios ad-hoc (I)

SQLU Summit

• Optimize for ad-hoc workloads – A nivel de instancia de SQL Server – Solo útil para consultas ad-hoc livianas – Almacena un pequeño código auxiliar en lugar del plan completo – Minimiza presión sobre el cache de planes de ejecución – Solo si se detecta reutilización, se recompila y almacena en cache

Mejorar escenarios ad-hoc (II)

SQLU Summit

• Force parametrization – A nivel de base de datos – Ocurre por cada statement. Cada batch puede tener múltiples statements autoparametrizados – Fuerza la parametrización de toda sentencia SELECT, UPDATE, INSERT y DELETE – En ciertos escenarios, mejora enormemente el rendimiento a base de reutilización de planes de ejecución

• PRECAUCIÓN: Testear siempre el entorno antes de poner en producción. Puede que salgamos

perdiendo…¿alguien sabe por qué?

Excepciones Statements dentro de SP, funciones,…

Si ANSI_PADDING o ANSI_NULL = OFF

Statements que referencian variables

Statements en cursor


Demo Parametrización forzada

Vaciar plan cache

SQLU Summit

• ALTER DATABASE [dbName] SET ONLINE • ALTER DATABASE [dbName] SET OFFLINE • ALTER DATABASE [dbName] SET READ_ONLY • ALTER DATABASE [dbName] SET READ_WRITE • ALTER DATABASE [dbName] MODIFY NAME = [SomeDB_Name] • ALTER DATABASE [dbName] MODIFY FILEGROUP Test1FG1 DEFAULT • ALTER DATABASE [dbName] MODIFY FILEGROUP Test1FG1 READ_WRITE • ALTER DATABASE [dbName] MODIFY FILEGROUP Test1FG1 READ_ONLY • ALTER DATABASE [dbName] COLLATE Collation_Name • DROP DATABASE [db_Snapshot_Name] • DBCC FREEPROCCACHE • DBCC FREESYSTEMCACHE • • OJO: En SQL Server 2005 RTM y SP1, DBCC CHECKDB limpia el plan cache PARA LA

INSTANCIA DE SQL SERVER!!!

Compilaciones y recompilaciones

SQLU Summit

• Hay que evitar siempre compilaciones y recompilaciones

– Consumo excesivo de CPU y memoria

– Mayor tiempo de respuesta


Demo Recompilaciones parciales

Agregación de consultas

SQLU Summit

• Es lo que debemos hacer siempre de cara a una primera optimización.

• Antes de SQL Server 2008 – Procesos externos como nuestro HealthCheck

• A partir de SQL Server 2008 – Ahora además, podemos hacer uso de DMVs

• Sys.dm_exec_query_stats • Columnas

– Query_hash » Hash calculado en la consulta…util para identificar consultas con lógica similar (lo

que hace HealthCheck) » Util para buscar consultas con literales diferentes

– Query_plan_hash » Hash calculado del plan de ejecución » Util para buscar planes de ejecución similares

– NOTA: esto solo captura desde la última ejecución de SQL Server

Un ejemplo de lo que debemos buscar

SQLU Summit

11% 1%

18%

69%

0% 0%

0%

1%

% of memory used

Compiled Plan Proc

Compiled Plan Trigger

Compiled Plan Adhoc

Compiled Plan Prepared

Extended Proc Proc

Parse Tree UsrTab

Parse Tree Check

Parse Tree View

Database Name Cached Pages Memory (MB)

BBDD1 588.870 4600,55

BBDD2 98.906 772,7

tempdb 2.889 22,57

msdb 1.149 8,98

BBDD3 327 2,55

BBDD4 174 1,36

BBDD5 138 1,08

master 54 0,42

BBDD6 35 0,27

BBDD7 30 0,23

model 1 0,01

AdventureWorks 1 0,01

ReportServer 1 0,01

AdventureWorksDW 1 0,01

ReportServerTempDB 1 0,01

Indexación

SQLU Summit

• Tareas que debemos realizar – Búsqueda de índices faltantes – Búsqueda de índices que no se usan – Búsqueda de índices duplicados – Comparación de índices clústered vs nonclustered – Quitar siempre key y RID lookups

• Filtrar índices si es necesario • No aplicar funciones a columnas de índice • No utilizar predicados tipo like ‘%...’ • Cuidado con los predicados: (a,b) requiere buscar por a como

mínimo. • Pregunta: ¿En un índice definido por la tupla (a,b), si no se hace

referencia a «a», se utilizará el índice?

Los 10 mandamientos del rendimiento

SQLU Summit

• Amaras a los procedimientos almacenados sobre todas las cosas • No aplicarás una función de SQL server en vano • Santificarás los índices • Honrarás las claves ajenas y las restricciones check • SI matarás a cursores y consultas ad-hoc • Cometerás agregación de consultas • No robarás ciclos de CPU mediante recompilaciones • No levantarás tablas variables cuando deberían ser temporales • No consentirás el uso de query hints sin conocimiento de causa • No codiciaras un SELECT *

Mas información

• El rincón del DBA – http://blogs.solidq.com/ElRinconDelDBA/Home.aspx

• BI Corner – http://blogs.solidq.com/BICorner/Home.aspx

• SolidQ SharePoint Team Blog – http://blogs.solidq.com/sharepoint

• CuevaNet – http://blogs.solidq.com/cuevanet

• Todos los Blogs – http://blogs.solidq.com


Preguntas

24 HOP LATAM - PATROCINADORES

http://www.idera.com/


http://sqlpass.org/

http://www.sqlpass-latam.org/

http://blogs.solidq.com/ElRinconDelDBA/Home.aspx

Optimiza tus queries desde abajo

Technology

Transcript of Optimiza tus queries desde abajo