Attention, votre navigateur ne supporte pas le javascript ou celui-ci a été désactivé. Certaines fonctionnalités dynamiques de ce module sont restreintes.
Regardez l'extrait vidéo et complétez le texte suivant.
Pour garantir le « tout ou rien », le SGBD utilise un outil particulier, qu'on appelle le journal. Le journal est un fichier dans lequel le SGBD écrit simplement les zones mémoire qui ont été touchées par votre programme en écriture. Relire ce que j'ai touché c'est en général immédiat, c'est en tout cas bien plus rapide que refaire tourner tout le programme. Le principe est très simple. D'une part, ce fichier n'est pas stocké au même endroit que la base de données, parce que s'il y a une panne sur la base de données, il y aurait aussi une panne sur le journal. Donc le journal est en général considéré comme étant rangé ailleurs, dans ce qu'on appelle une mémoire sûre Chaque fois que vous faites un ordre d'écriture quelque part, il est inscrit dans le journal, il est préfixé par le nom de la transaction qu'il touche. Parce que dans votre ordinateur il y a évidemment plein de programmes qui tournent en même temps. Et puis à chaque fois qu'il y a une mise à jour, on met la case mémoire à laquelle on touche, l'ancienne valeur et la nouvelle valeur. Cela fait une ligne dans le journal. Quand on commence une transaction, on met une ligne particulière qu'on appelle « start » et quand on termine une transaction, on met une ligne particulière qu'on appelle « commit ». J'ai des transactions qui tournent, j'ai des « start », j'ai des informations, par exemple la transaction A a touché à la zone A, il y en avait 1000, maintenant il y en a 950, la transaction 2 a touché à la zone C, il y en avait 700, il y en a 600 maintenant.
Dans cette phrase de journal, la transaction T1 s'est terminée, la transaction T2 s'est terminée. La technique est simple : quand le programme tourne, à chaque fois qu'il y a une écriture quelque part, une ligne est écrite dans le journal. Quand il y a une panne, à un moment donné, cela s'arrête. Quand cela s'arrête, le système, au moment du redémarrage, après panne, relit le journal. Si une transaction apparaît dans le journal, avec son « start » et avec son « commit », c'est qu'elle avait bien été jusqu'au bout et que j'ai bien toutes les informations qui avaient dû être écrites dans la mémoire. Auquel cas je repasse toutes ces lignes-là pour réécrire en mémoire les nouvelles valeurs de manière à être sûr que ces nouvelles valeurs sont bien en mémoire. Si jamais une transaction est dans le journal avec un « start » mais sans « commit », elle n'est donc pas allée jusqu'au bout. Puisqu'elle n'est pas allée jusqu'au bout, je reprends toutes ces lignes et je remets toutes les anciennes valeurs.