SQL Server 2016 - Introduction à la base de données extensible

À partir de SQL Server 2016, vous aurez la possibilité de stocker des parties d'une base de données dans le cloud. Cette nouvelle capacité est connue sous le nom de Stretch Database et la fonctionnalité sera bénéfique pour ceux qui ont besoin de conserver des données transactionnelles pendant de longues périodes et ceux qui cherchent à économiser de l'argent sur le stockage. La possibilité de migrer des données de manière transparente vers le cloud Microsoft Azure vous donnera la possibilité d'archiver des données sans avoir à modifier la façon dont vos applications interrogent les données.

Dans SQL Server 2016 Community Technology Preview 2 (CTP2), Stretch Database migre des tables entières. Si votre base de données est déjà configurée pour stocker les données d'archive dans des tables distinctes des données actuelles, vous pourrez facilement migrer les données d'archive vers Azure. Une fois que vous avez activé Stretch Database, vos données seront migrées en silence vers une base de données SQL Azure. Stretch Database exploite la puissance de traitement d'Azure pour exécuter des requêtes sur des données distantes en réécrivant la requête. Vous le verrez comme un opérateur de "requête à distance" dans le plan de requête.

Un moyen simple d'identifier les bases de données et les tables éligibles à l'extension est de télécharger et d'exécuter le conseiller de mise à niveau SQL Server 2016 et d'exécuter le conseiller de base de données Stretch. Aaron Bertrand (@AaronBertrand) a récemment écrit à ce sujet :

• Identifier les tables candidates pour les bases de données Stretch SQL Server 2016

Limites pour Stretch Database

Toutes les tables ne seront pas éligibles pour être activées par Stretch. Certaines propriétés de table, types de données et de colonnes, contraintes et index ne sont pas pris en charge, tels que :

• Tables à mémoire optimisée et répliquées
• Tableaux contenant des données FILESTREAM, utilisez le suivi des modifications ou les données de modification
• Types de données tels que timestamp, sql_variant, XML, géographie ou colonnes toujours chiffrées
• Contraintes de vérification et par défaut ou contraintes de clé étrangère qui référencent la table
• XML, full-text, spatial, clustered columnstore et vues indexées qui font référence à la table extensible
• Vous ne pouvez pas exécuter d'instructions UPDATE ou DELETE, ni exécuter d'opérations CREATE INDEX ou ALTER INDEX sur une table extensible

Pour une liste complète des limitations, vous pouvez visiter :Exigences et limitations pour Stretch Database.

Configuration de la base de données Stretch

La mise en route n'est pas une tâche compliquée. Vous aurez besoin d'un compte Azure, puis activez Stretch Database sur l'instance.

Pour activer Stretch Database sur une instance exécutée :

EXEC sys.sp_configure N'remote data archive', '1';
RECONFIGURE;
GO

Pour cette démo, je vais utiliser la base de données AdventureWorks2014 sur une instance SQL Server 2016 CPT2. Je vais commencer par créer un nouveau tableau :

USE [AdventureWorks2014];
GO
 
CREATE TABLE dbo.StretchTest
(
  FirstName VARCHAR(50),
  LastName  VARCHAR(50)
);
GO

Et puis je remplirai la table de test StretchTest avec quelques données :

USE [AdventureWorks2014];
GO
 
INSERT INTO dbo.StretchTest(FirstName, LastName)
VALUES('Paul', 'Randal'),  ('Kimberly', 'Tripp'),('Jonathan', 'Kehayias'),
      ('Erin', 'Stellato'),('Glenn', 'Berry'),   ('Tim', 'Radney');
GO

J'ai maintenant une table que je peux étendre au Microsoft Azure Cloud. Pour ce faire, je vais utiliser l'interface graphique en cliquant avec le bouton droit sur AdventureWorks2014, en choisissant Tâches et en sélectionnant Activer la base de données pour Stretch.

L'assistant Activer la base de données pour l'étirement s'ouvrira, comme ci-dessous :

Je clique sur suivant :

Et connectez-vous à mon compte Microsoft Azure :

Je suis ensuite invité à vérifier quel compte je souhaite utiliser :

Ensuite, je sélectionne l'emplacement Azure que je souhaite utiliser et je spécifie un identifiant et un mot de passe administrateur. Lorsque vous faites cela, assurez-vous de noter le nom d'utilisateur et le mot de passe de l'administrateur, car vous en aurez besoin à l'avenir pour vous reconnecter à Azure SQL Database si vous devez restaurer la base de données.

Je clique ensuite sur suivant :

Et cliquez sur Terminer et la base de données commence à s'approvisionner sur Azure SQL Database Server.

Je viens de créer une définition de serveur lié sécurisé sur mon serveur local qui a la base de données Azure SQL distante comme point de terminaison. Je peux voir cela dans les objets serveur, les serveurs liés ainsi que dans mon compte Azure sous bases de données SQL. Notez que seuls les processus système peuvent utiliser ce serveur lié; les connexions utilisateur ne peuvent pas émettre de requêtes via le serveur lié vers le point de terminaison distant.

Maintenant que Stretch Database est activé pour l'instance et pour la base de données AdventureWorks2014, je peux maintenant étirer ma nouvelle table. Pour étendre la table vers Azure, je dois modifier la table et activer l'archivage de données à distance.

USE [AdventureWorks2014];
GO
 
ALTER TABLE [StretchTest]
ENABLE REMOTE_DATA_ARCHIVE WITH ( MIGRATION_STATE = ON );
GO

En plus des nouvelles fonctionnalités avec SQL Server 2016, il existe également de nouveaux DMV. Pour surveiller la migration des données vers Azure, vous pouvez interroger sys.dm_db_rda_migration_status. Lorsque j'ai interrogé le DMV après avoir activé l'archivage de données à distance, j'ai pu voir que les 6 lignes avaient été migrées :

Sauvegarde et restauration d'une base de données Stretch

Actuellement, dans SQL Server 2016 CTP2, lorsqu'une base de données extensible est sauvegardée, une sauvegarde superficielle est créée qui n'inclut pas les données qui ont été migrées vers la base de données Azure SQL. Il est prévu qu'avec la version RTM de SQL Server 2016, la sauvegarde d'une base de données extensible créera une sauvegarde approfondie qui contiendra à la fois des données locales et étirées.

Lors de la restauration d'une base de données extensible, vous devrez reconnecter la base de données locale à la base de données Azure SQL distante. Pour ce faire, exécutez la procédure stockée sys.sp_reauthorize_remote_data_archive en tant que db_owner.

Si je sauvegarde maintenant la base de données AdventureWorks2014 extensible et que je la restaure, je ne pourrai plus interroger la table StretchTest jusqu'à ce que je me reconnecte à Azure SQL Database en exécutant :

USE [AdventureWorks2014];
GO
 
EXEC sys.sp_reauthorize_remote_data_archive @azure_username, @azure_password;
GO

Une fois reconnecté, je reçois un message similaire à celui ci-dessous, puis je peux à nouveau interroger les données étirées :