Symptômes
Partez du principe que vous utilisez le groupe de disponibilité AlwaysOn d’une base de données Microsoft SQL Server 2012 ou SQL Server 2014 et qu’une grande transaction active ouverte existe et que vous avez besoin d’un espace journal supplémentaire. Lorsque le fichier journal ne peut pas augmenter pour l’une des raisons suivantes, la transaction échoue.
-
Espace de fichier supplémentaire manquant
-
Le fichier journal est configuré de manière à ne pas grandir
-
Le fichier journal a atteint sa taille maximale configurée
En outre, le message d'erreur suivant s'affiche :
Erreur : 9002, gravité : 17, État : 9. le journal de transactions de la base de données <le nom de la base de données> 'est plein en raison de « log_backup ».
Après avoir exécuté une sauvegarde du journal, vous recevez un autre message d’erreur 9002 :
Erreur : 9002, gravité : 17, État : 9. le journal de transactions de la base de données <le nom de la base de données> 'est plein en raison de « ACTIVE_TRANSACTION ».
Après une sauvegarde du journal, vous recevez un autre message d’erreur 9002 suivi d’un message d’erreur 5901 :
Erreur : 9002, gravité : 17, État : 9. le journal de transactions de la base de données <le nom de la base de données> 'est plein en raison de « AVAILABILITY_REPLICA ».
Impossible d’écrire un enregistrement de point de contrôle dans la base de données <nom de la base de données>, car le journal est en dehors de l’espace. Contactez l’administrateur de base de données pour tronquer le journal ou allouer plus d’espace aux fichiers journaux de la base de données. Erreur : 5901, gravité : 16, État : 1. au moins une unité de récupération de la base de données « <nom de la base de données> » n’a pas pu générer de point de contrôle. En règle générale, ce problème est dû au manque de ressources système, telles que le disque ou la mémoire, ou dans certains cas de corruption de la base de données. Pour plus d’informations sur cet échec, examinez les entrées précédentes dans le journal des erreurs.
Lorsque les sauvegardes de point de contrôle ou de journal ultérieures sont alors prises lors de la restauration de la transaction, vous pouvez recevoir le message d’erreur suivant :
MSG 3052, niveau 16, état 1, ligne 4BACKUP journal n’a pas pu enregistrer les mises à jour de la base de données <nom de la base de données>». Des sauvegardes de journaux ultérieures seront nécessaires pour faire progresser le point de sauvegarde de' <LSN ID 1> 'à' <lsn ID 2> 'après que l’espace du journal est mis à disposition pour les journaux.
Lorsque vous recevez ces messages, vous n’êtes plus en mesure de transmettre de nouvelles transactions à la base de données, et vous ne pouvez pas agrandir le fichier journal ou ajouter un autre fichier journal.
Résolution
Le problème a été résolu dans la mise à jour cumulative suivante de SQL Server :
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. Nous vous recommandons de télécharger et d’installer les dernières mises à jour cumulatives pour SQL Server :
Solution de contournement
Vous pouvez utiliser la solution de contournement suivante pour tronquer les journaux et les activités de reprise.
-
Vérifiez que les réplicas secondaires vérifient le last_hardened_lsn de réplica secondaire (voir sys.dm_hadr_database_replica_states) correspondant à la last_hardened_lsnde réplica principal. Pour cela, exécutez la requête suivante qui est connectée à l’instance de réplica principal.
SELECT ags.name as AGGroupName, ar.replica_server_name as InstanceName, hars.role_desc, db_name(drs.database_id)as DBName, drs.last_hardened_lsn, drs.log_send_queue_size, drs.synchronization_state_desc as SyncState, ar.availability_mode_desc as SyncMode, CASE drs.is_local WHEN 1 THEN drs.database_id ELSE NULL END as database_id FROM sys.dm_hadr_database_replica_states drs LEFT JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id LEFT JOIN sys.availability_groups ags ON ar.group_id = ags.group_id LEFT JOIN sys.dm_hadr_availability_replica_states hars ON ar.group_id = hars.group_id and ar.replica_id = hars.replica_id WHERE db_name(drs.database_id) = '<database name>'
-
Sur le réplica principal
-
Supprimez la base de données du groupe disponibilité.
-
Rajoutez la base de données dans le groupe disponibilité.
-
-
Sur chaque réplica secondaire
-
Rajoutez la base de données dans le groupe disponibilité.
-
En supprimant la base de données du groupe disponibilité, elle tronque immédiatement ses journaux et libère l’espace journal. Si le last_hardened_lsn de chaque réplica secondaire est identique au réplica principal, et qu’il n’y a pas de sauvegarde du journal lors de la suppression de la base de données du groupe de disponibilité et de l’ajout de la base de données sur chacun d’eux, le réplica secondaire sera de nouveau ajouté sans erreur ou n’aura pas besoin de restaurer les sauvegardes du journal sur le secondaire. S’il n’y a pas de réplica secondaire et que vous devez supprimer la base de données du groupe de disponibilité avant que le secondaire puisse le retrouver, il est possible que le réplica secondaire doive disposer de sauvegardes de journaux restaurées pour le détecter avant de le rajouter au groupe de disponibilité, ou de le réamorcer avec une sauvegarde de la base de données du journal des transactions
Statut
Microsoft a confirmé l’existence de ce problème dans les produits Microsoft répertoriés dans la section « S’applique à ».
