Au fil du temps, de plus en plus d'entreprises migrent vers, ou du moins évaluent, Azure SQL Database comme alternative au coût élevé de l'exécution de SQL Server sur site.
Vérifier la compatibilité
L'un des premiers aspects du déplacement de votre base de données vers Azure SQL Database consiste à vérifier la compatibilité et Microsoft vous propose de nombreuses façons de procéder pour Azure SQL Database V12 (ci-après simplement « V12 »). L'une de ces méthodes utilise SQL Server Data Tools pour Visual Studio (SSDT) qui utilise les règles de compatibilité les plus récentes pour détecter les incompatibilités V12. Dans SSDT, vous pouvez importer votre schéma de base de données et créer un projet pour un déploiement V12. Si des incompatibilités sont détectées, elles peuvent être corrigées dans SSDT, puis synchronisées avec la base de données source.
Vous pouvez également utiliser un outil de ligne de commande appelé SqlPackage qui peut générer un rapport sur les problèmes de compatibilité (et assurez-vous toujours que vous disposez de la dernière version). SQL Server Management Studio est une autre façon de procéder, en utilisant la fonctionnalité Exporter l'application de la couche Données, qui peut détecter et signaler les erreurs à l'écran. Si aucune erreur n'est détectée, vous pouvez alors migrer votre base de données vers la V12. Si des incompatibilités sont détectées, elles peuvent être corrigées à l'aide de SSMS avant la migration.
L'assistant de migration de données est un outil autonome (facilement confondu avec l'assistant de migration SQL Server) qui peut être utilisé pour aider à réduire l'effort de mise à niveau et remplace l'aperçu du conseiller de mise à niveau SQL Server 2016. DMA peut également recommander des améliorations de performances et de fiabilité. Un autre outil, SQL Azure Migration Wizard (SAMW), est un outil Codeplex qui utilise les règles de compatibilité Azure SQL Database V11 pour détecter les incompatibilités V12. SAMW peut également terminer la migration vers la V12 et résoudre certains problèmes de compatibilité. Une chose à savoir lors de l'utilisation de SAMW est qu'il peut détecter des incompatibilités qui n'ont pas besoin d'être corrigées.
Migrer des données
Une fois que votre base de données a passé le contrôle de compatibilité, vous devez déterminer la meilleure méthode de migration. Certaines des méthodes les plus courantes incluent l'utilisation de l'assistant de migration SSMS, l'exportation vers un BACPAC, l'utilisation de la réplication transactionnelle ou le scriptage manuel des bases de données et l'insertion de vos données.
L'utilisation de l'assistant de migration SSMS est idéale pour les bases de données SQL Server 2005 et ultérieures de petite à moyenne taille. Vous pouvez activer cet assistant dans SSMS 2016, en cliquant avec le bouton droit sur une base de données, en choisissant Tâches, puis en déployant la base de données sur la base de données Microsoft Azure SQL. Dans SSMS 2014, cela s'appelle Déployer la base de données sur la base de données SQL Windows Azure. L'utilisation de cet assistant vous permet de spécifier la base de données à migrer, de vous connecter à votre abonnement Azure, de choisir l'emplacement du fichier .bacpac, le nouveau nom de la base de données et le niveau vers lequel migrer. Lorsque vous cliquez sur Terminer, l'assistant extrait et valide le schéma, puis exporte les données. Une fois les données exportées, il créera un plan de déploiement et commencera à importer les données dans la nouvelle base de données V12.
Très similaire à l'assistant de migration SSMS est l'application Export Data-tier. Pour sélectionner cette option, cliquez avec le bouton droit sur la base de données, choisissez Tâches, puis Exporter l'application de la couche Données. Dans les paramètres d'exportation, vous spécifiez où vous souhaitez créer le fichier .bacpac. Vous pouvez l'enregistrer localement ou l'enregistrer directement sur votre compte de stockage Azure. Il existe également un onglet avancé dans lequel vous pouvez sélectionner les tables à inclure. Ceci est utile si votre base de données locale contient des copies de tables que vous ne souhaitez pas migrer vers la V12. Lorsque vous choisissez Terminer, vos données seront exportées. Vous pouvez ensuite vous connecter à votre serveur Azure via SSMS et choisir d'importer l'application de la couche Données. Vous spécifierez l'emplacement du fichier, le nom de la base de données et le niveau de la base de données Azure SQL. Lorsque vous choisissez Terminer, la base de données commencera l'importation. Cette méthode vous donne un peu plus de contrôle sur le processus car elle sépare l'exportation de l'importation. Il vous donne également la possibilité de stocker le fichier .bacpac dans votre compte de stockage Azure afin que le processus d'importation plus vulnérable ne dépende pas de votre connexion Internet.
Une option lors de l'utilisation de l'assistant de migration SSMS ou de l'application Export Data-tier consiste à créer une machine virtuelle Azure avec SQL Server et à configurer l'envoi de journaux. Cela préparera votre base de données dans le cloud Azure pour aider à minimiser le temps d'importation de la base de données. Lorsque vient le temps d'effectuer la migration, il vous suffit de restaurer les sauvegardes finales du journal sur le secondaire, puis de supprimer l'envoi de journaux. Pour mettre la base de données en ligne, effectuez une restauration avec récupération. Cela éliminera essentiellement le temps nécessaire pour copier votre base de données de votre centre de données vers le centre de données Azure.
La réplication transactionnelle est une autre méthode permettant de réduire le temps d'arrêt de la migration vers la V12. C'est la meilleure option si vous avez une fenêtre de maintenance extrêmement petite pour passer à la V12, si la base de données peut prendre en charge la réplication transactionnelle. La configuration de la réplication transactionnelle nécessite des clés primaires pour chaque table publiée, ce qui peut être problématique pour de nombreuses bases de données. La configuration de la réplication transactionnelle peut également être compliquée, car vous devez configurer la base de données de distribution, configurer l'éditeur et l'abonné, et surveiller les travaux.
Vous pouvez également migrer manuellement à l'aide de l'assistant Générer des scripts et créer des scripts pour le schéma et/ou les données de la base de données. Vous pouvez ensuite créer une base de données vide dans Azure et importer votre schéma et/ou vos données en exécutant le script. J'ai entendu parler de certaines personnes utilisant cette méthode pour créer la base de données vide, puis insérant manuellement leurs données une table à la fois à l'aide de SSMS et d'un serveur lié. Cette méthode peut fonctionner pour vous, mais elle peut aussi être très compliquée si vous avez beaucoup de constructions de schéma comme des relations de clé étrangère et des colonnes d'identité, auquel cas les autres méthodes ci-dessus seraient plus fiables et efficaces.
Autres considérations relatives à la migration
Lors de la planification de la migration des bases de données sur site vers la V12, la taille de la base de données est un facteur déterminant dans la durée de la migration. L'exportation de la base de données, le transfert des données et l'importation augmenteront tous proportionnellement à la taille de la base de données.
Un autre facteur important dans le temps de restauration/importation lors du déplacement de vos bases de données vers V12 est le niveau de performance que vous restaurez également. Le processus de restauration/importation nécessite beaucoup de puissance, donc pour accélérer votre migration, vous devriez envisager de restaurer à un niveau de performance plus élevé. Lorsque la base de données est en ligne, vous pouvez facilement et rapidement passer à un niveau inférieur qui répond à vos besoins de performances quotidiens. La possibilité de modifier les niveaux de performances en quelques clics de souris est l'un des principaux avantages d'Azure SQL Database.
Surveillance
Une partie importante de l'administration de toute base de données est la surveillance. Si vous ne surveillez pas quelque chose, vous ne pouvez pas le mesurer. Si vous ne savez pas quelles sont vos mesures lorsque les choses fonctionnent normalement, comment saurez-vous quelles sont les pires choses lorsque les performances se dégradent ? Avec les bases de données sur site, nous avons des outils que nous connaissons :SQL Server Management Studio, Performance Monitor, Task Manager, DMV, etc. Lorsque nous déplaçons nos bases de données vers la V12, nous perdons la capacité de surveiller du point de vue du système d'exploitation, et d'autres concepts changent également un peu. Nous avons maintenant cette métrique appelée DTU avec laquelle travailler, qui signifie Database Transaction Units. Considérez-le comme une combinaison de CPU, d'E/S de données et de journaux de transactions, et de mémoire. Le portail Azure inclut un graphique de surveillance dont le pourcentage de DTU est vérifié par défaut, et vous pouvez modifier ce graphique pour inclure des métriques supplémentaires, telles que :
- Bloqué par le pare-feu
- % CPU
- Limite DTU
- DTU utilisé
- % d'E/S de données
- Taille de la base de données %
- Interblocages
- Échec des connexions
- Pourcentage de stockage OLTP en mémoire
(préversion)
- Log I/O %
- Sessions %
- Connexions réussies
- Taille totale de la base de données
- Travailleurs %
Au minimum, j'ajouterais le pourcentage de CPU, le pourcentage d'E/S de données, les blocages et le pourcentage de taille de la base de données. Actuellement, ce graphique affiche l'heure précédente d'utilisation des ressources.
La surveillance par les DMV n'a pas beaucoup changé, à part quelques nouveaux DMV liés aux métriques de base de données individuelles et à la façon de calculer la taille de la base de données. L'un de mes articles précédents ici, Getting Started Tuning Performance in Azure SQL Database, couvre certaines des différences dans les scripts courants utilisés pour collecter les latences de disque et les statistiques d'attente par rapport à Azure SQL Database.
Des outils tiers ont également commencé à inclure des hooks dans Azure SQL Database, tels que SentryOne avec DB Sentry. DB Sentry vous permet de surveiller les performances et de gérer les événements qui se produisent dans votre système. Une fonctionnalité intéressante est la fonction Top SQL qui vous permet de voir les requêtes qui ont le plus d'impact sur vos performances globales afin que vous puissiez régler/résoudre tous les problèmes avec cette requête. Une autre consiste à tracer le DTU au fil du temps et à le visualiser sur un tableau de bord aux côtés d'autres mesures importantes.
 Top SQL dans le client SentryOne |  Utilisation des DTU sur le tableau de bord DB Sentry |
Ces métriques sont stockées dans une base de données dédiée, vous offrant la possibilité de référencer et de suivre les tendances des performances au fil du temps, ce qui est bien meilleur que les graphiques limités que vous obtenez actuellement dans le portail Azure.
Résumé
La migration vers Azure SQL Database V12 présente de nombreux avantages. Si votre base de données est compatible, profitez donc de l'un des outils disponibles pour vérifier votre compatibilité avec V12. Si votre base de données est compatible ou peut être facilement modifiée pour devenir compatible, vous pouvez facilement migrer vers Azure SQL Database V12 et commencer à tester et à comparer vos applications et vos charges de travail.
