Blog gratis
Reportar
Editar
¡Crea tu blog!
Compartir
¡Sorpréndeme!
img
img

 

 

SQL Server
Blog. (Apuntes y Recopilaciones) por Norman M. Pardell

img
img

Query Optimizer. Correlated Columns. Columnas Relacionadas. SQL Server. Tema: IV

 Un punto importante en el uso de estadísticas, que comentare en este Tema: IV, es la relación que puede existir entre las columnas que nosotros definimos en una consulta.

 

  Es aconsejable para el buen entendimiento de este “Tema:IV” que se lea o repase los enlaces: Query Optimizer. Parameter Sniffing. SQL Server. Tema: I y el enlace: Query Optimizer. Cardinality Estimation Error. SQL Server. Tema: II

 

 En SQL Server, cuando tenemos una expresión, por ejemplo, con dos predicados:

 

SELECT * FROM Table WHERE Modelo = ‘Z’ AND Color = ‘Verde’

 

 

 Como ya hemos comentado en anteriores “Temas”, el Optimizador de Consultas consulta las estadísticas, haciendo estimaciones de registros a devolver, para intentar construir el mejor Plan de Ejecución posible para las consulta. De aquí que se aconseje trabajar con las estadísticas y de tener actualizadas las mismas. Para asumir cual es el número estimado de registros a devolver, SQL Server, estima cada uno de los predicados (Modelo = ‘Z’   y   Color = ‘Verde’) por separado. Es decir, SQL Server, interpretará cada predicado como un conjunto por separado y lo que nosotros queremos es el resultado de la intersección entre los dos conjuntos.  Exactamente lo que hace, es calcular por un lado el número estimado de registros a devolver para el primer predicado: SELECT * FROM Table WHERE Modelo = ‘Z’, supongamos que es 50, y luego calculará el número estimado de registros a devolver para el segundo predicado: SELECT * FROM Table WHERE Color = ‘Verde’, supongamos que son 73. Si por ejemplo la tabla tuviese 361 registros, el Optimizador de consultas estimará  el número de registros a devolver para: SELECT * FROM Table WHERE Modelo = ‘Z’ AND Color = ‘Verde’, con el resultado de la operación para este caso: (50 * 73)/361, lo que nos dará un número estimado de 10.110803 registros. (así es como funciona por defecto el Optimizador de consultas).

 

 Pero van a existir algunos casos, en que los datos de los campos que están en el predicado (WHERE) estén relacionados y no se pueda hacer una intersección (multiplicación), ya que daría un mal número estimado de registros a devolver. Por ejemplo para el caso anterior, si suponemos que todos los Modelo = ‘Z’ son de Color = ‘Verde’, el Optimizador realizará una mala estimación de los registros a devolver, ya que no es capaz de diferenciar estos casos o similares… Para estos casos tenemos dos opciones para solucionar esto:

 

  • Filtered Statistics (Usar estadísticas que tiene un filtro o una condición, solo están disponibles desde la versión SQL Server 2008.)

  • Multi-column Statistics (Opción disponible en todas las versiones de SQL Server, desde la versión 7.)

 La mejor solución para nuestro ejemplo, sería utilizar Filtered Statistics (estadísticas con filtro), pero el principal problema es que solo esta disponible en versiones muy recientes, si no tenemos la versión SQL Server 2008 o superior, nosotros podremos usar Multi-column Statistics, básicamente es crear estadísticas en los campos que necesitamos, en nuestro caso: Modelo  y  Color.

 

 Un detalle a mencionar es que SQL Server, crea estadísticas automáticamente de una columna, nunca va a crear estadísticas automáticamente de 2 o mas columnas, esto último lo tenemos que hacer nosotros.

 

 Par nuestro caso las crearíamos de la forma (Multi-column Statistics):

 

