Expansión de los usos de DBCC CLONEDATABASE

Service Pack 2 para SQL Server 2014 se lanzó el mes pasado (lea las notas de la versión aquí) e incluye una nueva instrucción DBCC:DBCC CLONEDATABASE . Estaba muy emocionado de ver este comando presentado, ya que proporciona un muy fácil manera de copiar un esquema de base de datos, incluyendo estadísticas , que se puede usar para probar el rendimiento de las consultas sin requerir todo el espacio necesario para los datos en la base de datos. Finalmente hice algo de tiempo para probar DBCC CLONEDATABASE y entiendo las limitaciones, y tengo que decir que fue bastante divertido.

Lo básico

Comencé creando un clon de la base de datos AdventureWorks2014 y ejecutando una consulta en la base de datos de origen y luego en la base de datos clonada:

DBCC CLONEDATABASE (N'AdventureWorks2014', N'AdventureWorks2014_CLONE');
GO
 
SET STATISTICS IO ON;
GO
SET STATISTICS TIME ON;
GO
SET STATISTICS XML ON;
GO
 
USE [AdventureWorks2014];
GO
 
SELECT *
FROM [Sales].[SalesOrderHeader] [h]
JOIN [Sales].[SalesOrderDetail] [d] ON [h].[SalesOrderID] = [d].[SalesOrderID]
ORDER BY [SalesOrderDetailID];
GO
 
USE [AdventureWorks2014_CLONE];
GO
 
SELECT *
FROM [Sales].[SalesOrderHeader] [h]
JOIN [Sales].[SalesOrderDetail] [d] ON [h].[SalesOrderID] = [d].[SalesOrderID]
ORDER BY [SalesOrderDetailID];
GO
 
SET STATISTICS IO OFF;
GO
SET STATISTICS TIME OFF;
GO
SET STATISTICS XML OFF;
GO

Si observo la salida de E/S y TIME, puedo ver que la consulta en la base de datos de origen tomó más tiempo y generó muchas más E/S, las cuales se esperan ya que la base de datos clonada no tiene datos:

/* Base de datos FUENTE */

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

Tiempo de análisis y compilación de SQL Server:
Tiempo de CPU =0 ms, tiempo transcurrido =4 ms.

(121317 filas afectadas)

Tabla 'Encabezado de pedido de ventas'. Recuento de escaneo 0, lecturas lógicas 371567, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.

Mesa 'Mesa de trabajo'. Recuento de escaneo 0, lecturas lógicas 0, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.

Tabla 'Detalle del pedido de venta'. Recuento de escaneos 5, lecturas lógicas 1361, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.

Mesa 'Mesa de trabajo'. Recuento de escaneo 0, lecturas lógicas 0, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.

(1 fila(s) afectada(s))

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

/* CLONAR base de datos */

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

Tiempo de análisis y compilación de SQL Server:
Tiempo de CPU =12 ms, tiempo transcurrido =12 ms.

(0 filas afectadas)

Mesa 'Mesa de Trabajo'. Recuento de escaneo 0, lecturas lógicas 0, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.

Tabla 'Encabezado de pedido de ventas'. Recuento de escaneo 0, lecturas lógicas 0, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.

Tabla 'Detalle del pedido de venta'. Recuento de escaneo 5, lecturas lógicas 0, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.

(1 fila(s) afectada(s))

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

Si observo los planes de ejecución, son los mismos para ambas bases de datos excepto por los valores reales (la cantidad de datos que realmente se movieron a través del plan):

Plan de consulta para la base de datos AdventureWorks2014

Plan de consulta para la base de datos AdventureWorks2014_CLONE

Aquí es donde el valor de DBCC CLONEDATABASE es evidente:puedo obtener una copia vacía de una base de datos para cualquier persona (Soporte de productos de Microsoft, mi compañero DBA, etc.) y hacer que recreen e investiguen un problema, y ​​no necesitan potencialmente cientos de GB de espacio en disco para hacer eso. La publicación del martes de T-SQL de julio de Melissa tiene información detallada sobre lo que sucede durante el proceso de clonación, por lo que recomiendo leerla para obtener más información.

