Uso de vistas indizadas para aumentar el rendimiento de una base de datos

07.12.2013 12:07
 

El uso de vistas indizadas es un recurso que puede aumentar en un porcentaje importante el rendimiento de una base de datos, veamos un ejemplo:

Supongamos que tenemos que optimizar esta query, lanzada sobre la base de datos AdventureWorksDW2012:

select productkey, spanishproductname,DimProduct.ProductSubcategoryKey, SpanishProductsubCategoryName,DimProductSubcategory .ProductcategoryKey,SpanishProductCategoryName

from dbo.DimProduct

inner join DimProductSubcategory on dimproduct.ProductSubcategoryKey=DimProductSubcategory.ProductSubcategoryKey

inner join DimProductCategory on DimProductSubcategory .ProductcategoryKey = DimProductCategory .ProductCategoryKey

Veamos ahora su plan de ejecución:

Tabla 'Worktable'. Recuento de exámenes 0, lecturas lógicas 0, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas de LOB 0, lecturas físicas de LOB 0, lecturas anticipadas de LOB 0.

Tabla 'DimProduct'. Recuento de exámenes 1, lecturas lógicas 477, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas de LOB 0, lecturas físicas de LOB 0, lecturas anticipadas de LOB 0.

Tabla 'DimProductSubcategory'. Recuento de exámenes 1, lecturas lógicas 2, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas de LOB 0, lecturas físicas de LOB 0, lecturas anticipadas de LOB 0.

Tabla 'DimProductCategory'. Recuento de exámenes 1, lecturas lógicas 2, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas de LOB 0, lecturas físicas de LOB 0, lecturas anticipadas de LOB 0.

Tiempos de ejecución de SQL Server:Tiempo de CPU = 0 ms, tiempo transcurrido = 290 ms.

Vemos ahora que el tiempo de ejecucion es de 290 ms y se han producido 477 lecturas lógicas en la tabla DimProduct.

Creamos una vista indizada con la opción schemabinding y creamos un indice sobre ella: 

create view dbo.vproductkey with schemabinding

 

as select productkey, spanishproductname,DimProduct.ProductSubcategoryKey, SpanishProductsubCategoryName,DimProductSubcategory .ProductcategoryKey,SpanishProductCategoryName

 

from dbo.DimProduct

 

inner join dbo.DimProductSubcategory on dimproduct.ProductSubcategoryKey=DimProductSubcategory.ProductSubcategoryKey

 

inner join dbo.DimProductCategory on DimProductSubcategory .ProductcategoryKey = DimProductCategory .ProductCategoryKey

go

create unique clustered index ixvprodctkey on dbo.vproductkey (productkey,ProductSubcategoryKey,ProductcategoryKey)

y el plan de ejecución resultante:


 

Tabla 'Worktable'. Recuento de exámenes 0, lecturas lógicas 0, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas de LOB 0, lecturas físicas de LOB 0, lecturas anticipadas de LOB 0.

Tabla 'DimProduct'. Recuento de exámenes 1, lecturas lógicas 477, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas de LOB 0, lecturas físicas de LOB 0, lecturas anticipadas de LOB 0.

Tabla 'DimProductSubcategory'. Recuento de exámenes 1, lecturas lógicas 2, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas de LOB 0, lecturas físicas de LOB 0, lecturas anticipadas de LOB 0.

Tabla 'DimProductCategory'. Recuento de exámenes 1, lecturas lógicas 2, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas de LOB 0, lecturas físicas de LOB 0, lecturas anticipadas de LOB 0.

(1 filas afectadas)

 Tiempos de ejecución de SQL Server:

Tiempo de CPU = 0 ms, tiempo transcurrido = 148 ms.


 

hemos conseguido reducir el tiempo de ejecucion a la mitad, pero el plan de ejecución sigue siendo el mismo. Vamos a ver si podemos mejorarlo:


 

Ejecutamos lo siguiente:

select * from dbo.vproductkey with(noexpand)

y voilà!


 

Tabla 'vproductkey'. Recuento de exámenes 1, lecturas lógicas 9, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas de LOB 0, lecturas físicas de LOB 0, lecturas anticipadas de LOB 0.

(1 filas afectadas)

 Tiempos de ejecución de SQL Server:

 Tiempo de CPU = 0 ms, tiempo transcurrido = 95 ms
 


 

Ahora si hemos reducido el tiempo de ejecución considerablemente y el plan de ejecución realiza un index seek 100%.Además hemos reducido las lecturas lógicas a 9!!

La clave está en la clausula NOEXPAND

