Con un título tan rimbombante cualquiera se preguntará acerca de qué voy a escribir, pero claro, en el mismo enunciado aparece una buena pista, mi tan apreciada SQL Server. Mencionar que esta característica está disponible únicamente a partir de la versión 2016 y corriendo sobre máquina Windows.
Una vez terminada la breve introducción, empecemos hablando acerca de qué es SQL Server Stretch y para qué lo podría usar. Pues bien, como sabemos el movimiento al Cloud es un proceso en el que se encuentran inmersas muchas organizaciones. Hasta aquí, nada nuevo salvo en el caso de que tu movimiento a la nube se esté realizando de un modo smooth, en el que convivan recursos tanto en on-prem como en Cloud. Esto suele ser muy habitual por ejemplo en el caso de las bases de datos por lo que muchas veces, hay que buscar fórmulas de sincronización entre ambos mundos para evitar la pérdida de información o desactualización.
Sin duda, hay muchas formas de articular soluciones para manejar apropiadamente esto, pero como hoy quiero presentar SQL Server Stretch, él será nuestro protagonista. Así que, empecemos.
Inicialmente descargaré la base de datos de ejemplo de Adventure Works en su versión ligera, la puedes descargar desde el link. Pero antes de eso, debes conocer la versión del servidor de SQL que dispones, eso se ejecuta con un simple SELECT @@version.
Una vez descargada, procedemos a su «restauración» siguiendo el ejemplo de abajo.

Ya tenemos la base de datos, ahora sólo queda habilitar SQL Server Stretch tanto en el servidor como en las distintas tablas a configurar. Para ello, debemos incluir el siguiente código.
EXEC sp_configure 'remote data archive' , '1';
GO
RECONFIGURE;
GO
Ejecutamos el script y esperamos la respuesta.

El siguiente paso es configurar el servicio de SQL Server Stretch en la base de datos, que en nuestro caso es AdventureWorksLT2016 mediante la ejecución del siguiente SQL script.
USE AdventureWorksLT2016;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD='@12345ñ67/89';
GO

Ahora lo que hay que hacer es crear una nueva credencial para la base de datos de AdventureWorksLT2016 mediante el siguiente script.
CREATE DATABASE SCOPED CREDENTIAL onpremcredentialname
WITH IDENTITY = 'crendentialname', SECRET = 'credential1000'
GO
NOTA: el nombre de la identidad utilizado en la creación de la credencial debe tener permisos de owner en la Azure SQL Database.

Seguimos con la configuración de la Stretch Database, ya sólo quedaría vincular la base de datos on-premise con el servidor de Azure. Esto se realiza mediante el siguiente script.
ALTER DATABASE AdventureWorksLT2016
SET REMOTE_DATA_ARCHIVE = ON
(
SERVER = 'xxxxx.database.windows.net' ,
CREDENTIAL = onpremcredentialname
) ;
GO

Una vez llegados hasta aquí, sólo queda habilitar SQL Server Stretch a nivel de tabla. Para ello, seleccionamos SalesLT.Address. Al quedar seleccionada, pulsamos sobre el botón derecho y nos aparecerá el menú desplegable, ahora sólo tenemos que clicar sobre Stretch y de nuevo sobre Enable.

Al realizar la pulsación nos aparecerá la siguiente pantalla, donde lamentablemente nos indica que no podemos activar la función. ¿Por qué? Pues por que SQL Stretch presenta alguna limitaciones, que pueden ser consultadas aquí.

En nuestro afán de completar el vídeo decidimos crear una nueva tabla con el nombre de SalesLT.Address2 sin las limitaciones previas. Así como incluyendo un mínimo conjunto de datos en ella destacando el campo ModifiedDate que será el que vayamos a utilizar como filtro para mover los datos previos al 1 de agosto de 2021 a nuestra Azure SQL Database.

Para ello volvemos pulsar sobre Stretch y en esta ocasión, la tabla será seleccionable y decidiremos que no vamos a mover toda la tabla a Azure, sino únicamente los datos anteriores a nuestro primero de agosto. Pulsamos sobre Next.

Avanzamos y se nos muestra el sumario, comprobamos que todo es correcto y pulsamos sobre Finish.

Y finalmente se ejecuta el proceso de configuración que se suele tomar su tiempo, esperaremos a que termine.

Conseguido, los datos cool que para nosotros serán aquellos anteriores al primero de agosto de 2021 se moverán a Azure.
Ahora sólo queda comprobar el tiempo empleado en la ejecución de una simple consulta que me devuelva todos los datos de ambas tablas de direcciones. Vemos que la original con 450 registros ubicada 100% on-premise no llega al segundo frente a los casi 4 que tarda en devolver la información de los ocho registros de nuestra Stretch Database. Normal tiene que ir a Azure, coger los cuatro registros migrados y volver para pegarlos con los otros cuatro que se encuentran en on-premise.
Bueno, ya por último para comprobar, vamos a nuestra suscripción de Azure y ahí está nuestra flamante Stretch Database.

Salvando el grave problema de las limitaciones como FK, default values, tipos de campos, índices, etc, para poder ser una tabla seleccionable, el servicio es realmente interesante, puesto que te permite desentenderte de los movimientos de datos. Si bien es cierto que en mi caso prefiero algunas otras formas de mover el cool data, pero para gusto lo colores 😉
Reblogueó esto en El Bruno.
Me gustaMe gusta