¿Eso es todo?

Pero… ¿puedo hacer más con DBCC CLONEDATABASE? ? Quiero decir, esto es genial, pero creo que hay muchas otras cosas que puedo hacer con una copia vacía de la base de datos. Si lee la documentación de DBCC CLONEDATABASE , verás esta línea:

Mi primer pensamiento fue, "optimizador de consultas - hmm... ¿puedo usar esto como una opción para probar actualizaciones ?”

Bueno, la base de datos clonada es de solo lectura, pero pensé en intentar cambiar algunas opciones de todos modos. Por ejemplo, si pudiera cambiar el modo de compatibilidad, sería genial, ya que podría probar los cambios de CE en SQL Server 2014 y SQL Server 2016.

USE [master];
GO
 
ALTER DATABASE [AdventureWorks2014_CLONE] SET COMPATIBILITY_LEVEL = 110;

Me sale un error:

Hm. ¿Puedo cambiar el modelo de recuperación?

ALTER DATABASE [AdventureWorks2014_CLONE] SET RECOVERY SIMPLE WITH NO_WAIT;

Puedo. Eso no parece justo. Bueno, es de solo lectura, ¿puedo cambiar eso?

ALTER DATABASE [AdventureWorks2014_CLONE] SET READ_WRITE WITH NO_WAIT;

¡SÍ! Antes de que te emociones demasiado, déjame dejarte esta nota de la documentación aquí:

Voy a repetir esta línea de la documentación, ponerla en negrita y ponerla en rojo como amigable pero extremadamente importante recordatorio:

Bueno, por mí está bien, definitivamente no iba a usar esto para producción, ¡pero ahora puedo usarlo para probar! ¡AHORA puedo cambiar el modo de compatibilidad, y AHORA puedo hacer una copia de seguridad y restaurarla en otra instancia para probarla!

USE [master];
GO
 
BACKUP DATABASE [AdventureWorks2014_CLONE]
  TO  DISK = N'C:\Backups\AdventureWorks2014_CLONE.bak'
  WITH INIT, NOFORMAT, STATS = 10, NAME = N'AW2014_CLONE_full';
GO
 
/* restore on SQL Server 2016 */
 
 
RESTORE DATABASE [AdventureWorks2014_CLONE]
FROM  DISK = N'C:\Backups\AdventureWorks2014_CLONE.bak' WITH
MOVE N'AdventureWorks2014_Data' TO N'C:\Databases\AdventureWorks2014_Data_2684624044.mdf',
MOVE N'AdventureWorks2014_Log' TO N'C:\Databases\AdventureWorks2014_Log_3195542593.ldf',
NOUNLOAD,  REPLACE,  STATS = 5;
GO
 
ALTER DATABASE [AdventureWorks2014_CLONE] SET COMPATIBILITY_LEVEL = 130;
GO

ESTO ES GRANDE.

En mi última publicación, hablé sobre la marca de rastreo 2389 y las pruebas con el nuevo Estimador de cardinalidad porque, amigos, ustedes necesitan estar probando con el nuevo CE antes de actualizar. Si no realiza la prueba y cambia el modo de compatibilidad a 120 (SQL Server 2014) o 130 (SQL Server 2016) como parte de su actualización, corre el riesgo de trabajar en un modo de extinción de incendios si se encuentra con regresiones con el nuevo CE. Ahora, podría estar bien y el rendimiento podría ser incluso mejor después de la actualización. Pero… ¿no te gustaría estar seguro?

Muy a menudo, cuando menciono las pruebas antes de una actualización, me dicen que no hay un entorno en el que realizar las pruebas. Sé que algunos de ustedes tienen un entorno de prueba. Algunos de ustedes tienen Test, Dev, QA, UAT y quién sabe qué más. Tienes suerte.

