Prácticamente toda aplicación utiliza por debajo un motor de base de datos para almacenar información. Entender lo que hace cuando le pedimos datos a SQL Server puede ayudar a cualquier desarrollador a entender por qué sus consultas van lentas. No se trata solo de abrir esa "caja negra" que es SQL Server, sino de entender lo que realmente tiene en su interior. En esta sesión aprenderemos a leer planes de ejecución y contaremos además, qué novedades hay en SQL Server 2014 con el nuevo cardinality estimator

1. Planes de ejecución en SQL
Server 2014
Enrique Catala Bañuls
MVP , Mentor
ecatala@solidq.com
Twitter: @enriquecatala
www.enriquecatala.com

2. 3 Sponsor Sessions at 11:15
 Don’t miss them, they might be getting
distributing some awesome prizes!
 Attunity
 SolidQ
 ApexSQL
 Also Raffle prizes at the end of the
event provided by
Cisco, SolidQ, Attunity, ApexSQL &
Microsoft

3. Our Main Sponsors:

4. Agenda
1. Planes de ejecución
2. Operadores
3. Cardinality estimator

5. Planes de ejecución
¿Sabemos interpretarlos?
5
Optimizador de
consultas
Sentencia SQL Plan de ejecución
Mágia

6. Operadores
¿Cuántos y cuales son?
8

7. Operadores
Los básicos que debes conocer
9
SELECT Sort
Clustered Index
Seek
Clustered Index
Scan
Non-clustered
index scan
Non-clustered
index seek Table Scan RID Lookup Key Lookup Hash Match
Nested Loops Merge Join Compute Scalar
Constant
Scan Spool
Stream Aggregate Distribute Streams Gather Streams
Repartition
Streams Bitmap
Split Top Filter Lazy Spool Eager Spool

8. Operadores
¿Qué son?
10
 Todo operador funciona pidiendo filas de uno o
mas hijos y devolviéndolas al que se las ha pedido
 Caso especial Common Table Spool
 Cada operador devuelve de 1 fila en 1 fila
 *No todos -> Ver sesión Niko Neugebauer a las 13h BI

9. DEMO
12
Operadores básicos

10. Procesamiento lógico
De una consulta
13
1. FROM
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
1. Evaluar expresiones
2. Eliminar duplicados
6. ORDER BY
7. OFFSET-FETCH/TOP

11. Planes de ejecución
Flechas
14
¿Ves la diferencia en el grosor de la flecha? 
Estimación un poco equivocada! 
1. Analiza el grosor de las flechas
2. Compara los valores del plan estimado vs. el real

12. Planes de ejecución
Comparar planes
15
 Fíjate en los % de consulta

13. Operadores join
Nested loops
16
for each row R1 in the outer table
for each row R2 in the inner table
if R1 joins with R2
return (R1, R2)
*No confundir inner table con inner join ni
outer table com outer join

14. ID_Alum Nombre_Aluno ID_Curso
1Luis 2
2Ana 6
3Juan 5
4Pepe 3
5Carlos 4
6Felipe 3
7Iratxe 5
8María 4
Tabla de Alumnos:
ID_Curso Nombre_Curso
1Paisajismo
2Fotografía
3Arte Clásico
4Matemáticas
5Física
6Química
Tabla de Cursos:
Resultado:
Nombre Alumno | Nombre Curso
1-Luis |2-Fotografía
4-Pepe |3-Arte Clásico
6-Felipe |3-Arte Clásico
5-Carlos |4-Matemáticas
8-María |4-Matemáticas
...

15. Operadores join
Merge join
18
 get first row R1 from input 1
 get first row R2 from input 2
 while not at the end of either input
 {
 if R1 joins with R2
 {
 return (R1, R2)
 get next row R2 from input 2
 }
 else if R1 < R2
 get next row R1 from input 1
 else
 get next row R2 from input 2
 }

