Architecture physique du journal des transactions

Mis à jour : 14 avril 2006

Le journal des transactions d'une base de données s'étend sur un ou plusieurs fichiers physiques. D'un point de vue conceptuel, le fichier journal est une chaîne d'enregistrements. D'un point de vue physique, la séquence des enregistrements du journal est stockée de façon efficace dans l'ensemble de fichiers physiques qui implémente le journal des transactions.

Le moteur de base de données SQL Server divise chaque fichier journal physique en un certain nombre de fichiers journaux virtuels. La taille et le nombre de ces fichiers journaux virtuels sont variables. Le moteur de base de données choisit dynamiquement la taille des fichiers journaux virtuels en créant ou en étendant des fichiers journaux. Le moteur de base de données essaie de ne conserver qu'un petit nombre de fichiers virtuels. Après une extension du fichier journal, la taille des fichiers virtuels est la somme de la taille du journal existant et de la taille du nouvel incrément de fichier. La taille et le nombre des fichiers journaux virtuels ne peuvent être ni configurés, ni définis par les administrateurs.

Le seul moment où les fichiers journaux virtuels ont une incidence sur les performances du système est lorsque les valeurs size et growth_increment des fichiers journaux sont faibles. Si la taille de ces fichiers journaux s'accroît par de petits incréments, de nombreux fichiers journaux virtuels vont être créés, ce qui peut ralentir le démarrage de la base de données ainsi que les opérations de sauvegarde et de restauration. Il est conseillé d'affecter aux fichiers journaux une valeur size proche de la taille finale souhaitée et une valeur growth_increment relativement importante.

Le journal des transactions est un fichier cumulatif. Considérons, par exemple, une base de données possédant un fichier journal physique divisé en quatre fichiers journaux virtuels. Lors de la création de la base de données, le fichier journal logique commence au début du fichier journal physique. Les nouveaux enregistrements du journal sont ajoutés à la fin du journal logique, qui s'étend vers la fin du journal physique. Le fait de tronquer le journal permet de libérer tous les journaux virtuels dont les enregistrements précèdent tous le MinLSN (numéro de séquence d'enregistrement minimum). Le MinLSN est le numéro de séquence d'enregistrement du plus ancien enregistrement du journal requis pour une opération de restauration réussie de l'ensemble de la base de données. Le journal des transactions de la base de données exemple ressemblerait à celui de l'illustration suivante :

Fichier journal divisé en quatre fichiers journaux virtuels

Lorsque la fin du journal logique atteint la fin du fichier journal physique, le nouvel enregistrement du journal revient au début du fichier journal physique.

Inclusion d'enregistrements de journal vers le début du fichier journal

Le cycle se répète indéfiniment tant que la fin du journal logique n'a pas atteint le début du journal logique. Si les anciens enregistrements du journal sont tronqués suffisamment souvent pour laisser de la place à tous les nouveaux enregistrements créées jusqu'au point de contrôle suivant, le journal ne se remplit jamais. Si la fin du journal logique atteint le début du journal logique, l'une ou l'autre des situations suivantes se produit :

  • Si le paramètre FILEGROWTH est activé pour le journal et que l'espace disque est suffisant, le fichier s'étend en fonction de la taille spécifiée dans le paramètre growth_increment, les nouveaux enregistrements du journal étant ajoutés à l'extension. Pour plus d'informations sur le paramètre FILEGROWTH, consultez ALTER DATABASE (Transact-SQL).
  • Si le paramètre FILEGROWTH n'est pas activé ou si l'espace disque réservé au fichier journal est inférieur à la taille spécifiée dans le paramètre growth_increment, l'erreur 9002 est générée.

Si le journal contient plusieurs fichiers journaux physiques, le journal logique va se déplacer dans tous les fichiers journaux physiques avant de revenir au début du premier fichier journal physique.

Voir aussi

Concepts

Facteurs susceptibles de retarder la troncation de journal
Architecture logique du journal des transactions
Utilisation des sauvegardes de journaux de transactions
Introduction aux journaux de transactions

Autres ressources

Présentation de l'architecture du journal des transactions

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version Historique

14 avril 2006

Nouveau contenu :
  • Ajout de la définition du MinLSN.