Análisis de Los Planes de Ejecución en SQL Server

Análisis de los Planes de Ejecución en SQL Server  Guías: Gestión de Soluciones Tecnológicas.

Definición El Plan de Ejecución (Execution Plan) de SQL Server es el resultado de la tarea realizada por el Optimizador de Consultas (Query Optimizer ) al estimar la manera más óptima de ejecutar una consulta T-SQL. El costo estimado es basado por los valores requeridos de CPU, I/O de disco, y Tiempo de ejecución. Las estadísticas de los datos y el costo de los planes estimados, determinan el "mejor" plan a ejecutar.

Execution Plan - SSMS (SQL Server Management Studio)

SET STATISTICS PROFILE ON; go SET STATISTICS PROFILE OFF; go

Tipos de Planes de Ejecución - SSMS

Tipos de Planes de Ejecución - SSMS

Tipos de Planes de Ejecución - Profiler (trazas)

Interpretando el Plan de Ejecución: Table scan, index scan, clustered index scan Causa: Índices inexistentes, o mal uso de estos. Solución: Una operación "scan" no es significado de bajo rendimiento cuando los datos consultados son menos del 6% (<6%) del total de los datos o en términos generales a resultados menores de 500 filas. Si el impacto es considerable, debe implementarse un índice que solucione este inconveniente.

Interpretando el Plan de Ejecución: Alto número de resultados Causa: Mal uso de cláusulas JOINs o falta de condiciones filtro (WHERE). Solución: La consulta debe estar filtrando el conjunto de resultados como paso final en lugar de limitar la extracción de grandes tablas desde el principio de la ejecución. Divida la consulta en varios "pasos" con el uso de tablas temporales que limiten el volumen de información por procesar. Use índices sobre las tablas temporales.

Interpretando el Plan de Ejecución: RID Lookups, Key Lookups Causa: Los datos no están ubicados en el nivel "hoja" del índice, y debe "saltar" (Lookup) y buscarlos. Solución: Este comportamiento no es siempre evitable, ya que solo es posible tener un (1) índice Cluster, tampoco es deseable tener todas las columnas de la tabla en índices No-Cluster. Como alternativa se puede considerar en adicionar estas columnas a los índices ya existentes con la clausula INCLUDE (Conver Index).

Interpretando el Plan de Ejecución: Paralelismo Causa: El volumen de datos procesados supera la "barrera" de ejecución en paralelo configurada en el servidor. Solución: En las máquinas con más de una CPU, SQL Server es capaz de determinar cuando una consulta requiere de más de un procesador para resolverla, sin embargo, se debe entender que no todas las cargas de trabajo se benefician de esta característica. En general, un sistema OLTP debe atender consultas cortas, múltiples clientes/conexiones, y sets de datos reducidos, por lo que NO DEBERÍA HACER USO DE PARALELISMO.

Paralelismo

Interpretando el Plan de Ejecución: Compute Scalar  Causa: JOINs de diferentes tipos de datos con conversión implicita. Solución: Se debe evitar en la medida de lo posible dado su naturaleza de operación FILA-A-FILA de los JOINs lo que causa que se realice una carga de procesamiento intensa. Mueva los datos convertidos previamente a una tabla temporal.

Interpretando el Plan de Ejecución: Nested Loops Causa: JOINs de campos que no tienen índice. Solución: Es el algoritmo de JOIN más costoso y se puede evitar con índices que incluyan estos campos (Covered index).

Referencias ●

Execution Plan Basics. https://www.simple-talk.com/sql/performance/execution-plan-basics/

●

How to Optimize a Stored Procedure using the Execution Plan. http://sqlserverplanet.com/optimization/how-to-optimize-a-storedpr ocedure-using-the-execution-plan

● Parallelism, SQL Server, and you: Round 2 http://www.mikefal.net/tag/maxdop/