En agosto de 2015, escribí un artículo que presentaba la nueva característica de Stretch Database en SQL Server 2016. En ese artículo, expuse cómo comenzar con Stretch Database en SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 se lanzó el 1 de junio de 2016 y ha habido numerosas actualizaciones del producto. El método de configuración de Stretch Database ha cambiado ligeramente, así como algunas de las funciones.
A partir de SQL Server 2016, obtuvimos la capacidad de almacenar partes de una base de datos en Azure SQL Database. En versiones preliminares anteriores, cuando habilitaba Stretch para una base de datos, tenía que migrar toda la tabla; con la versión RTM de SQL Server 2016, ahora puede elegir una parte de una tabla. Una vez que habilite la extensión para una tabla, migrará silenciosamente sus datos. Si no está familiarizado con Stretch Database, aprovecha la capacidad de procesamiento de Azure para ejecutar consultas en los datos remotos reescribiendo la consulta. No tiene que volver a escribir ninguna consulta por su parte. Verá esto como un operador de "consulta remota" en el plan de consulta.
Una manera fácil de identificar bases de datos y tablas que son elegibles para la habilitación de Stretch es descargar y ejecutar el Asesor de actualización de SQL Server 2016 y ejecutar el Asesor de base de datos Stretch. Aaron Bertrand (@AaronBertrand) escribió sobre esto hace un tiempo. El Asesor de actualizaciones ha cambiado ligeramente desde la publicación de Aaron, sin embargo, el proceso es prácticamente el mismo:
- Identificar tablas candidatas para bases de datos extendidas de SQL Server 2016
Limitaciones para la base de datos ampliada
No todas las mesas serán elegibles para habilitar Stretch. Ciertas propiedades de tabla, tipos de datos y columnas, restricciones e índices no son compatibles, como:
- Tablas duplicadas y optimizadas para memoria
- Tablas que contienen datos de FILESTREAM, utilice Change Tracking o Change Data Capture
- Tipos de datos como marca de tiempo, sql_variant, XML o geografía
- Restricciones de verificación o predeterminadas
- Restricciones de clave externa que hacen referencia a la tabla
- Índices de almacén de columnas XML, de texto completo, espaciales o agrupados
- Vistas indexadas que hacen referencia a la tabla
- No puede ejecutar instrucciones UPDATE o DELETE, o ejecutar operaciones CREATE INDEX o ALTER INDEX en una tabla habilitada para Stretch
Para obtener una lista completa de limitaciones, puede visitar:Requisitos y limitaciones para Stretch Database.
Configuración de base de datos ampliada
Comenzar con el lanzamiento de RTM es un poco diferente a las vistas previas anteriores. Necesitará una cuenta de Azure y luego debe habilitar Stretch Database en la instancia local.
Para habilitar Stretch Database en una instancia, ejecute:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Para esta demostración, usaré una base de datos de muestra que he creado llamada STRETCH. Empecé haciendo clic derecho en la base de datos, eligiendo Tareas, Estirar y luego elegí Habilitar. Esto estaba usando SQL Server 2016 Management Studio.
La siguiente pantalla le ofrece qué tablas le gustaría habilitar para Stretch:
Elegí la tabla SALES2. El asistente tiene como valor predeterminado "Toda la tabla", pero también puede cambiar esa opción para migrar un subconjunto de filas.
Si elige por filas, debe seleccionar un nombre para sus criterios y luego puede elegir qué columna usar en su instrucción where, así como la condición y el valor. En esta captura de pantalla, elegí filas anteriores a 2016. Poder elegir una parte de una tabla es una gran mejora con respecto a las vistas previas anteriores, que solo permitían estirar toda la tabla. Para simplificar, en esta demostración voy a migrar toda la tabla, así que hice clic en Cancelar y luego en Siguiente.
Una vez que haya seleccionado sus tablas y condiciones, debe elegir qué suscripción de Azure va a utilizar, su región de Azure y la información de su servidor.
Una vez que haya ingresado la información requerida, haga clic en Siguiente.
Una nueva mejora es usar la clave maestra de la base de datos para proteger las credenciales de Azure para conectarse a Azure. Si aún no tiene una clave maestra, se le pedirá que cree una, si ya tiene una, deberá proporcionar la contraseña. Haga clic en Siguiente.
Deberá crear una regla de firewall para su servidor, o puede ingresar un rango de IP de subred. Haga su selección y haga clic en Siguiente.
Aquí es donde las cosas realmente han cambiado y me harán reconsiderar el uso de esta función. Microsoft ha creado una unidad de extensión de base de datos (DSU) para que pueda escalar hacia arriba o hacia abajo el nivel de rendimiento que necesita para los datos de extensión. A partir de junio de 2016, los precios actuales se facturan tanto para el procesamiento como para el almacenamiento, que se ven representados en la imagen de arriba. Para mi tabla de 15 MB que se migró, se me cobraría $ 61 USD por mes por almacenamiento, así como el nivel mínimo de DSU (100) a $ 912.50 por mes. Los niveles de DSU van desde:
| Nivel de DSU | Coste por hora | Coste mensual máximo (meses con 31 días) |
|---|---|---|
| 100 | $1.25 | $930 |
| 200 | $2.50 | $1,860 |
| 300 | $3.75 | $2,790 |
| 400 | $5.00 | $3,720 |
| 500 | $6.25 | $4,650 |
| 600 | $7.50 | $5,580 |
| 1000 | $12.50 | $9,300 |
| 1200 | $15.00 | $11,160 |
| 1500 | $18.75 | $13,950 |
| 2000 | $25.00 | $18,600 |
¿Por qué el asistente me dijo solo $ 912.50, cuando la hoja de precios indica que debería ser $ 900 para junio (o prorrateado en función de cuántos días quedan en junio)? Tu invitado es tan bueno como el mío; Probé varias cosas de matemáticas y me quedé en blanco. Puede obtener más información sobre los modelos de precios aquí:
- Precio de la base de datos ampliada de SQL Server
Antes de conocer este nuevo método de facturación para DSU, podría argumentar que usar Stretch Database sería un método muy rentable para almacenar datos fríos (datos no utilizados) en la nube. Al expandir estos datos a Azure, podría migrar una gran parte de los datos más antiguos, lo que reduciría el tamaño (y, por lo tanto, el costo) de sus copias de seguridad locales. En caso de que tuviera que restaurar una base de datos, simplemente tendría que establecer la conexión a Azure para los datos extendidos, eliminando así la necesidad de restaurarla. Sin embargo, dado que el costo mínimo es de casi $1,000 por mes para la escala DSU de gama baja, muchas organizaciones encontrarán que es mucho más económico retener los datos en un nivel de almacenamiento menos costoso dentro de su centro de datos y encontrar otros métodos para HA como duplicación, trasvase de registros o grupos de disponibilidad.
Haga clic en Finalizar para comenzar la migración.
Felicitaciones, ahora he migrado la tabla SALES2 a una base de datos Azure SQL
Deshabilitar una tabla de estiramiento
En las primeras vistas previas de Stretch Database, si quería deshabilitar una tabla Stretch, tendría que crear una nueva tabla e insertar los datos de estiramiento en ella. Una vez que se copiaron todos los datos, tendría que cambiar manualmente las tablas renombrándolas o fusionar manualmente los datos extendidos nuevamente en la tabla de producción. Con el lanzamiento de RTM, aún puede manejar la migración manualmente, elegir dejar los datos en Azure o elegir una opción para recuperar los datos de Azure.
Independientemente del método que utilice para recuperar los datos, incurre en cargos por transferencia de datos.
Copia de seguridad y restauración de una base de datos ampliada
Una vez que migra los datos a una base de datos Stretch, Azure se encarga de la copia de seguridad de los datos Stretch. Las copias de seguridad se realizan con una instantánea tomada cada 8 horas y las instantáneas se mantienen durante 7 días. Esto le da hasta 21 puntos en el tiempo durante los 7 días anteriores para restaurar.
No tiene que realizar ningún cambio en sus rutinas de copia de seguridad locales actuales. Todas las copias de seguridad locales realizadas contendrán todos los datos locales y los datos elegibles que aún no se hayan migrado. Esto se conoce como una copia de seguridad superficial y no contiene datos que ya se hayan migrado a Azure.
DBCC CHECKDB
Tampoco puede ejecutar CHECKDB en datos que se han migrado a Azure.
Cuando ejecuté DBCC CHECKDB en mi base de datos STRETCH antes de la migración, obtuve los siguientes resultados para la tabla SALES2:
Resultados DBCC para 'VENTAS2'.Hay 45860 filas en 1901 páginas para el objeto "VENTAS2".
Después de la migración, recibí el siguiente resultado para la tabla SALES2 (énfasis mío):
Resultados de DBCC para 'SALES2'.Hay 0 filas en 1901 páginas para el objeto "VENTAS2".
Puede ejecutar DBCC CHECKDB en Azure SQL Database; sin embargo, debido a que no puede conectarse directamente a la base de datos Azure SQL ampliada, actualmente no puede ejecutar manualmente DBCC CHECKDB en los datos ampliados específicamente. No puedo encontrar ninguna documentación que indique que Azure está realizando comprobaciones de coherencia en estas bases de datos.
Esto plantea un riesgo significativo en mi opinión.
Resumen
Stretch Database es una manera fácil de migrar datos de archivo a Microsoft Azure, si su base de datos lo admite. Actualmente, en SQL Server 2016 RTM existen muchas limitaciones con las propiedades de tablas, datos y columnas, tipos de datos y columnas, restricciones e índices. Si no está restringido por esas limitaciones, Stretch Database es una forma sencilla de migrar datos históricos a Azure SQL Database para liberar almacenamiento local y reducir los tiempos de restauración de esas bases de datos si el gasto lo justifica. También debe sentirse cómodo, al menos por ahora, sin poder ejecutar DBCC CHECKDB contra los datos migrados. Administrar las restauraciones también será un poco más complicado al tener que restaurar la conexión entre la base de datos de SQL Server y la base de datos remota de Azure.
