Este documento presenta una agenda para optimizar consultas SQL desde abajo hacia arriba. Enrique Catalá es un experto en bases de datos que discute cómo entender planes de ejecución, operadores de join clave y trucos prácticos para mejorar el rendimiento de consultas. La presentación también cubre temas como indexación, agregación de consultas y evitar recompilaciones.

1. Enrique Catalá Bañuls
MAP/MCT/MCITP/MCTS
Optimiza tus queries desde abajo

2. • 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?

3. 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

4. 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.

5. 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

6. ¿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

7. ¿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'

8. 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)

9. 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

10. 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

11. 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

12. ¿Qué información me da un operador?
SQLU Summit

13. Copyright © 2010, SQL PASS Chile. All rights reserved.
Demo
¿Cómo leer un plan de
ejecución?

14. Herramientas de análisis de rendimiento
SQLU Summit
• Monitor de rendimiento
• SQL Server profiler
– Trazas de servidor
• DMVs y DMFs
• Eventos extendidos
• Books Online 

15. 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

16. 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

17. Copyright © 2010, SQL PASS Chile. All rights reserved.
Demo
Parametrización forzada

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

19. Compilaciones y recompilaciones
SQLU Summit
• Hay que evitar siempre compilaciones y
recompilaciones
– Consumo excesivo de CPU y memoria
– Mayor tiempo de respuesta

20. Copyright © 2010, SQL PASS Chile. All rights reserved.
Demo
Recompilaciones parciales

21. 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

22. 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

23. 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?

24. 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 *

25. 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

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

27. 24 HOP LATAM - PATROCINADORES
http://www.idera.com/

28. Copyright © 2010, SQL PASS Chile. All rights reserved.
http://sqlpass.org/
http://www.sqlpass-latam.org/
http://blogs.solidq.com/ElRinconDelDBA/Home.aspx