Gestion des Transactions

Mohamed EL ADNANI

1
Plan

1. Introduction : modle ACID

2. Journaux et Sauvegarde
3. Scnarios de Reprise
4. Concurrence
5. Verrouillage

2/25
Introduction

Le concept de transaction et fondamental

pour maintenir la cohrence dune BD
Une transaction est une unit atomique de
mise jour compose de plusieurs
oprations successives qui doivent tre
toutes excutes ou pas de tout
Lobjectif premier de la gestion des
transactions est dterminer les parties des
programmes BD correctement excutes
3/25
Introduction

Beaucoup d'oprations sur une BD doivent

tre atomiques:
Exemple : Transfert d'argent entre les comptes:
UPDATE Compte1
Val = Val -100
UPDATE Compte2
Val = Val + 100

Si seulement une de ces requtes est

excute, la BD perd sa consistance

4/25
Proprits des transactions: Modle ACID de
transactions
Atomicit
Unit de cohrence : toutes les mises jour doivent tre
effectues ou aucune. Le systme doit tre capable
dannuler toutes les modifications que la transaction a
engag en cas dchec
Latomicit est menace par tout vnement successible
dinterrompre une transaction en cour tel que : les pannes
de programmes, de systme ou du matriel

Cohrence
La transaction doit faire passer la base de donnes d'un
tat cohrent un autre
En cas dchec, le systme doit restaurer la BD ltat
cohrent davant la transaction non termine

5/25
Proprits des transactions: Modle ACID de
transactions
Isolation
Les rsultats d'une transaction ne doivent tre visibles aux
autres transactions qu'une fois la transaction est valide
afin dviter les interfrences avec les autres transactions
Les accs concurrents peuvent mettre en question
lisolation

Durabilit
Les modifications d une transaction valide ne seront
jamais perdues
Le systme doit garantir quelles soient conserves en cas
de pannes

6/25
Modle ACID de transactions

Oprations atomiques inexprimables avec

une requte relationnelle.
entirement ou pas du tout
Prservant la consistance de la BD
Comme si l'usager tait isol sur la BD
A effet durable sur la BD, une fois termines
comme prvu

7/25
Primitives de gestion de transactions

BEGIN, COMMIT, ROLLBACK

BEGIN TRANSACTION
UPDATE Compte1
Val = Val -100
IF SQLCODE <> 0 ROLLBACK ; EXIT ;
UPDATE Compte2
Val = Val + 100
IF SQLCODE <> 0 ROLLBACK ; EXIT;
COMMIT

8/25
Primitives de gestion de transactions

INTRODUCTION DACTIONS ATOMIQUES

Commit (fin avec succs) et Abort (fin avec chec)
Ces actions s'effectuent en fin de transaction

COMMIT
Validation de la transaction
Rend effectives toutes les mises jour de la transaction

ABORT /ROLLBACK
Annulation de la transaction
Dfait toutes les mises jour de la transaction

9/25
Schma de transaction simple

Fin avec succs ou chec

Begin_Transaction
- Provoque l'intgration relle des mises
update jour dans la base
- Relche les verrous
update
.....
Commit ou Abort
- Provoque l'annulation des mises jour
- Relche les verrous
- Reprend la transaction

10/25
Effet logique
Mmoire de la
transaction
Update
Update

Abort
Commit

Bases de donnes Poubelle

11/25
Journaux et Sauvegarde
A un instant donn, ltat de la BD est dtermin par
ltat de la mmoire secondaire (disque), et ltat du
cache (mmoire volatile)
Deux cas sont possibles:
Transactions venant juste dtre valides dont les MAJ sont
en cours de report en cas de panne il faut pouvoir
REFAIRE les modifications
En milieu de transaction et afin de librer de lespace
mmoire; le systme effectue des reports de pages avant
la validation de la transaction en cas de panne il faut
pouvoir DEFAIRE les modifications

12/25
Journaux et Sauvegarde
Les journaux qui sont des fichiers systmes sont utilises
pour permettre de refaire et de dfaire les MAJ des
transactions
Journal des images avant
Journal contenant les dbuts de transactions, les valeurs
d'enregistrement avant mises jour, les fins de transactions
(commit ou abort)
Il permet de dfaire les mises jour effectues par une
transaction
Journal des images aprs
Journal contenant les dbuts de transactions, les valeurs
d'enregistrement aprs mises jour, les fins de transactions
(commit ou abort)
Il permet de refaire les mises jour effectues par une
transaction

