Facteurs susceptibles de retarder la troncation de journal
Mis à jour : 17 juillet 2006
La troncation de journal libère de l'espace dans le fichier journal qui peut être réutilisé par le journal des transactions. Dans la mesure où la partie active du journal ne peut pas être tronquée ni supprimée par réduction, la troncation peut être retardée lorsque des enregistrements du journal restent longtemps actifs.
.gif "ms345414.note(fr-fr,SQL.90).gif") Remarque : |
|---|
| Pour plus d'informations sur le fonctionnement de la troncation de journal, consultez Troncation du journal des transactions. |
Les enregistrements du journal peuvent rester actifs sous diverses conditions, décrites dans cette rubrique. Pour découvrir les éventuelles raisons qui empêchent la troncation de journal, utilisez les colonnes log_reuse_wait et log_reuse_wait_desc de l'affichage catalogue sys.databases.
| Remarque : |
|---|
| 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 les valeurs des colonnes log_reuse_wait et log_reuse_wait_desc de l'affichage catalogue sys.database.
Valeur de log_reuse_wait
Valeur de log_reuse_wait_desc
Description
0
NOTHING
Actuellement, un ou plusieurs fichiers journaux virtuels sont 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 de fichier journal est requise pour avancer l'en-tête du journal (mode de restauration complète ou mode de récupération utilisant les journaux de transactions uniquement).
Remarque :
Les sauvegardes de fichiers journaux n'empêchent pas la troncation.
Une fois le journal sauvegardé, l'en-tête est avancé et un certain espace de journal peut devenir réutilisable.
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).
- Une transaction de longue durée peut exister au début de la sauvegarde de fichier journal. Dans ce cas, il peut être nécessaire d'effectuer une nouvelle sauvegarde de fichier journal pour libérer de l'espace. Pour plus d'informations, consultez « Transactions actives de longue durée », plus loin dans cette rubrique.
- Une transaction est différée (SQL Server 2005 Enterprise Edition et versions ultérieures uniquement). Une transaction différée est une transaction active dont la restauration est bloquée en raison de ressources non disponibles. Pour plus d'informations sur les causes des transactions différées et comment changer leur état, consultez Transactions différées.
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 de 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 de 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 les versions ultérieures, les sauvegardes de fichiers journaux peuvent intervenir au cours d'une sauvegarde de données. Toutefois, la troncation du journal ne peut pas intervenir au cours de telles sauvegardes de fichiers journaux 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. Si vous effectuez des sauvegardes de fichiers, l'utilisation de WITH NO_LOG permet d'éviter le problème qui empêche de tronquer le journal.
Pour plus d'informations sur la troncation de journaux tronqués, consultez Troncation du journal des transactions.
| Important : |
|---|
| Les options NO_LOG et TRUNCATE_ONLY de l'instruction BACKUP LOG seront supprimées dans une version future de SQL Server. Ces options effacent la partie inactive du journal sans en faire de sauvegarde et tronquent le journal en tenant uniquement compte de la partie active du journal. Cela provoque une rupture de la séquence de journaux. Jusqu'à la prochaine sauvegarde de base de données complète ou différentielle, la base de données n'est pas protégée contre une défaillance du support. Par conséquent, nous vous conseillons vivement de ne pas utiliser ces options dans de nouveaux travaux de développement et de prévoir de modifier les applications qui les utilisent. |
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.
| Remarque : |
|---|
| 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 de fichier journal qui tronque le journal, à appliquer cette sauvegarde du 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 de fichiers journaux supplémentaires sont effectuées après la sauvegarde de 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. Vous pouvez également 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 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
Concepts
Points de contrôle et partie active du journal
Troncation du journal des transactions
Réduction du journal des transactions
Résolution des problèmes en cas de journal des transactions saturé (erreur 9002)
Autres ressources
Gestion du journal des transactions