En août 2015, j'ai écrit un article présentant la nouvelle fonctionnalité Stretch Database dans SQL Server 2016. Dans cet article, j'ai expliqué comment démarrer avec Stretch Database dans SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 est sorti le 1er juin 2016 et de nombreuses mises à jour ont été apportées au produit. La méthode de configuration de Stretch Database a légèrement changé ainsi que certaines fonctionnalités.
À partir de SQL Server 2016, nous avons acquis la possibilité de stocker des parties d'une base de données dans une base de données Azure SQL. Dans les aperçus précédents, lorsque vous activiez Stretch pour une base de données, vous deviez migrer la table entière, avec la version RTM de SQL Server 2016, vous pouvez désormais choisir une partie d'une table. Une fois que vous avez activé l'étirement pour une table, celle-ci migre silencieusement vos données. Si vous n'êtes pas familier avec Stretch Database, il exploite la puissance de traitement d'Azure pour exécuter des requêtes sur les données distantes en réécrivant la requête. Vous n'avez pas à réécrire les requêtes de votre côté. 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 écrit à ce sujet il y a quelque temps. Le conseiller de mise à niveau a légèrement changé depuis le message d'Aaron, mais le processus est essentiellement le même :
- 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 répliquées et optimisées en mémoire
- Tableaux contenant des données FILESTREAM, utilisant le suivi des modifications ou la capture des données modifiées
- Types de données tels que timestamp, sql_variant, XML ou géographie
- Vérifier ou contraintes par défaut
- Contraintes de clé étrangère faisant référence à la table
- Index XML, de texte intégral, spatiaux ou groupés ColumnStore
- Vues indexées faisant référence à la table
- 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 de la version RTM est un peu différente des aperçus précédents. Vous aurez besoin d'un compte Azure, puis vous devrez activer Stretch Database sur l'instance locale.
Pour activer Stretch Database sur une instance, exécutez :
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Pour cette démo, je vais utiliser un exemple de base de données que j'ai créé et appelé STRETCH. J'ai commencé par cliquer avec le bouton droit sur la base de données, en choisissant Tâches, Étirer, puis j'ai choisi Activer. Cela utilisait SQL Server 2016 Management Studio.
L'écran suivant vous propose les tableaux que vous souhaitez activer pour Stretch :
J'ai choisi la table SALES2. L'assistant utilise par défaut "Table entière", mais vous pouvez également modifier cette option pour migrer un sous-ensemble de lignes.
Si vous choisissez par lignes, vous devez sélectionner un nom pour vos critères, puis vous pouvez choisir la colonne à utiliser dans votre instruction where, ainsi que la condition et la valeur. Dans cette capture d'écran, j'ai choisi des lignes antérieures à 2016. Pouvoir choisir une partie d'un tableau est une énorme amélioration par rapport aux aperçus précédents, qui vous permettaient uniquement d'étirer le tableau entier. Pour plus de simplicité, dans cette démo, je vais migrer toute la table, j'ai donc cliqué sur Annuler, puis sur Suivant.
Une fois que vous avez sélectionné vos tables et conditions, vous devez choisir l'abonnement Azure que vous allez utiliser, votre région Azure et les informations de votre serveur.
Une fois que vous avez saisi les informations requises, cliquez sur Suivant.
Une nouvelle amélioration utilise la clé principale de la base de données pour protéger les informations d'identification Azure pour se connecter à Azure. Si vous n'avez pas encore de clé principale, vous serez invité à en créer une, si vous en avez déjà une, vous devrez fournir le mot de passe. Cliquez sur Suivant.
Vous devrez créer une règle de pare-feu pour votre serveur ou saisir une plage d'adresses IP de sous-réseau. Faites votre sélection et cliquez sur Suivant.
C'est là que les choses ont vraiment changé et me feront reconsidérer l'utilisation de cette fonctionnalité. Microsoft a créé une Database Stretch Unit (DSU) afin que vous puissiez augmenter ou réduire le niveau de performances dont vous avez besoin pour les données Stretch. Depuis juin 2016, la tarification actuelle est facturée à la fois pour le calcul et le stockage, ce que vous voyez représenté dans l'image ci-dessus. Pour ma table de 15 Mo qui a été migrée, je serais facturé 61 USD par mois pour le stockage, ainsi que le niveau minimum DSU (100) à 912,50 USD par mois. Les niveaux de DSU vont de :
| Niveau DSU | Coût horaire | Coût mensuel max (mois de 31 jours) |
|---|---|---|
| 100 | 1,25 USD | 930 $ |
| 200 | 2,50 $ | 1 860 $ |
| 300 | 3,75 $ | 2 790 $ |
| 400 | 5,00 $ | 3 720 USD |
| 500 | 6,25 $ | 4 650 USD |
| 600 | 7,50 $ | 5 580 $ |
| 1 000 | 12,50 $ | 9 300 $ |
| 1200 | 15,00 $ | 11 160 $ |
| 1500 | 18,75 $ | 13 950 $ |
| 2 000 | 25,00 $ | 18 600 $ |
Pourquoi l'assistant m'a-t-il indiqué seulement 912,50 $, alors que la grille tarifaire indique qu'il devrait être de 900 $ pour juin (ou calculé au prorata en fonction du nombre de jours restants en juin) ? Votre supposition est aussi bonne que la mienne; J'ai essayé divers trucs mathématiques et je n'ai rien trouvé. Vous pouvez en savoir plus sur les modèles de tarification ici :
- Tarification de la base de données SQL Server Stretch
Avant d'en savoir plus sur cette nouvelle méthode de facturation pour DSU, je pouvais faire valoir que l'utilisation de Stretch Database serait une méthode très rentable pour stocker des données froides (données inutilisées) dans le cloud. En étendant ces données dans Azure, vous pourriez migrer une grande partie des données plus anciennes, ce qui réduirait la taille (et donc le coût) de vos sauvegardes locales. Dans le cas où vous deviez restaurer une base de données, vous n'auriez qu'à établir la connexion à Azure pour les données étirées, éliminant ainsi le besoin de les restaurer. Cependant, avec un coût minimal de près de 1 000 USD par mois pour l'échelle DSU bas de gamme, de nombreuses organisations trouveront qu'il est beaucoup moins cher de conserver les données sur un niveau de stockage moins coûteux au sein de leur centre de données et de trouver d'autres méthodes pour HA telles que mise en miroir, envoi de journaux ou groupes de disponibilité.
Cliquez sur Terminer pour commencer la migration.
Félicitations, j'ai maintenant migré la table SALES2 vers une Azure SQL Database
Désactiver un tableau extensible
Dans les premiers aperçus de Stretch Database, si vous vouliez désactiver une table Stretch, vous deviez créer une nouvelle table et y insérer les données Stretch. Une fois que toutes les données ont été copiées, vous devez soit désactiver manuellement les tables en les renommant, soit fusionner manuellement les données étirées dans la table de production. Avec la version RTM, vous pouvez toujours gérer manuellement la migration, choisir de laisser les données dans Azure ou choisir une option pour ramener les données d'Azure.
Quelle que soit la méthode que vous utilisez pour récupérer les données, des frais de transfert de données vous seront facturés.
Sauvegarde et restauration d'une base de données Stretch
Une fois que vous avez migré des données dans une base de données Stretch, Azure gère la sauvegarde des données Stretch. Les sauvegardes se produisent avec un instantané pris toutes les 8 heures et les instantanés sont conservés pendant 7 jours. Cela vous donne jusqu'à 21 points dans le temps au cours des 7 jours précédents pour restaurer.
Vous n'avez pas à apporter de modifications à vos routines de sauvegarde locales actuelles. Toutes les sauvegardes locales effectuées contiendront toutes les données locales et les données éligibles qui n'ont pas encore été migrées. Ceci est appelé une sauvegarde superficielle et ne contient aucune donnée déjà migrée vers Azure.
DBCC CHECKDB
Vous ne pouvez pas non plus exécuter CHECKDB sur des données qui ont été migrées vers Azure.
Lorsque j'ai exécuté DBCC CHECKDB sur ma base de données STRETCH avant la migration, j'ai obtenu les résultats suivants pour la table SALES2 :
Résultats DBCC pour 'SALES2'.Il y a 45860 lignes dans 1901 pages pour l'objet "SALES2".
Après la migration, j'ai reçu la sortie suivante pour la table SALES2 (c'est moi qui souligne) :
Résultats DBCC pour 'SALES2'.Il y a 0 lignes dans 1901 pages pour l'objet "SALES2".
Vous pouvez exécuter DBCC CHECKDB sur Azure SQL Database, mais en raison de l'impossibilité de vous connecter directement à la base de données Azure SQL étendue, vous ne pouvez actuellement pas exécuter manuellement DBCC CHECKDB spécifiquement sur les données étendues. Je ne trouve aucune documentation indiquant qu'Azure effectue des vérifications de cohérence par rapport à ces bases de données.
Cela représente un risque important à mon avis.
Résumé
Stretch Database est un moyen simple de migrer des données d'archive vers Microsoft Azure, si votre base de données le prend en charge. Actuellement, dans SQL Server 2016 RTM, il existe de nombreuses limitations concernant les propriétés de table, de données et de colonne, les types de données et de colonne, les contraintes et les index. Si vous n'êtes pas limité par ces limitations, Stretch Database est un moyen simple de migrer des données historiques vers Azure SQL Database pour libérer du stockage local et réduire les temps de restauration de ces bases de données si les dépenses en valent la peine. Vous devez également être à l'aise, du moins pour le moment, avec l'impossibilité d'exécuter DBCC CHECKDB sur les données migrées. La gestion des restaurations sera également un peu plus délicate car il faudra restaurer la connexion entre la base de données SQL Server et la base de données Azure distante.
