Países el alto ingreso y stock per cápita en América Latina (1819-2024).pdf
24 HOP edición Español - Planes de ejecución en sql server 2014 - Enrique Catala
1. Planes de ejecución en SQL Server
2014
Enrique Catala Bañuls (España) @enriquecatala
MVP | MCT | ecatala@solidq.com www.enriquecatala.com
Moderada: Freddy Angarita
2. Gracias a nuestros auspiciadores
Database Security as Easy as A-B-C
http://www.greensql.com
Hardcore Developer and IT
Training
http://www.pluralsight.com
SQL Server Performance
Try PlanExplorer today!
http://www.sqlsentry.com
3. Próximos SQL Saturday
6 de Diciembre de 2014
https://www.sqlsaturday.com/351/register.aspx
24 de Enero de 2015
https://www.sqlsaturday.com/346/register.aspx
18 de Abril de 2015
https://www.sqlsaturday.com/368/register.aspx
9 de Mayo de 2015
https://www.sqlsaturday.com/373/register.aspx
4. Capítulo Global PASS en Español
4
4
Reuniones semanales todos los miércoles a
las 12PM UTC-5 (Hora de Colombia)
https://www.facebook.com/SpanishPASSVC
5. 5
Asistencia Técnica
Si requiere asistencia
durante la sesión debe
usar la sección de
preguntas que esta en el
menú de la derecha.
Use el botón de Zoom
para ajustar su pantalla
al tamaño deseado
Escriba sus preguntas
en la sección de
preguntas que esta en el
menú de la derecha
6. 6
Enrique Cátala
• Mentor en SolidQ
• Microsoft SQL Server MVP
• Ingeniero en informática
• Microsoft Certified Trainer (MCT) , MCSE y MAP (Microsoft Active Professional).
• Centrado en el motor relacional SQL Server, tanto en la resolución de problemas de
rendimiento y escalabilidad en sistemas OLTP como la definición e implementación de
entornos de alta disponibilidad confiables, en donde ha llevado con éxito más de 90
proyectos no solo en España, sino en diferentes países como EEUU, Holanda, México,
Arabia Saudí o Austria.
• Arquitecto principal de las soluciones para SolidQ llamadas HealthCheck, SQL2Cloud,
SCODA y del generador de SSIS de SolidQ
• Ponente habitual del SolidQ SUMMIT, miembro y ponente en SQL PASS tanto en España
como Iberoamérica ponente en varios SQLSaturday
• Colabora con Microsoft realizando Webcast y conferencias.
• Mantiene tanto su blog personal (http://www.enriquecatala.com/ ), como "El Rincón del DBA"
(http://blogs.solidq.com/es/elrincondeldba ) con colegas de SolidQ.
6
10. Operadores
Los básicos que debes conocer
12
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
11. Operadores
¿Qué son?
Todo operador funciona pidiendo filas de uno o mas hijos y
devolviéndolas al que se las ha pedido
13
Caso especial Common Table Spool
Cada operador devuelve de 1 fila en 1 fila
*No todos
13. Procesamiento lógico
De una consulta
16
1. FROM
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
1. Evaluar expresiones
2. Eliminar duplicados
6. ORDER BY
7. OFFSET-FETCH/TOP
14. Planes de ejecución
Flechas
17
1. Analiza el grosor de las flechas
2. Compara los valores del plan estimado vs. el real
¿Ves la diferencia en el grosor de la flecha?
Estimación un poco equivocada!
16. Operadores join
Nested loops
19
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
17. 20
Tabla de Alumnos:
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 Cursos:
ID_Curso Nombre_Curso
1Paisajismo
2Fotografía
3Arte Clásico
4Matemáticas
5Física
6Química
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
...
18. Operadores join
Merge join
21
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
}
20. Operadores join
Hash join
23
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)
}
21. Recomendaciones
Nested Loop
• No
bloqueante
• Eficiencia de
tabla inner
(arriba)
• Soporta
cualquier join
• Util cjtos
pequeños
Merge Join
• No
bloqueante
• Datos
ordenados
• Solo equijoin
Hash Join
• Bloqueante
• Tabla inner
muy pequeña
24. 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
25. Operadores exchange
Repartition streams
• Consume múltiples fuentes y produce multiples fuentes
• No se modifican las filas
• Se reducen filas si aparece un operador bitmap
28
26. Operadores exchange
Gather streams
• Consume múltiples hilos y produce un único hilo
• Combina resultados
• Es el que mayor % de esperas suele generar
28. Cardinality estimator
El mayor cambio en el motor “OnDisk” desde SQL Server 7.0
32
• 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
Estimar selectividad del predicado
WHERE
29. Cardinality estimator
El mayor cambio en el motor “OnDisk” desde SQL Server 7.0
• Se decide el algoritmo de obtención de datos
• Malas interpretaciones producen
• Malos planes de ejecución
• Mal rendimiento de consultas
33
30. Cardinality estimator
Desde SQL Server 7.0 hasta SQL Server 2012
34
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
Inclusión mayor
• En equijoin se assume
que el valor existe
¿Acaso eso
sucede?
32. 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
37
Son unos 166 en SQL Server 2014 http://msdn.microsoft.com/en-us/library/ms191158(v=sql.120).aspx
No toda operación tiene representación.
Los operadores paralelos poseen una variante con doble flecha en la parte inferior izquierda
5’
Los dibujitos son bastante explicativos
Los operadores de tipo índice columnar y los de tipo Exchange paralelos, que funcionan enviando paquetes de filas
10’
Obviamente dependen del operador
Aprovechar para planes de ejecución actuales vs estimados
15’
Esto es importantísimo para entender los planes de ejecución
Esto es mucho mas frecuente de lo que parece. ¡Actualiza tus estadísticas!
Es el operador mas sencillo
Es un doble bucle
Lee simultáneamente las dos entradas
Ambas entradas deben estar ordenadas
37’
Si se estima menos memoria para hash, aparecen los temidos hash warnings…
Notas Hash Join:
-La existencia de Hash Join cuando la tabla inner no es sustancialmente menor típicamente indica que falta algun filtro.
-Hay que estar vigilantes ante Hash Warning Events – Profiler
-Altamente ineficiente si las tablas son muy grandes
Estimated CPU Cost
Coste de uso de CPU por el operador. Este número debe ser el menor posible.
Estimated I/O Cost
Coste de toda la actividad de I/O realizada por el operador. Este número debe ser el menor posible.
Estimated Operator Cost
Coste para el optimizador de consultas al ejecutar esta operación. Muestra entre paréntesis el porcentaje total del coste del operador en relación a todo el plan.
Estimated Number of Executions
Estimación del número de veces que el operador será ejecutado en el plan.
Estimated Number of Rows
Estimación del número de filas que el operador devolverá.
Estimated Row Size
Media estimada del tamaño del registro (en bytes) leido por el operador.
Estimated SubTree Cost
Suma del coste de todos los operadores ejecutados antes de este operador.
En definitiva, estimar la selectividad de WHERE, JOIN y HAVING
Muy útil la lectura http://blogs.technet.com/b/dataplatforminsider/archive/2014/03/17/the-new-and-improved-cardinality-estimator-in-sql-server-2014.aspx
Infravalorar el nº de filas
Usar plan en serie cuando debería ser paralelo
Operadores join inapropiados
Uso de índice inadecuado (seek vs scan)
Sobrevalorar nº de filas
Seleccionar plan paralelo cuando debe ser serie
Operadores join inapropiados
Uso de índice inadecuado (scan vs seek)
Sobre dimensionar requerimientos ram