13/25
Journal des images avant

Utilis pour dfaire les mises jour : Undo

2.Log

Page lue Page modifie

3.Update

1.Read 4.Write

Base de donnes

14/25
Journal des images aprs

Utilis pour refaire les mises jour : Redo

3.Log

Page lue Page modifie

2.Update

1.Read 4.Write

Base de donnes

15/25
Gestion du journal
Journal avant et aprs sont unifis
crits dans un tampon en mmoire et vider sur
disque en dbut de commit (avant dcrire sur le
disque)
Structure d'un enregistrement :
N transaction (Trid)
Type enregistrement {dbut, update, insert, commit, abort}
TupleId
[Attribut modifi, Ancienne valeur, Nouvelle valeur] ...
Problme de taille
on tourne sur N fichiers de taille fixe
possibilit d'utiliser un fichier hach sur Trid/Tid

16/25
Sauvegarde

Sauvegarde priodique de la base

toutes les heures, jours, ...
Doit tre effectue en parallle aux mises jour
Un Point de Reprise (checkpoint) est crit dans le
journal pour le synchroniser par rapport la
sauvegarde de la base
permet de situer les transactions effectues aprs la
sauvegarde de la base
Pose d'un point de reprise :
crire les buffers de journalisation (Log)
crire les buffers de pages (DB)
crire un record spcial "checkpoint" dans le journal

17/25
Scnarios de Reprise
Les mises jour peuvent tre effectues
directement dans la base (en place)
la base est mise jour immdiatement, ou au moins ds
que possible pendant que la transaction est active (avant le
commit)
La validation de latomicit dune transaction est ralise
par criture dun enregistrement dans le journal
Les mises jour peuvent tre effectues en
mmoire et installes dans la base la validation
(commit)
le journal est crit avant d'crire les mises jour

18/25
 Stratgie do-undo
Mises jour en place
l'objet est modifi dans la base
Utilisation des images avant
copie de l'objet avant mise jour
utilise pour dfaire en cas de panne
3. Update

2. LogPage
Mmoire cache Journal avant
4. WritePage

1. LirePage Undo

Base

19/25
Stratgie do-redo
Mises jour en diffrentiel
l'objet est modifi en page diffrentielle (non en
place/journal)
Utilisation des images aprs
copie de l'objet en journal aprs mise jour (do)
utilise pour refaire en cas de panne (redo)
2. Update
4. LogPage
Mmoire cache Journal aprs

3. WritePage

1. LirePage Redo

Base Ombre
Commit 20/25
Pages ombres

La validation dune transaction non en place peut

tre effectue par la technique de Pages dombres
Les pages modifies sont recopies dans de
nouvelles pages en mmoire et crites dans de
nouveaux emplacements dans la base
Ces pages nouvelles attaches la transaction
modifiantes sont dites des pages diffrentielles
Les anciennes pages constituent les pages ombres
Avant toutes lecture le SGBD doit consulter les
pages diff. Valides et non encore physiquement
intgres la base alourdissement des
procdures de consultation

21/25
Pages ombres
Table des Pages Ombres

Nom
Fichier
Adresse
COMMIT
Table des
Pages
Page Ombre Page Ombre

Nouvelle Table des Pages

Nouvelles Pages
22/25
La gestion des buffers
Bufferisation des journaux
on crit le journal lorsqu'un buffer est plein
ou lorsqu'une transaction commet
Bufferisation des bases
on modifie la page en mmoire
le vidage sur disque s'effectue en diffr
(processus E/S)
Synchronisation journaux / base
le journal doit toujours tre crit avant modification
de la base !

23/25
Commits bloqus
AFIN D'EVITER 3 E/S POUR 1:
Le systme reporte l'enregistrement des journaux au
commit
Il force plusieurs transactions commettre ensemble
Il fait attendre les transactions au commit afin de bloquer
un buffer d'criture dans le journal

RESULTAT
La technique des "commits" bloques permet d'amliorer les
performances lors des pointes sans faire attendre trop
sensiblement les transactions

24/25
Reprise froid

En cas de perte d'une partie de la base, on

repart de la dernire sauvegarde
Le systme retrouve le checkpoint associ
Il r-applique toutes les transactions
commises depuis ce point
(for each committed Ti : redo (Ti))

25/25