CHAPITRE 1 

: TRANSACTIONS

Isolation: Isoler les donnees pour les proteger des mofications externes et faire des
modifications sur une transaction sans que l’autre transaction ne soit impactee.
Transaction: Ensemble de requetes(jeu de donnees) traitees de facon unitaire comme si
c’etait une seule requete.
Le concept de transaction est caracterise par l’atomicite(un debut et une fin pour assurer la
coherence d’un jeu de donnees dans un espace temporaire).
Atomicite soit tout marche soit rien de marche. Donc si il y’a une requete qui viole une
contrainte, toutes les modifications de la transaction seront ignorees.
Coherence: Elle n’est pas assure durant la transaction mais la base de donnees doit etre
coherente a la fin de la transaction.

Le jeu de donnees est stocke dans une memoire temporaire.

ACID : Atomicite, Coherence, isolation, durabilite
SGBD transactional: S’il permet d’effectuer des transactions.
SGBD ACID:
Les transactions sont caracterisees par ACID.
Pratique:
 Start transaction; : pour que ces donnees puissent etre proteger des autres influences.
Creation d’un espace de stockage temporaire. Permet d’entrer en mode transaction
Ajout ou modification d’une donnee: L’autre utilisasteur ne le voit pas: C’est le principe
de l’isolation.
 Commit; : pour terminer la transaction et pour ecrire les infos qui etait sur la memoire
temporaire sur le disque. C’est pour sortir de l’isolation.
 Rollback; : pour annuler les traitements et sortir du mode transactionnel. Supprimer les
infos presents dans la memoire temporaire.
On travaille sur le disque ou sur la memoire temporaire.
Cas ou les users travaillent sur la meme donnee:
La requête update de l’user est mise en attente lorsque l’autre modifie.
La ressource sera sécurisée jusqu’a ce que l’user fait un commit. Cela permettra de prendre en
compte les modifications.
Le verrou sera porté sur la table d’index ce qui nous permet de savoir qu’une modification est
en cours sachant que les 2 users sont dans des espaces temporaires isoles.
Plusieurs sortes de verrouillage:
 Verouillage d’un enregistrement: Select * from points where x>5 for update:
verrouillage en lecture pour eviter que les autres utilisateurs ne modifient les points ou
x est > 5;
 Verrouillage d’une table: lock table;
 InnoDB: verrouillage jusqu’aux enregistrements et Myisam: verrouillage jusqu’aux
tables par defaut.
 Insertion ne peut creer une mise en attente: parce que les autres utisateurs ne peuvent
pas voir l’enregistrement nouvellement cree.
Cout de la transaction
 Occupation de l’espace memoire
 Mecanisme de verrou entraine un probleme de liberation de la memoire. La solution
grace au timeout.
 Volatilite de l’espace memoire lors de l’arret du serveur. La solution grace a la
journalisation(historisation des modifications(insert, update, delete. Le select n’est pas
concerné) sur disque(fichier)).
C’est une journalisation de l’operation mais pas de l’enregistrement. Les problemes de la
journalisation:
 Surcharge. Solution: un algo LRU qui me permet de reecrire sur un fichier de taille
fixe.
 Diminue la vitesse: Solution: Utiliser le buffer comme memoire intermediaire. Le
serveur ecrit juste sur le buffer.
Buffer va etre vider par un autre processus qui va ecrire les donnees du buffer sur disque.
2 types de fichiers de journalisation:
 UNDO: on stocke l’ancienne valeur avant la modification (historique de modification
de valeur): Restoration d’anciennes valeurs
 REDO: On stocke la nouvelle valeur.
Mercredi 27 janvier 2021

Remarque: Abort = rollback;

Notion de verrou
 Un verrou sur un enregistrement ou sur une table.
 Lorsque l’on travail sur un enregistresment, l’autre ne peut pas travailler dessus car le
verrou n’est pas encore relaché.
 Des modifications sur un enrgistrement supprimé par une autre transaction en parallele
