Applies ToSQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2016 Service Pack 1 SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use) SQL Server 2014 Service Pack 2 - duplicate (do not use)

Symptômes

Supposez que vous utilisez un groupe Microsoft SQL Server 2014 ou 2016 toujours disponible (AG). Si une erreur d’écriture qui ressemble à ce qui suit se produit sur une base de données secondaire, il est possible que la base de données soit suspendue.

Erreur : 17053, gravité : 16, État : 1. SQLServerLogMgr :: LogWriter : erreur du système d’exploitation 6 (le handle n’est pas valide.) encountered. Erreur d’écriture lors du vidage du journal.

Dans ce cas, si vous reprenez la migration des données, la base de données n’est pas reprise et elle reste à l’état suspendu.

Solution de contournement

Pour contourner ce problème, vous pouvez redémarrer l’instance SQL Server, ou vous pouvez supprimer la base de données secondaire du groupe disponibilité et l’ajouter à nouveau.

Résolution

Ce problème a été résolu dans la mise à jour cumulative suivante pour SQL Server :

       Mise à jour cumulative 8 pour SQL Server 2016 RTM

       Mise à jour cumulative 5 pour SQL Server 2016 CU5

       Mise à jour cumulative 6 pour SQL Server 2014 SP2

Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs et 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 l’installation de cette mise à jour, si le problème persiste, 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.

MODIFIER <de base de données database_name> définir la reprise de HADR

Cette opération n’est pas automatisée. Par conséquent, vous devez manuellement lancer l’opération de reprise. Comme la plupart des types d’erreurs qui génèrent une suspension des mouvements de données sur le réplica secondaire nécessitent une intervention manuelle. 

Par exemple, si le fichier journal se trouve dans un dossier partagé ou qui est stocké dans un objet BLOB Microsoft Azure et que la connexion est perdue, l’erreur 17053 se produit. L’intervention manuelle vérifie que la connexion au dossier partagé ou à l’objet BLOB Azure est restaurée avant d’exécuter la commande de reprise de HADR.

Statut

Microsoft a confirmé l'existence de ce problème dans les produits Microsoft figurant dans la liste des produits concernés par cet article.

Références

Apprenez-en davantage sur la terminologieutilisée par Microsoft pour décrire les mises à jour logicielles.

Besoin d’aide ?

Vous voulez plus d’options ?

Explorez les avantages de l’abonnement, parcourez les cours de formation, découvrez comment sécuriser votre appareil, etc.

Les communautés vous permettent de poser des questions et d'y répondre, de donner vos commentaires et de bénéficier de l'avis d'experts aux connaissances approfondies.