Como leer planes de ejecución 2 de Diciembre 2015 (8 am GMT -5)
Enrique Catala
Resumen:
Todo el mundo que trabaja con base de datos siempre se
ha preguntado alguna vez qué son los planes de
ejecución y como se leen. Saber leer un plan de ejecución
nos va a dar información valiosísima de cara a mejorar el
rendimiento de una consulta. En esta sesión vamos a
centrarnos en aprender a leer T-SQL para interpretar lo
que está haciendo SQL Server para devolvernos la
información.
Está por comenzar:
Moderador: Jose Rivera
MVP , Mentor SolidQ
ecatala@solidq.com
www.solidq.com
Twitter:@enriquecatala
www.enriquecatala.com
Agenda
Repaso rápido
• Generación de planes
• Procesamiento lógico
• Operadores join
• Operadore exchange
Demos!
Planes de ejecución
¿Sabemos interpretarlos?
3
Optimizador de
consultas
Sentencia SQL Plan de ejecución
Mágia
Generación de plan de ejecución
El optimizador utiliza dos tipos de clave
• Tiempo E/S: Coste de leer páginas de un subsistema de
disco
• Tiempo CPU: Coste de aplicar predicados y tuplas en
memoria
Estimación de costes
Generación de plan de ejecución
En cada join, se incrementa exponencialmente el nº de soluciones
posibles
Cuidado con el timeout!
Visualizar plan de ejecución
SELECT *
FROM dbo.Pedidos p
INNER JOIN dbo.Items i
ON p.ID_Pedido = i.ID_Pedido
INNER JOIN dbo.Clientes c
ON p.ID_Cliente = c.ID_Cliente
INNER JOIN dbo.Produtos p
ON i.ID_Produto = p.ID_Produto
Para no Clikear
presionar CTRL-L
Operadores
¿Qué son?
7
Casi todo operador funciona pidiendo filas
de uno o mas hijos y devolviéndolas al que
se las ha pedido
•Caso especial
• Common Table Spool
• Operadores columnares
Cada operador devuelve de 1 fila en 1 fila
• *No todos
Planes de ejecución
Flechas
8
¿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
Planes de ejecución
Comparar planes
9
Fíjate en los % de consulta
Operadores join
Nested loops
10
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
Operadores join
Merge join
11
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
}
Operadores join
Hash join
12
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)
}
EQ_ROWS = Cantidad de líneas que poseen el último valor de la muestra
Ej: Existen 64 líneas para la mostra 111 (línea 5)
DISTINCT_RANGE_ROWS = Cantidad de valores distintos dentro de un intervalo. El
valor de RANGE_HI_KEY está EXCLUIDO
Ej: En la línea 5 (108 hasta 110) tenemos 3 valores distintos
Debería llamarse DISTINCT_RANGE_VALUES
AVG_RANGE_ROWS = Media de valores en el rango (RANGE_ROWS/ DISTINCT_RANGE_ROWS)
Ej: En la linea 5 tenemos 160 / 3 = 53,33333
RANGE_HI_KEY = Valor clave de cada muestra
Ej: En la línea 5 tenemos el valor 111 que va de 108 (107 (Línea 4)
+ 1) hasta 111
RANGE_ROWS = Cantidad de líneas que poseen valores iguales a los de la muestra
excluyendo el valor de RANGE_HI_KEY
Ej: La línea 5 va de 108 a 110 (excluyendo el valor
111(RANGE_HI_KEY)). Dentro de este rango tenemos 160 líneas
El valor buscado (110) está entre las líneas 4 y
5
SELECT *
FROM Items1
WHERE Quantity = 110
DBCC SHOW_STATISTICS (Items1, Stats_Quantity) WITH HISTOGRAM
DBCC SHOW_STATISTICS
DEMO
15
Leamos planes!
Propiedades
Sort
Propiedades
Sort
Propiedades
Key lookup
Procesamiento lógico
De una consulta
19
1. FROM
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
1. Evaluar expresiones
2. Eliminar duplicados
6. ORDER BY
7. OFFSET-FETCH/TOP
Conclusión
20
1. Repasar aspectos fundamentales de operadores
2. Ser capaces de leer los planes de ejecución mas habituales