seront ignorées.
Point de sauvegarde:
 Savepoint p1;
  Rollback to p1; pour restaurer l’etat de la transaction a un etat anterieur.
 Rollback; pour supprimer tous les modifications
Les savepoint sont enregistres dans une pile.
P1/P2/P3/P4 -> restaurer la sauvergarder P2 donc on supprime P3 ET P4.
Rollback; supprimer toutes les sauvegardes et on revient a un etat anterieur a la transaction;
(Toute la transaction sera annulee).
Variable d’environnement autocommit
Remarque: Par defaut les SGBD transactionnels gerent toujours des transaction.
1 requete ou plusieurs  1 transaction par defaut
La variable d’environnement Autocommit permet de faire la validation automatique des
requetes.
Quand on tape une requete par defaut, le systeme rajoute un commit.
 Setautocommit=1: C’est ce qui est par defaut dans Mysql. Validation automatique des
requetes.
 Set autocommit=0; A partir de ce moment aucune des requetes ne sera
automatiquement validee. Ensuite on fait un commit pour valider. C’est comme si on
etait en mode transactionnelle permanent.
Dans oracle, on est par defaut en mode transactionnel permanent. On peut faire un commit à
tout moment pour que les modifications soient validees. Alors que dans Mysql, il faut active
le mode transactionnel.
Les fichiers log
Le concept de transaction lie à un concept de journalisation dont les fichiers sont dupliques,
de taille fixe, unifies et bufferises.
MySQL, on a 2 fichiers de journalisation.
Oracle, on a 3 fichiers de journalisation.
On a besoin un minimum 2 fichiers de journalisation pour des questions de securite Si jamais
on a une panne du disque du fichier de journalisation qu’on soit en mesure de restaurer.
On duplique les fichiers log pour les repartir physiquement sur des disques.
Gestion de la sauvegarde: Sauvegarde integrale de la base de donnees
Mysqldump -u oot -p license > backupDBlicence.sql : permet d’avoir un script sql pour
recreer la base de donnees.
La transaction fait de la journalisation.
Gestion de la journalisation: Journalisation de l‘ensemble des operations de transaction dans
un systeme de fichier.
Strategie do-undo: Restaure l’etat de la base de donnees. On ecrase les valeurs que l’on avait
Strategie do-redo: Restaure l’etat de mes transactions. On a besoin de l’ombre
Buffer de base de donnees: sauvegarde lors d’un commit
Buffer de journalisation : sauvegarde en permanence pour la journalisation.

Bufferisation : Réduire le temps d’accès sur le disque car on écrit sur un espace temporaire
Changement du niveau d’isolation
 Repitable read : Les modifications faites qu’elles soient commuter ou pas, ne sont pas
visibles dans une autre transaction. Voir les mêmes résultats de lecture si dans ma
transaction je n’ai pas fait de modifications. C’est le mode d’isolation par défaut.
 Read commited : permet de voir les modifications après la validation (le commit) des
opérations d’une autre transaction,
 Read uncommited : Lire les modifications effectuées dans les autres transactions même si
elles ne sont pas encore commutées. L’autre transaction a un aperçu a temps réel des
modifications effectuées dans une autre transaction.

Le read commited et le read uncommited auront comme consequence une instabilite des
transactions. Par exemple pour un calcul de Moyenne, le resultat sera inexact.
Avantages : Vue d’ensemble sur les activites de mon client a temps reel qu’elles soient
valideees ou non
Comment les transactions peuvent voir les modifications des autres?
Read uncommited : Avoir un espace memoire partage a chaque fois que quelqu’un fait une
modification , il l’applique a cete space partage.
Pourquoi ne pas prendre le buffer de journalisation comme source de donnees pour raffrachir
les autres transactions? (Voir image)
La gestion des verrous
Verrouillage mortelle : Solution : Serialisation en effectuant toutes les operations de T1 avant
de faire celles de T2 pour eviter les interbloquage. Mise en serie des operations au lieu de les
traiter de manière aleatoire en function de leurs arrives. Cela permet d’eviter les verroux
mortels.
Les scenarios de reprise a froid: Restaurer l’etat de la base de donnees a un moment precis.