NOEXPAND sólo se aplica a las vistas indizadas. Como ya hemos visto una vista indizada es una vista con un índice agrupado único creado en él. Si una consulta contiene referencias a columnas que estén presentes tanto en una vista indizada y en tablas de base, y el optimizador de consultas determina que el uso de la vista indizada ofrece el mejor método para ejecutar la consulta, el optimizador de consultas utiliza el índice de la vista. Esta funcionalidad se denomina coincidencia de vista indizada. El uso automático de una vista indizada por el optimizador de consultas sólo se admite en las ediciones específicas de SQL Server. Para obtener una lista de características que son compatibles con las ediciones de SQL Server, vea Características compatibles con las ediciones de SQL Server 2012.

Sin embargo, para que el optimizador considere el uso de las vistas indizadas  o utilice una vista indizada que se referencia con una sugerencia NOEXPAND, las siguientes opciones SET deben establecerse en ON.

ANSI_NULLS ANSI_WARNINGS CONCAT_NULL_YIELDS_NULL
ANSI_PADDING ARITHABORT1 QUOTED_IDENTIFIERS

SQL Server

SQL SERVER 2016 con polybase

19.03.2016 18:24
Con polybase, se puede acceder a los datos en clústeres de almacenamiento Hadoop o Azure Blob, utilizando las mismas características de SQL Server que se usan  con datos relacionales,  creación de estadísticas, aplicación de tecnologías de almacén de columnas, aprovechamiento de...

Búsquedas con Full text search o Lucene.net

13.12.2014 20:25
Sql Server incorpora un buscador propio full text cuya ventaja principal es la búsqueda simultánea en varios campos de texto  de una misma tabla, no obstante, presenta algunos problemas en cuanto a rendimiento cuando es imprescindible que las búsquedas se realicen instantáneamente, o en...

Comparativa de rendimiento en funciones de agregado para datawarehouses II

06.04.2014 21:22
Viene de: https://francescsanchezbi.webnode.es/news/comparativa-de-rendimiento-en-funciones-de-agregado-para-datawarehouses/Una vez tenemos la tabla vamos a realizar una query con las window function, que nos permiten agrupar agregados por distintos campos, a diferenciadel group by:Probaremos una...

Comparativa de rendimiento en funciones de agregado para datawarehouses I

05.04.2014 21:34
Es frecuente, cuando estamos preparando un datawarehose, que nos interese guardar en un archivo los datos de una gran variedad de campos jerárquicos agrupados, tales como count, sumas, promedios etc, para cada  registro de una tabla. Tabla 1.Supongamos, segun el ejemplo anterior, que...

Mejora de rendimiento de un slow changing dimension mediante programacion Tsql

01.03.2014 22:53
El componente Slow changing dimensión se utiliza para la actualización y el mantenimiento de datawarehouses a tavés  de la inserción selectiva de registros en las tablas de dimensiones de almacenamiento de datos. La transformación Dimensión de variación lenta proporciona la siguiente...

Creacion de Datawarehouse desde sql dinámico y BIML

23.02.2014 19:22
Siguiendo los últimos artículos publicados sobre el lenguaje dinamico de generación de paquetes SSIS presentamos esta utilidad para generar Datawarehouse dinámicamente a través de BIML y sql. Para ello es necesario descargar la utilidad BIML desde la sihuiente...

Uso de Hadoop en Sql Server con PDW y Polybase

01.02.2014 17:03
Como se ilustra en la figura, el objetivo del proyecto polybase es permitir a los usuarios de SQL Server PDW ejecutar consultas en los datos almacenados en Hadoop, específicamente en el sistema de archivos distribuidos Hadoop (HDFS). Polybase es polivalente en tanto el tipo de cluster Hadoop...

Indexación de variables Tabla en Sql Server

15.01.2014 15:50
Una de las principales características de las variables table frente a las tablas temporales, es que al ser declaradas en lugar de ser creadas no generan estadisticas ni histogramas al no generar tampoco un plan de ejecución como una tabla temporal o normal.   Su ventaja es que al ser un...

Mejora de rendimiento de NOT EXISTS vs NOT IN

09.01.2014 17:56
El uso de la instrucción  NOT IN  suele ser mas frecuente que el de NOT EXISTS. Aunque a simple vista pueden parecer equivalentes no es asi en muchas ocasiones. Veamos un ejemplo:   Tenemos 2 querys que dan los mismos resultados utilizando ambas instrucciones sobre la base de datos...

Compresión de datos en SQL Server 2012

06.01.2014 19:39
Con la explosión de datos que se ha producido en la industria y la empresa, más y más datos se almacenan en SQL Server. Sin embargo, las bases de datos ya no son de un promedio de 100 GB en  tamaño como lo eran hace 10 años. Ahora las bases de datos son más grande que nunca, con tamaños de 10...
1 | 2 >>