Para aquellos de ustedes que afirman que no tienen ningún entorno de prueba en el que probar, les doy DBCC CLONEDATABASE . Con este comando, no tiene excusa para no ejecutar las consultas ejecutadas con más frecuencia y las más importantes contra un clon de su base de datos. Incluso si no tiene un entorno de prueba, tiene su propia máquina. Realice una copia de seguridad de la base de datos clonada desde producción, suelte la clonación, restaure la copia de seguridad en su instancia local y luego pruebe. La base de datos clonada ocupa muy poco espacio en el disco y no incurrirá en contención de memoria o de E/S ya que no hay datos. Usted lo hará ser capaz de validar los planes de consulta del clon contra los de su base de datos de producción. Además, si restaura en SQL Server 2016, puede incorporar Query Store en sus pruebas. Habilite Query Store, ejecute sus pruebas en el modo de compatibilidad original, luego actualice el modo de compatibilidad y vuelva a realizar la prueba. ¡Puede usar Query Store para comparar consultas una al lado de la otra! (¿Puedes decir que estoy bailando en mi silla ahora mismo?)

Consideraciones

Nuevamente, esto no debería ser nada que usaría en producción, y sé que no lo haría, pero vale la pena repetirlo porque en su estado actual, DBCC CLONEDATABASE no está completamente completo . Esto se indica en el artículo de KB en Objetos admitidos; los objetos como tablas optimizadas para memoria y tablas de archivos no se copian, no se admite el texto completo, etc.

Ahora, la base de datos clonada no está exenta de inconvenientes. Si sin darse cuenta ejecuta una reconstrucción del índice o una actualización de las estadísticas en esa base de datos, acaba de borrar sus datos de prueba. Perderá las estadísticas originales, que es lo que probablemente realmente quería en primer lugar. Por ejemplo, si reviso las estadísticas del índice agrupado en SalesOrderHeader en este momento, obtengo esto:

USE [AdventureWorks2014_CLONE];
GO
DBCC SHOW_STATISTICS (N'Sales.SalesOrderHeader',PK_SalesOrderHeader_SalesOrderID);

Estadísticas originales para SalesOrderHeader

Ahora, si actualizo las estadísticas de esa tabla, obtengo esto:

UPDATE STATISTICS [Sales].[SalesOrderHeader] WITH FULLSCAN;
GO
 
DBCC SHOW_STATISTICS (N'Sales.SalesOrderHeader',PK_SalesOrderHeader_SalesOrderID);

Estadísticas actualizadas (vacías) para SalesOrderHeader

Como medida de seguridad adicional, probablemente sea una buena idea deshabilitar las actualizaciones automáticas de las estadísticas:

USE [master];
GO
ALTER DATABASE [AdventureWorks2014_CLONE] SET AUTO_UPDATE_STATISTICS OFF WITH NO_WAIT;

Si actualiza las estadísticas sin querer, ejecute DBCC CLONEDATABASE y pasar por el proceso de copia de seguridad y restauración no es tan difícil, y lo tendrás automatizado en poco tiempo.

Puede agregar datos a la base de datos. Esto podría ser útil si desea experimentar con estadísticas (por ejemplo, diferentes frecuencias de muestreo, estadísticas filtradas) y tiene suficiente almacenamiento para guardar una copia de los datos de la tabla.

Sin datos en la base de datos, obviamente no obtendrá una duración representativa confiable y datos de E/S. Está bien. Si necesita datos sobre el uso real de los recursos, entonces necesita una copia de su base de datos con todos los datos que contiene. DBCC CLONEDATABASE se trata realmente de probar el rendimiento de las consultas; eso es todo. No es un reemplazo para las pruebas de actualización tradicionales de ninguna manera, pero es una nueva opción para validar cómo SQL Server optimiza una consulta con diferentes versiones y modos de compatibilidad. ¡Feliz prueba!