Vue d’ensemble de la fonctionnalité de liaison des meilleures pratiques - Azure SQL Managed Instance
S’applique à : 
Azure SQL Managed Instance
Cet article décrit les meilleures pratiques à adopter lors de l’utilisation de la fonctionnalité de liaison pour Azure SQL Managed Instance. La fonctionnalité de liaison pour Azure SQL Managed Instance connecte vos serveurs SQL hébergés partout dans SQL Managed Instance, permettant une réplication des données en quasi-temps réel vers le cloud.
Notes
Certaines fonctionnalités de la liaison sont en disponibilité générale, tandis que d’autres sont en préversion. Passez en revue les prérequis pour en savoir plus.
Effectuer régulièrement des sauvegardes de fichiers journaux
Si SQL Server est votre principal initial, il est important d’effectuer la première sauvegarde de fichier journal sur SQL Server une fois l’amorçage initial terminé, lorsque la base de données n’est plus dans l’état Restauration... sur Azure SQL Managed Instance. Prenez ensuite régulièrement les sauvegardes du journal des transactions SQL Server pour maintenir une taille de fichier journal de transactions saine pendant que SQL Server est dans le rôle principal.
La fonction de liaison réplique les données à l’aide de la technologie des groupes de disponibilité distribués basée sur les groupes de disponibilité Always On. La réplication des données avec des groupes de disponibilité distribués est basée sur la réplication des enregistrements du journal des transactions. Aucun enregistrement du journal des transactions ne peut être tronqué de la base de données de l’instance principale SQL Server tant qu’il n’a pas été répliqué dans la base de données du réplica secondaire. Si la réplication des enregistrements du journal des transactions est lente ou bloquée en raison de problèmes de connexion réseau, le fichier journal continue de se développer sur l’instance principale. La vitesse de développement dépend de l’intensité de la charge de travail et de la vitesse du réseau. En cas de défaillance prolongée de la connexion réseau et de charge de travail élevée sur l’instance principale, le fichier journal peut occuper tout l’espace de stockage disponible.
L’utilisation de sauvegardes régulières du journal des transactions tronque le journal des transactions et réduit le risque d’épuisement de l’espace sur l’instance SQL Server principale en raison de la croissance du fichier d’historique. Aucune action supplémentaire n’est nécessaire lorsque la SQL Managed Instance est la principale puisque les sauvegardes de journaux d’activité sont déjà effectuées automatiquement. En effectuant régulièrement des sauvegardes de fichier journal sur votre SQL Server principal, vous rendez votre base de données plus résistante aux événements imprévus de croissance de journaux d’activité. Envisagez de planifier des tâches quotidiennes de sauvegarde de fichier journal à l’aide d’une tâche SQL Server Agent.
Vous pouvez utiliser un script Transact-SQL (T-SQL) pour sauvegarder le fichier journal, tel que l’exemple fourni dans cette section. Remplacez les espaces réservés dans l’exemple de script par le nom de votre base de données, le nom et le chemin d’accès du fichier de sauvegarde, ainsi que la description.
Pour sauvegarder votre journal des transactions, utilisez l’exemple suivant de script Transact-SQL (T-SQL) sur SQL Server :
-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1
La commande Transact-SQL (T-SQL) suivante permet de vérifier l’espacement du journal utilisé par votre base de données sur SQL Server :
-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);
Le résultat de la requête ressemble à l’exemple suivant pour un exemple de base de données tpcc :
Dans cet exemple, la base de données a utilisé 76 % du journal disponible, avec un fichier journal d’une taille absolue d’environ 27 Go (27 971 Mo). Les seuils d’action peuvent varier en fonction de votre charge de travail. Dans l’exemple précédent, la taille du journal des transactions et le pourcentage d’utilisation du journal indiquent généralement que vous devez effectuer une sauvegarde du journal des transactions pour tronquer le fichier journal et libérer de l’espace, ou vous devez effectuer des sauvegardes de journal plus fréquentes. Il peut également s’agir d’une indication du blocage de la troncation du journal des transactions par les transactions ouvertes. Pour plus d’informations sur la résolution des problèmes liés à un journal des transactions dans SQL Server, consultez Résoudre les problèmes liés à la saturation du journal des transactions (erreur 9002 SQL Server). Pour en savoir plus sur la résolution des problèmes d’un journal des transactions dans Azure SQL Managed Instance, consultez Résolution des erreurs du journal des transactions dans Azure SQL Managed Instance.
Remarque
Lorsque vous participez à un lien, les sauvegardes de journal des transactions et complètes automatisées sont extraites de SQL Managed Instance, qu’il s’agisse du réplica principal ou non. Les sauvegardes différentielles ne sont pas effectuées. Cela peut entraîner des temps de restauration plus longs.
Mettre en correspondance la capacité d’analyse des performances entre les réplicas
Lorsque vous utilisez la fonctionnalité de liaison, il est important de faire correspondre la capacité d’analyse des performances entre SQL Server et SQL Managed Instance pour éviter les problèmes d’analyse des performances si le réplica secondaire ne peut pas suivre la réplication à partir du réplica principal ou après le basculement. La capacité d’analyse des performances inclut les cœurs d’UC (ou vCores dans Azure), la mémoire et le débit d’E/S.
Vous pouvez vérifier l’analyse des performances de la réplication avec la taille de file d’attente de restauration par progression sur le réplica secondaire. La taille de la file d’attente de restauration par progression indique le nombre d’enregistrements de journal en attente d’être restaurés sur le réplica secondaire. Une taille de file d’attente de restauration par progression élevée indique que le réplica secondaire ne peut pas suivre le réplica principal. Vous pouvez vérifier la taille de la file d’attente restauration par progression de la manière suivante :
- Valeur
redo_queue_sizedans la vue de gestion dynamique sys.dm_hadr_database_replica_states sur le réplica principal. - La valeur
InstanceRedoLagReplicationSecondsdans Get-AzSqlInstanceLink sur le réplica principal.
Si la taille de file d’attente de restauration par progression est constamment élevée, envisagez d’augmenter les ressources sur le réplica secondaire.
Effectuer une rotation du certificat
Il est possible que le certificat que vous utilisez pour sécuriser le point de terminaison de mise en miroir de bases de données expire, ce qui peut entraîner la dégradation de la liaison. Pour éviter ce problème, faites pivoter le certificat avant son expiration.
Utilisez la commande Transact-SQL (T-SQL) suivante pour vérifier la date d’expiration du certificat en cours :
-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'
Si votre certificat est sur le point d’expirer ou a déjà expiré, vous pouvez créer un nouveau certificat, puis modifier le point de terminaison existant pour remplacer le certificat en cours.
Une fois le point de terminaison configuré pour utiliser le nouveau certificat, vous pouvez exclure le certificat expiré.
Ajouter des indicateurs de trace de démarrage
Dans SQL Server, il existe deux indicateurs de trace (-T1800 et -T9567) qui, lorsqu’ils sont ajoutés comme paramètres de start-up, peuvent optimiser les performances de la réplication des données via la liaison. Pour en savoir plus, consultez Activer les indicateurs de trace de démarrage.