Planes de ejecución con SQL Server III, planes de ejecución gráficos

Los planes de ejecución nos ayudarán a escribir código SQL eficiente, solucionar problemas de SQL o monitorear e informar sobre nuestros sistemas.
Aquí se pueden consultar las dos partes previas:

Planes de ejecución con SQL Server I

Planes de ejecución con SQL Server II

Permisos requeridos para ver los planes de ejecución

Para generar planes de ejecución de consultas es necesario tener los permisos necesarios dentro de la base de datos. El administrador de base de datos tendrá generalmente todos los permisos pero para dar permisos a cualquier usuario se puede ejecutar.

GRANT SHOWPLAN TO [nombre de usuario]

Esta acción permitirá a un usuario ver los planes de ejecución para la base de datos.

Trabajar con los planes de ejecución gráficos

Comenzaremos con una de las consultas más simples posibles,

SELECT * FROM dbo.tbNombretabla

Ver el plan estimado

Vamos a ver el plan de ejecución estimado en forma gráfica que ha generado el optimizador de consultas.
Es posible averiguar la estimación del plan más óptimo calculada por el optimizador de una delas siguientes maneras, primero hay que seleccionar la consulta a analizar y después:

• Hacer clic en el icono plan de ejecución estimado en la barra de herramientas.

Planes de ejecución con SQL Server II

Planes estimado y real de ejecución

Como se mencionó en la primera parte de Planes de Ejecución con SQL Server, hay dos tipos distintos de plan de ejecución. En primer lugar, existe el plan que representa la salida del optimizador. Es el plan de ejecución estimado. Corresponde con una primera estimación del optimizador y no representan la ejecución real cuando se ejecute la consulta física.
El siguiente es el plan que representa la salida real de la ejecución de la consulta. Este tipo de plan es el plan de ejecución real y representa lo que realmente ocurrió cuando se ejecutó la consulta.

Planes de ejecución con SQL Server I

Introducción

A la hora de gestionar las bases de datos el DBA  siempre se plantea el mismo tipo de preguntas:

• ¿Por qué es esta consulta está funcionando tan lentamente?

• Está SQL Server utilizando el índice que he creado?

• ¿Por qué SQL Server no utiliza el índice que he creado?

• ¿Por qué esta consulta se ejecuta más rápido que esta otra?

• Y así sucesivamente.

La respuesta correcta probablemente sea diferente en cada caso, pero siempre hay que hacerse la misma pregunta: ¿He consultado el plan de ejecución?
Los planes de ejecución muestran lo que está pasando detrás de cada actuación de SQL Server. Esto proporciona una gran cantidad de información acerca de cómo SQL Server está ejecutando las consultas, incluyendo los siguientes puntos.

Índices en SQL Server

Qué es un índice

Un índice consiste en una estructura de punteros a registros o grupos de registros asociados a una tabla. Esta estructura contiene claves asociadas a una o varias columnas de la tabla. La organización de estos punteros a los datos se realiza de manera que se reduzcan Ias búsquedas cuando éstas sean necesarias, distingue los diferentes métodos de indexación. Un índice resulta más eficiente cuantas menos comprobaciones sobre la estructura deba realizar para encontrar un registro.

Los registros de la tabla tienen un tamaño fijo y se almacenan en ficheros, de manera que cada registro queda perfectamente determinado por su posición en el fichero. De esta forma los punteros a los datos que se almacenan en los índices no contienen más que la posición de estos registros en el fichero.

SQL Server almacena los índices como un objeto más de la base de datos. Los objetos de SQL Server se almacenan en un modelo orientado a la página y no al registro, la indexación no se lleva a cabo en ese modelo de puntero fijo, en este modo de almacenamiento, los índices se almacenan en páginas separadas, dentro de la misma base de datos.