Facteurs pouvant retarder la troncation du journal
La troncation du journal libère de l'espace dans le fichier journal pour que le journal des transactions puisse le réutiliser. Comme la partie active du journal ne peut pas être tronquée ni supprimée par réduction, la troncation peut être retardée lorsque les enregistrements du journal restent actifs longtemps.
Notes
Pour plus d'informations sur le fonctionnement de la troncation des journaux, consultez Troncation du journal des transactions.
Les enregistrements du journal peuvent rester actifs pour divers motifs qui sont décrits dans cette rubrique. Vous pouvez découvrir les raisons éventuelles qui empêchent de tronquer le journal en utilisant les colonnes log_reuse_wait et log_reuse_wait_desc de l'affichage catalogue sys.databases.
Notes
Certains de ces facteurs, tels qu'une très longue transaction ou la suspension d'une session de mise en miroir de bases de données, peuvent entraîner un remplissage du journal des transactions. Pour plus d'informations sur la marche à suivre en cas de saturation du journal des transactions, consultez Résolution des problèmes en cas de journal des transactions saturé (erreur 9002).
Le tableau suivant décrit sommairement les valeurs des colonnes log_reuse_wait et log_reuse_wait_desc de l'affichage catalogue sys.database.
valeur log_reuse_wait |
valeur log_reuse_wait_desc |
Description |
|---|---|---|
0 |
NOTHING |
Il existe actuellement un ou plusieurs fichiers journaux virtuels réutilisables. |
1 |
CHECKPOINT |
Aucun point de contrôle n'est apparu depuis la dernière troncation du journal ou le début du journal n'est pas encore allé au-delà d'un fichier journal virtuel (tous les modes de récupération). Il s'agit d'une raison classique de retarder la troncation du journal. Pour plus d'informations, consultez Points de contrôle et partie active du journal. |
2 |
LOG_BACKUP |
Une sauvegarde du fichier journal est requise pour faire avancer le début du journal (modes de restauration complète ou de récupération utilisant les journaux de transactions). .gif "Remarque") Remarque
Les sauvegardes du fichier journal n'empêchent pas la troncation.
Lorsque la sauvegarde du fichier journal est terminée, le début du journal est avancé et de l'espace peut devenir réutilisable dans le journal. |
3 |
ACTIVE_BACKUP_OR_RESTORE |
Une sauvegarde de données ou une restauration est en cours (tous les modes de récupération). Une sauvegarde de données fonctionne comme une transaction active et, lorsqu'elle est exécutée, la sauvegarde empêche la troncation. Pour plus d'informations, consultez « Opérations de sauvegarde et de restauration de données », plus loin dans cette rubrique. |
4 |
ACTIVE_TRANSACTION |
Une transaction est active (tous les modes de récupération).
|
5 |
DATABASE_MIRRORING |
La mise en miroir de bases de données est interrompue ou, en mode haute performance, la base de données miroir se trouve derrière la base de données principale de manière significative (mode de restauration complète uniquement). Pour plus d'informations, consultez « Mise en miroir de la base de données et journal des transactions », plus loin dans cette rubrique. |
6 |
REPLICATION |
Durant les réplications transactionnelles, les transactions pertinentes aux publications sont encore non remises à la base de données de distribution (mode de restauration complète uniquement). Pour plus d'informations, consultez « Réplication transactionnelle et journal des transactions », plus loin dans cette rubrique. |
7 |
DATABASE_SNAPSHOT_CREATION |
Un instantané de base de données est en cours de création (tous les modes de récupération). Il s'agit d'une raison classique et habituellement brève du retard de la troncation du journal. |
8 |
LOG_SCAN |
Une analyse de journal est en cours (tous les modes de récupération). Il s'agit d'une raison classique et habituellement brève du retard de la troncation du journal. |
9 |
OTHER_TRANSIENT |
Cette valeur n'est pas utilisée actuellement. |
Opérations de sauvegarde et de restauration de données
La troncation du journal ne peut pas se produire au cours d'une opération de sauvegarde ou de restauration. Dans SQL Server 2005 et versions ultérieures, les sauvegardes du fichier journal peuvent intervenir au cours d'une sauvegarde de données. Toutefois, la troncation du journal ne peut pas intervenir au cours de telles sauvegardes du journal car l'ensemble du journal des transactions doit rester disponible pour l'opération de sauvegarde des données. Si une sauvegarde des données empêche la troncation du journal, l'annulation de la sauvegarde peut résoudre le problème immédiat.
Pour plus d'informations sur la troncation de journaux, consultez Troncation du journal des transactions.
Transactions actives de longue durée
Une transaction active exige que le journal reste actif à partir de l'enregistrement contenant le début de la transaction. Par exemple, si le début et la fin d'une transaction sont contrôlés par l'utilisateur, une raison classique de l'existence d'une transaction de longue durée est qu'un utilisateur a commencé une transaction puis est parti alors que la transaction attend une réponse de l'utilisateur. Dans un cas de ce type, bien que la transaction en attente génère très peu d'entrées de journal, elle empêche la troncation du journal et entraîne ainsi une croissance importante de ce dernier.
Notes
Pour plus d'informations sur la manière d'éviter des transactions de longue durée, consultez Écriture de transactions performantes.
Mise en miroir de la base de données et journal des transactions
La mise en miroir de la base de données exige que chaque enregistrement du journal reste actif tant que l'instance du serveur principal n'a pas reçu une notification provenant de l'instance du serveur miroir, stipulant que l'enregistrement a été écrit sur le disque du serveur miroir. Si l'instance du serveur miroir prend du retard par rapport à l'instance du serveur principal, l'espace du journal actif croît proportionnellement. Dans ce cas, vous pouvez être amené à arrêter la mise en miroir de la base de données, à effectuer une sauvegarde du fichier journal qui tronque le journal, à appliquer cette sauvegarde du fichier journal à la base de données miroir (à l'aide de WITH NORECOVERY) et à redémarrer la mise en miroir.
Important
De plus, avant de démarrer la mise en miroir, si des sauvegardes du fichier journal supplémentaires sont effectuées après la sauvegarde du fichier journal requise, vous devez également appliquer manuellement chacune de ces sauvegardes supplémentaires (toujours à l'aide de WITH NORECOVERY). Une fois la dernière sauvegarde du fichier journal appliquée, vous pouvez démarrer la mise en miroir.
Pour plus d'informations, consultez Suppression d'une mise en miroir des bases de données et Configuration de la mise en miroir d'une base de données.
Réplication transactionnelle et journal des transactions
La réplication de fusion et la réplication de capture instantanée n'affectent pas la taille du journal des transactions, contrairement à la réplication transactionnelle. Si une base de données comprend une ou plusieurs publications transactionnelles, le journal n'est pas tronqué tant que toutes les transactions relatives aux publications n'ont pas été remises à la base de données de distribution. Si la taille du journal des transactions devient trop importante et que l'Agent de lecture du journal s'exécute de manière planifiée, envisagez de réduire l'intervalle entre les exécutions ou de le paramétrer pour qu'il s'exécute en mode continu. S'il est paramétré pour s'exécuter en mode continu (par défaut), vérifiez qu'il fonctionne. Pour plus d'informations sur la vérification de l'état de l'Agent de lecture du journal, consultez Procédure : afficher des informations et effectuer des tâches pour les agents associés à une publication (moniteur de réplication).
De plus, si vous avez défini l'option « sync with backup » sur la base de données de publication ou la base de données de distribution, le journal des transactions n'est pas tronqué tant que toutes les transactions ne sont pas sauvegardées. Si la taille du journal des transactions devient trop importante et que cette option est définie, envisagez de réduire l'intervalle entre les sauvegardes du fichier journal des transactions. Pour plus d'informations sur la sauvegarde et la restauration de bases de données concernées par la réplication transactionnelle, consultez Stratégies de sauvegarde et de restauration de la réplication transactionnelle et de capture instantanée.
Pour gérer la réplication
Pour surveiller la réplication
Voir aussi