juillet
11
Le journal des transactions sous SQL Server
Le journal des transactions sous SQL Server est un des thèmes les plus mal compris parmis les nouveaux utilisateurs et gestionnaires de SGBD sous SQL Server.
Cet article décrit ce journal des transactions, quel est sont rôle et comment les différents modes de restauration modifie la log et comment le gérer.
Qu' es ce que le journal des transactions ?
Pour faire simple, le journal des transactions contient toutes les transactions effectuées sur la base de données et toutes les modifications faites par ces transactions sur la base de données. C'est une partie critique de l'architecture de la base de données SQL Server.
Ce journal n'est pas un journal d' audit, c'est à dire qu'il n'est pas utilisé pour connaitre quelles transactions sont lancées par quel utilisateur. Ce n'est pas non plus un outil de restauration, même si il existe des outils tierces qui permettent de faire de l'audit ou de la restauration à partir des ces journaux, ce n'est pas sont rôle premier.
Le journal des transactions est essentiellement utilisé pour assurer l'intégrité des données de la base de données relationnelle, pour permettre les rollbacks - retours arrières - et les restaurations.
Quand des changements sont effectués sur la base, que ce soit une transaction explicite ou une transaction utilisant un commit automatique, les changements sont d'abord écrits en dur dans le journal puis les pages de données sont changées en mémoire. Une fois l'enregistrement des changements dans la log, la transaction est considérée comme finalisée.
Les enregistrements du journal sont considérées comme actives jusqu'à ce que les pages de la base modifiées soit écrites sur le disque. Une fois cette écriture effectuée, les entrées du journal sont inactives et ne sont plus nécessaires pour une restauration de la base.
Si les transactions sont annulées, que ce soit par un ROLLBACK TRANSACTION explicite, une erreur si XACT_ABORT est activé, ou une perte de connexion du client, le journal est alors utilisé pour annuler les modifications faites par cette transaction.
Quand un serveur est redémarré, le language SQL utilise la transaction pour voir si au moment ou le serveur s'est éteint, il existait des transactions finies mais dont les modifications ne furent pas écrites sur le disque, ou qu'une transaction ne s'est pas finie. Si il en existe, les modifications non écrites sont réexécutées et toutes celles non finalisées sont annulées. Ces opérations assurent l'intégrité après un redémarrage.
Les sauvegardes faites avec le journal peuvent servir pour restaurer une base de données à un instant T en cas d'erreur.
Le journal est aussi utilisé pour assurer la réplication , le mirroring des bases, le Change Data Capture - CDC : c'est un système permettant de déclencher des traitements sur le changements des données.
Commentaires
Aucun commentaire pour le moment.
Ajouter un commentaire