16. Tabla de Alumnos:
ID_Curso Nombre_Curso
1Paisajismo
2Fotografía
3Arte Clásico
4Matemáticas
5Física
6Química
Tabla de Cursos:
Resultado:
ID_Aluno
s Nome_Aluno
ID_Curso
s
1Luís 2
2Ana 6
3Juan 5
4Pepe 3
5Carlos 4
6Felipe 3
7Iratxe 5
8María 4
ID_Alum Nombre_Alumno ID_Curso
1Luís 2
4Pepe 3
6Felipe 3
5Carlos 4
8María 4
Nombre Alumno | Nombre Curso
1-Luis |2-Fotografía
4-Pepe |3-Arte Clásico
6-Felipe |3-Arte Clásico
5-Carlos |4-Matemáticas
8-María |4-Matemáticas
...
Operadores join
Merge join

17. Operadores join
Hash join
20
 Ejecución en dos fases
1. Build: Cálculo de clave hash del inner
2. Prueba: Lee la outer, crea su hash y compara con hash
precalculado en fase build
for each row R1 in the build table
{
calculate hash value on R1 join key(s)
insert R1 into the appropriate hash bucket
}
for each row R2 in the probe table
{
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)
}

18. RecomendacionesNestedLoop
• No
bloqueante
• Eficiencia de
tabla inner
(arriba)
• Soporta
cualquier
join
• Util cjtos
pequeños
MergeJoin
• No
bloqueante
• Datos
ordenados
• Solo
equijoin
HashJoin
• Bloqueante
• Tabla inner
muy
pequeña

19. Propiedades

20. DEMO
23
Leamos planes!

21. Operadores exchange
Distribute Streams
Hash
• Los valores de
filas obtienen
hash y cada
hilo se
responsabiliza
de un rango
hash
Round Robin
• Los valores de
las filas se
envían al
siguiente hilo
de la lista
Range
• Determina a
que hilo enviar
la fila
evaluando una
funcion de
rango sobre
una columna
• Rara y usada
en algunos
parallel index
recreation
Broadcast
• Todas las filas
se envian a
todos los hilos
Demand
• Se usa un
modo pull en
lugar de push
como en las
otras.
• Envia la fila al
thread que se
la está
pidiendo
• Aparece en
tablas
particionadas

22. Operadores exchange
Repartition streams
25
• Consume múltiples fuentes y produce multiples fuentes
• No se modifican las filas
• Se reducen filas si aparece un operador bitmap

23. Operadores exchange
Gather streams
• Consume múltiples hilos y produce un único hilo
• Combina resultados
• Es el que mayor % de esperas suele generar

24. Agenda
1. Planes de ejecución
2. Operadores
3. Cardinality estimator

25. Cardinality estimator
El mayor cambio en el motor “OnDisk” desde SQL Server 7.0
29
• Aporta el nº de registros
involucrados en la
sentencia (en cada paso)
• Estima el recuento de
filas afectadas
• Aporta distribución de
valores
• Aporta info distinct
count
• Aporta info sobre
duplicados
Estimarselectividaddelpredicado
WHERE

26. • Se decide el algoritmo de obtención de datos
• Malas interpretaciones producen
• Malos planes de ejecución
• Mal rendimiento de consultas
Cardinality estimator
El mayor cambio en el motor “OnDisk” desde SQL Server 7.0
30

27. Cardinality estimator
Desde SQL Server 7.0 hasta SQL Server 2012
31
Independencia
• Distribución de datos
independiente de unos
campos a otros salvo
que se indique lo
contrario
Uniformidad
• Los valores se
distribuyen
uniformemente
Contenido
• Si algo se busca será
porque existe
• Si una table se cruza,
será porque existe el
dato en ambas
• El rango menor se
asume contenido en el
mayorInclusión
• En equijoin se assume
que el valor existe
¿Acaso
eso
sucede?

28. DEMO
33
Nuevo cardinality estimator

29. Conclusión
1. Ser capaces de leer los planes de
ejecución
2. Conocer el funcionamiento de los
operadores mas importantes
3. Conocer algunas novedades en SQL
Server 2014
34

30. Gracias!
Enrique Catala Bañuls
ecatala@solidq.com
Twitter: @enriquecatala
www.enriquecatala.com