Vue d'ensemble du journal des transactions
Chaque base de données SQL Server 2005 possède un journal des transactions qui enregistre toutes les transactions et les modifications apportées par chacune d'entre elles. Le journal des transactions est un composant essentiel de la base de données et, en cas de défaillance du système, vous pouvez en avoir besoin pour rétablir la cohérence de la base de données. Le journal de transactions ne doit jamais être supprimé ou déplacé, à moins d'en avoir pleinement compris les conséquences.
Opérations prises en charge par le journal des transactions
Le journal des transactions prend en charge les opérations suivantes :
Récupération des transactions individuelles
Récupération de toutes les transactions incomplètes au démarrage de SQL Server
Restauration par progression d'une base de données, d'un fichier, d'un groupe de fichiers ou d'une page jusqu'au point de défaillance
Prise en charge de la réplication transactionnelle
Prise en charge des solutions à serveur de secours.
Récupération des transactions individuelles
Si une application envoie une instruction ROLLBACK, ou si le moteur de base de données détecte une erreur telle que la perte de la communication avec un client, les enregistrements du journal permettent de restaurer les modifications effectuées par une transaction incomplète.
Récupération de toutes les transactions incomplètes au démarrage de SQL Server
En cas de défaillance d'un serveur exécutant SQL Server, il peut arriver que certaines modifications effectuées dans les bases de données n'aient jamais pu être écrites de la mémoire tampon vers les fichiers de données ou proviennent de transactions incomplètes dans les fichiers de données. Lorsqu'elle démarre, une instance de SQL Server exécute une récupération de chaque base de données. Chaque modification enregistrée dans le journal qui risque de ne pas avoir été répercutée dans les fichiers de données est récupérée. Chaque transaction incomplète trouvée dans le journal des transactions est ensuite restaurée afin de préserver l'intégrité de la base de données.
Restauration par progression d'une base de données, d'un fichier, d'un groupe de fichiers ou d'une page restauré jusqu'au point de défaillance
Après un incident matériel ou une défaillance de disque touchant les fichiers de base de données, vous pouvez restaurer la base de données jusqu'au point de défaillance. Restaurez tout d'abord la dernière sauvegarde complète et différentielle de la base de données, puis restaurez la séquence suivante des sauvegardes des journaux des transactions jusqu'au point de défaillance. Lorsque vous restaurez chaque sauvegarde de journal, le moteur de base de données réapplique toutes les modifications enregistrées dans le journal pour restaurer par progression toutes les transactions. Lorsque la dernière sauvegarde de journal a été restaurée, le moteur de base de données utilise les informations des journaux pour restaurer toutes les transactions qui n'ont pas été terminées à ce stade.
Prise en charge de la réplication transactionnelle
L'Agent de lecture du journal surveille le journal des transactions de chaque base de données configurée pour la réplication transactionnelle et copie les transactions devant être répliquées à partir du journal des transactions dans la base de données de distribution. Pour plus d'informations, consultez Fonctionnement de la réplication transactionnelle.
Prise en charge des solutions à serveur de secours
Les solutions à serveur de secours, les mises en miroir de base de données et les copies des journaux de transactions dépendent fortement du journal des transactions. Dans un scénario de copie des journaux de transactions, le serveur primaire envoie le journal des transactions actif de la base de données primaire vers une ou plusieurs destinations. Chaque serveur secondaire restaure le journal dans sa base de données secondaire locale. Pour plus d'informations, consultez Vue d'ensemble de la copie des journaux de transaction.
Dans un scénario de mise en miroir d'une base de données, toutes les mises à jour d'une base de données, à savoir la base de données principale, sont immédiatement reproduites dans une copie distincte complète de la base de données, la base de données miroir. L'instance du serveur principal envoie chaque enregistrement du journal immédiatement à l'instance du serveur miroir, qui applique ces enregistrements à la base de données miroir en la restaurant constamment par progression. Pour plus d'informations, consultez Présentation de la mise en miroir de bases de données.
Caractéristiques du journal des transactions
Les caractéristiques du journal des transactions de moteur de base de données SQL Server sont les suivantes :
Le journal des transactions est mis en œuvre sous la forme d'un fichier ou d'un ensemble de fichiers distinct dans la base de données. Le cache du journal est géré indépendamment du cache des tampons des pages de données, ce qui se traduit par un code simple, rapide et robuste dans le moteur de base de données.
Le format des enregistrements et des pages du journal ne suit pas obligatoirement celui des pages de données.
Le journal des transactions peut être implémenté dans plusieurs fichiers. Les fichiers peuvent être configurés pour croître automatiquement en définissant la valeur FILEGROWTH pour le journal. Le risque d'insuffisance de l'espace dans le journal des transactions et la surcharge administrative sont ainsi réduits. Pour plus d'informations, consultez ALTER DATABASE (Transact-SQL).
Le mécanisme de réutilisation de l'espace des fichiers journaux est rapide et a une incidence minimale sur le débit des transactions.