Como leer planes de ejecución

  • 1.
    Como leer planesde ejecución 2 de Diciembre 2015 (8 am GMT -5) Enrique Catala Resumen: Todo el mundo que trabaja con base de datos siempre se ha preguntado alguna vez qué son los planes de ejecución y como se leen. Saber leer un plan de ejecución nos va a dar información valiosísima de cara a mejorar el rendimiento de una consulta. En esta sesión vamos a centrarnos en aprender a leer T-SQL para interpretar lo que está haciendo SQL Server para devolvernos la información. Está por comenzar: Moderador: Jose Rivera MVP , Mentor SolidQ ecatala@solidq.com www.solidq.com Twitter:@enriquecatala www.enriquecatala.com
  • 2.
    Agenda Repaso rápido • Generaciónde planes • Procesamiento lógico • Operadores join • Operadore exchange Demos!
  • 3.
    Planes de ejecución ¿Sabemosinterpretarlos? 3 Optimizador de consultas Sentencia SQL Plan de ejecución Mágia
  • 4.
    Generación de plande ejecución El optimizador utiliza dos tipos de clave • Tiempo E/S: Coste de leer páginas de un subsistema de disco • Tiempo CPU: Coste de aplicar predicados y tuplas en memoria Estimación de costes
  • 5.
    Generación de plande ejecución En cada join, se incrementa exponencialmente el nº de soluciones posibles Cuidado con el timeout!
  • 6.
    Visualizar plan deejecución SELECT * FROM dbo.Pedidos p INNER JOIN dbo.Items i ON p.ID_Pedido = i.ID_Pedido INNER JOIN dbo.Clientes c ON p.ID_Cliente = c.ID_Cliente INNER JOIN dbo.Produtos p ON i.ID_Produto = p.ID_Produto Para no Clikear presionar CTRL-L
  • 7.
    Operadores ¿Qué son? 7 Casi todooperador funciona pidiendo filas de uno o mas hijos y devolviéndolas al que se las ha pedido •Caso especial • Common Table Spool • Operadores columnares Cada operador devuelve de 1 fila en 1 fila • *No todos
  • 8.
    Planes de ejecución Flechas 8 ¿Vesla 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
  • 9.
    Planes de ejecución Compararplanes 9 Fíjate en los % de consulta
  • 10.
    Operadores join Nested loops 10 foreach 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
  • 11.
    Operadores join Merge join 11 getfirst 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 }
  • 12.
    Operadores join Hash join 12 Ejecuciónen 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) }
  • 13.
    EQ_ROWS = Cantidadde líneas que poseen el último valor de la muestra Ej: Existen 64 líneas para la mostra 111 (línea 5) DISTINCT_RANGE_ROWS = Cantidad de valores distintos dentro de un intervalo. El valor de RANGE_HI_KEY está EXCLUIDO Ej: En la línea 5 (108 hasta 110) tenemos 3 valores distintos Debería llamarse DISTINCT_RANGE_VALUES AVG_RANGE_ROWS = Media de valores en el rango (RANGE_ROWS/ DISTINCT_RANGE_ROWS) Ej: En la linea 5 tenemos 160 / 3 = 53,33333 RANGE_HI_KEY = Valor clave de cada muestra Ej: En la línea 5 tenemos el valor 111 que va de 108 (107 (Línea 4) + 1) hasta 111 RANGE_ROWS = Cantidad de líneas que poseen valores iguales a los de la muestra excluyendo el valor de RANGE_HI_KEY Ej: La línea 5 va de 108 a 110 (excluyendo el valor 111(RANGE_HI_KEY)). Dentro de este rango tenemos 160 líneas El valor buscado (110) está entre las líneas 4 y 5 SELECT * FROM Items1 WHERE Quantity = 110 DBCC SHOW_STATISTICS (Items1, Stats_Quantity) WITH HISTOGRAM DBCC SHOW_STATISTICS
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
    Procesamiento lógico De unaconsulta 19 1. FROM 2. WHERE 3. GROUP BY 4. HAVING 5. SELECT 1. Evaluar expresiones 2. Eliminar duplicados 6. ORDER BY 7. OFFSET-FETCH/TOP
  • 19.
    Conclusión 20 1. Repasar aspectosfundamentales de operadores 2. Ser capaces de leer los planes de ejecución mas habituales

Notas del editor

  • #8 Los operadores de tipo índice columnar y los de tipo Exchange paralelos, que funcionan enviando paquetes de filas
  • #9 Esto es mucho mas frecuente de lo que parece. ¡Actualiza tus estadísticas!
  • #11 Es el operador mas sencillo Es un doble bucle
  • #12 Lee simultáneamente las dos entradas Ambas entradas deben estar ordenadas
  • #13 37’ Si se estima menos memoria para hash, aparecen los temidos hash warnings…
  • #14 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
  • #15 Esto es necesario para entender la demo
  • #17 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.
  • #18 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.
  • #19 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.
  • #20 Esto es importantísimo para entender los planes de ejecución