CREATE STATISTICS multicolumn_tatistics ON Table (Modelo, Color)

 

 Nota.- Si vais a realizar pruebas… no olvideis de limpiar de memoria los planes de ejecución (DBCC FREEPROCCACHE), para que no rehusé los creados con anterioridad.

 

 Si sacamos ahora nuestro plan de ejecución, veremos que el número estimado de registros es mucho mejor, después de crear Multi-column Statistics, pero recordar que es mucho mejor usar Filtered Statistics.

 

 Cuando trabajamos con Multi-column Statistics el Optimizador no usará el histograma de las estadísticas, entonces usara valores generales de las estadísticas, estos valores se llaman Densidad.

 

 Para eliminar nuestra Multi-column Statistics, lo haremos de la forma:

 

DROP STATISTICS Table.multicolumn_tatistics

 

 Una vez que está eliminada, voy a mostrar como haríamos con estadísticas filtradas:

 

 Cuando creemos estadísticas, en versión SQL Server 2008 o superior, podemos indicar una condición, para nuestro caso solo para los valores ‘Z’ en el campo Modelo. Lo crearíamos de la forma:

 

CREATE STATISTICS filtered_statistics ON Table (Color) Where Modelo = ‘Z’

 

 

Nota.- Si vais a realizar pruebas… no olvideis de limpiar de memoria los planes de ejecución (DBCC FREEPROCCACHE), para que no rehusé los creados con anterioridad.

 

 De esta forma el Optimizador obtendría el mejor número de registros estimados, para crear los panes de ejecución.

 

 Otro detalle, es que lo mas probable, se necesiten crear nuevos filtros para distintos Modelos, esta opción es buena o recomendada, cuando se dá que tenemos pocos subconjuntos (para nuestro caso de Modelo):

 

CREATE STATISTICS filtered_statistics2 ON Table (Color) Where Modelo = ‘Y’

CREATE STATISTICS filtered_statistics3 ON Table (Color) Where Modelo = ‘U’

 

  Para mostraros, como el Otimizador se SQL, se basa en el histograma de las estadísticas, podéis ejecutar:

 

DBCC SHOW_STATISTICS (Table, filtered_statistics)

 

 Podemos ver cual es la expresión que se utilizo en el filtro y también, que es lo interesante, cada conjunto de estadísticas tiene su histograma:


Se aconseja leer: Actualización de estadísticas síncronas o asíncronas mejoran la respuesta del optimizador de consultas. SQL Server 

 

 

 

Fuentes:

Microsoft, MSDN, Benjamin Nevares

Apunte y recopilación por Norman M. Pardell

Puedes consultarme, si deseas cualquier aclaración, pregunta o sugerencia en: Contacto, contestaré tan pronto como me sea posible.

 

 

publicado por normanmpardell a las 19:13 · Sin comentarios  ·  Recomendar
Comentarios (0) ·  Enviar comentario
Esta entrada no admite comentarios.
img
.Sobre mí
FOTO

Norman M. Pardell

MCITP: Database Administrator & Database Developer, SQL Server 2008. MCC Award Certificate. Consultor Senior de bases de datos en Capgemini España, S.L. Asesoramiento en implementación, desarrollo y gestión de bases de datos en grandes compañías. Actualmente, asignado a proyecto en compañía líder en el sector energético global. Más de 10 años trabajando con SQL Server (y otros gestores de BBDD)

» Ver perfil

img
.Secciones
» Inicio
img
.Enlaces
» Microsoft MSDN Foros
» Windows Server 2012
img
.Más leídos
» Asignar la cantidad correcta de Memoria para SQL Server
» Base de Datos Sospechosa (Suspect)
» Como modificar la Intercalación (Collation) en SQL Server
» Detectar bloqueos. SQL Server V.2005 y superiores
» Funciones SQL Server. Funciones escalares y funciones con valores de tabla.
» Integridad y corrupción en las bases de datos: DBCC CHECKDB
» Log de transacciones ( .ldf ). SQL Server.
» Migrando SQL Server 2005, 2008, 2008 R2 a SQL Server 2012
» Tomo I. Memoria RAM. Optimización de sistemas de 32 y 64 bits. SQL Server 2008.
» Transacciones activas. SQL server 2008
img
.Nube de tags [?]
                                                           
img img
FULLServices Network | Crear blog | Privacidad