Symptômes
Supposons que vous utilisez un groupe de disponibilité Always On Microsoft SQL Server 2014 ou 2016. Si une erreur d’écriture similaire à celle qui suit se produit sur une base de données secondaire, celle-ci peut être suspendue.
Remarque
Error : 17053, Severity : 16, State : 1.
SQLServerLogMgr ::LogWriter : Erreur 6 du système d’exploitation (le handle n’est pas valide.) rencontrée.
Erreur d’écriture lors du vidage du journal.
Dans ce cas, si vous reprenez le déplacement des données, la base de données ne reprend pas et reste dans l’état suspendu.
Solution de contournement
Pour contourner ce problème, vous pouvez redémarrer le SQL Server instance ou supprimer la base de données secondaire du groupe de disponibilité, puis l’ajouter de nouveau.
Résolution
Ce problème est résolu dans la mise à jour cumulative suivante pour SQL Server :
Mise à jour cumulative CU 38 pour SQL Server 2016 RTM
Mise à jour cumulative 5 pour SQL Server 2016 CU5
Mise à jour cumulative 6 pour SQL Server 2014 SP2
À propos des mises à jour cumulatives pour SQL Server :
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs logiciels et tous les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :
Dernière mise à jour cumulative pour SQL Server 2016
Dernière mise à jour cumulative pour SQL Server 2014
Remarque
Après avoir installé cette mise à jour, si ce problème se reproduit, vous pouvez exécuter la commande Transact-SQL suivante pour redémarrer la base de données, puis reprendre le déplacement des données pour la base de données.
ALTER DATABASE <database_name> SET HADR RESUME
Ce n’est pas automatisé. Par conséquent, vous devez lancer manuellement l’opération de reprise. Étant donné que la plupart des types d’erreurs qui entraînent la suspension des mouvements de données sur la réplica secondaire nécessitent une intervention manuelle.
Par exemple, si le fichier journal se trouve dans un dossier partagé ou est stocké dans Microsoft Azure Blob et que la connexion est perdue, l’erreur 17053 se produit. L’intervention manuelle permet de s’assurer que la connexion au dossier partagé ou au blob Azure est restaurée avant d’émettre la commande de reprise HADR.
État
Microsoft a confirmé qu’il s’agissait d’un problème dans les produits Microsoft répertoriés dans la section « S’applique à ».
Références
En savoir plus à propos de la terminologie utilisée par Microsoft pour décrire les mises à jour logicielles.