Vous êtes sur la page 1sur 75

L2A

Semestre 4
Mehdi Benzine
Introduction (1)
 Les accès concurrents à une base de données peuvent
engendrer des conflits.
 La réalisation d'opérations logiques regroupant
plusieurs opérations atomiques doit être réalisable.
Compte (num_compte, nom, solde)
Virement de 1000DA du compte 101 au compte 106:
update compte set solde = solde - 1000 where num_compte = 101;
update compte set solde = solde + 1000 where num_compte = 106;

update compte set solde = solde - 1000 where num_compte = 101;


PANNE
update compte set solde = solde + 1000 where num_compte = 106;
2
Introduction (2)
 Les données présentes dans la base de données doivent
vérifier toutes les contraintes d'intégrité déclarées sur
cette base de données.
 Pour avoir une vision cohérente de la base de données
lors de sa manipulation, un utilisateur ne doit pas voir
les modifications apportés par les autres utilisateurs
qui manipulent la base de données en même temps
que lui.
 Les mises à jours apportées à une base de données
doivent être permanentes et ne pas disparaitre même
en cas de panne logicielle ou matérielle.

3
Transaction
Une transaction est une unité de mises à jour composée
d'opérations qui doivent toutes être exécutées ou pas du
tout.

Toute transaction peut être à tout moment :


Validée (COMMIT)
Annulée (ABORT, ROLLBACK)

Toutes les modifications effectuées par une transaction


annulée doivent être défaites (annulées)

4
Propriétés ACID
Une transaction doit garantir les propriétés suivantes:
Atomicité: Toutes les opérations d'une transaction
doivent être exécutées ou pas du tout.
Cohérence: Une transaction doit faire passer la base de
données d'un état cohérent vers un autre état cohérent.
Isolation: Les mises à jour apportées par une transaction
ne doivent être visibles aux autres transactions qu'une fois
la première terminée et validée.
Durabilité: Les effets d'une transaction validée ne doivent
pas être perdus.

5
Atomicité
Une transaction étant une unité d'opérations sur une
base de données, l'annulation d'une transaction doit
conduire à l'annulation de tous ses effets (modifications)
sur la base de données.

Le SGBD doit conserver l'historique des modifications


non encore validées pour pouvoir les restaurer les
données originales au cas où la transactions ayant
effectué ces modifications a été annulée.

6
Cohérence
Une transaction doit faire passer une base de données d'un état
cohérent à un autre état cohérent.

Un état cohérent est un état où toutes les contraintes d'intégrité


sont respectées.

Oracle propose de vérifier chaque contrainte d'intégrité :


 Au moment de la modification des données (par défaut)
 Au moment de la validation de la transaction (clause
DEFERRABLE INITIALLY DEFERRED)

CREATE TABLE compte (num_compte INTEGER PRIMARY KEY,


nom VARCHAR2(50), Solde NUMBER(10,2) CHECK(Solde >= 0)
DEFERRABLE INITIALLY DEFERRED);
7
Isolation
Chaque utilisateur doit avoir l'impression d'être la seul à
manipuler la base de données à un instant donné.

Les effets d'une transaction ne deviennent visibles aux


autres transactions qu'après sa validation.

Le SGBD doit conserver l'historique des données pour


pouvoir fournir à chaque transaction la version des
données qui lui correspondent.

8
Durabilité
Les effets d'une transaction validée doivent être
permanents même en cas de panne.

Le SGBD doit conserver en permanence sur une


mémoire secondaire (disque dur, mémoire flash …) les
effets des transactions validées.

Ceci ne peut être garanti sans redondance matérielle


(copie des données sur plusieurs disques, RAID…).

9
Garantir les propriétés ACID
Pour garantir les propriétés ACID des transactions, les
SGBD mettent en place des mécanismes de:

1. Gestion des accès concurrents

2. Reprise sur panne

10
Gestion des accès concurrents
Si plusieurs transactions s'exécutent en parallèle,
certains problèmes peuvent apparaître.
Incohérence
Perte de mises à jour
Lectures non reproductibles

11
Incohérence
Plusieurs transactions modifiant des données liées par
une contraintes d'intégrité peut introduire des
incohérences.
Exemple: contrainte A = B (A = 100, B = 100)
T1: T2:
A := A + 1
A := A * 2

B: = B * 2

B=B+1

Temps

(A = 202, B = 201) 12
Perte de mises à jour
Une perte de mise à jour peut arriver lorsqu'une
transaction calcule une mise à jour à partir d'une donnée
périmée
Exemple: Solde = 10000
T1: T2:
A := Solde
B := Solde

Solde := B + 2000

Solde := A + 1000

Temps

Solde = 11000 13
Lectures non reproductibles
Deux lecture d'une même donnée dans la même
transaction peuvent conduire à deux valeurs différentes
si elle a été modifiée par une autre transaction.
Exemple: Solde = 10000
T1: T2:
A := Solde (10000)
B := Solde

… Solde := B + 2000

A: = Solde (12000)

Temps

14
Contrôle de concurrence
Les problèmes liés à la concurrence des accès sont dus
aux accès concurrents aux données en lecture et en
écriture des différentes transactions (entrelacement).

Lorsque les transactions sont exécutées de manière


sérielle (les unes à la suite des autres) les problèmes de
concurrence vus précédemment ne se posent pas.

15
Incohérence
Plusieurs transactions modifiant des données liées par
une contraintes d'intégrité peut introduire des
incohérences.
Exemple: contrainte A = B (A = 100, B = 100)
T1: T2:
A := A + 1
A := A * 2

B: = B * 2

B=B+1

Temps

(A = 202, B = 201) 16
Incohérence
Exemple: contrainte A = B (A = 100, B = 100)
T1:
A := A + 1
B=B+1

T2:
A := A * 2
B: = B * 2

Temps

(A = 202, B = 202)

17
Perte de mises à jour
Une perte de mise à jour peut arriver lorsqu'une
transaction calcule une mise à jour à partir d'une donnée
périmée
Exemple: Solde = 10000
T1: T2:
A := Solde
B := Solde

Solde := B + 2000

Solde := A + 1000

Temps

Solde = 11000 18
Perte de mises à jour
Exemple: Solde = 10000

T1:
A := Solde
Solde := A + 1000

T2:
B := Solde
Solde := B + 2000
Temps

Solde = 13000

19
Lectures non reproductibles
Deux lecture d'une même donnée dans la même
transaction peuvent conduire à deux valeurs différentes
si elle a été modifiée par une autre transaction.
Exemple: Solde = 10000
T1: T2:
A := Solde (=10000)
B := Solde

… Solde := B + 2000

A: = Solde (=12000)

Temps

20
Lectures non reproductibles
Exemple: Solde = 10000

T1:
A := Solde (=10000)


A: = Solde (=10000)

T2:
B := Solde
Solde := B + 2000
Temps

21
Exécution sérialisable (serializable)
Ne permettre l'exécution que d'une seule transaction à la
fois empêche l'exploitation optimale des ressources
disponibles (capacité de calcul, parallélisme…). Cela
augmente considérablement le temps de réponse de la
base de données .

La solution consiste à exécuter en parallèle les


transactions dont les effets sont équivalents à une
exécution en sérielle. Ce type d'exécution est dite
sérialisable.

22
Opérations permutables
Chaque transaction réalise deux types d'opérations:
 Lecture R: lecture d'un objet (attribut…) de la base de données
R(Salaire1001): Lire le salaire de l'employé 1001
 Ecriture (W): écriture d'un objet (attribut…) de la base de données
W(Salaire1001, 25000): Ecrire le salaire de l'employé 1001 = 25000.00DA

Deux opérations sont dites permutables, si leur effet est identique quelque soit
l'ordre dans lequel elles sont exécutées:
Les opérations sur des objets distincts sont permutables
T1:W(A, 12), T2:W(B, 25)
Les opérations de lecture sur le même objet sont permutable
T1: R(A), T2:R(A)
Les opérations d'écriture sur le même objet ne sont pas permutables (ex. T1:W(A,
10), T2:W(A, 18)
Une lecture et une écriture sur un même objet ne sont pas permutables T1: R(A),
T2:W(A, 12)

23
Scénario d'exécution
Séquence d'opérations exécutées par une ou plusieurs
transactions.
Exemple:
T1: W(A, 15), T2:R(B), T1:R(B), T2:W(B, 45), T2: R(C)
T1: T2:
W(A, 15)

R(B)
R(B)

W(B, 45)
R(C)
Temps
24
Exécution sérialisable
Un scénario d'exécution sérialisable est une exécution
pouvant être ramenée à une exécution sérielle équivalente par
un ensemble de permutations d'opérations permutables.

Exemple: T1: R(B), T2:R(A), T1:R(A), T2:W(A, 10)


T1: T2:
R(B)
R(A)

R(A)

W(A, 10)

Temps
25
Exécution sérialisable
Un scénario d'exécution sérialisable est une exécution
pouvant être ramenée à une exécution sérielle équivalente par
un ensemble de permutations d'opérations permutables.

Exemple: T1: R(B), T2:R(A), T1:R(A), T2:W(A, 10)


T1: T2:
R(B)
R(A)

R(A)

W(A, 10)

Temps
26
Exécution sérialisable
Un scénario d'exécution sérialisable est une exécution
pouvant être ramenée à une exécution sérielle équivalente par
un ensemble de permutations d'opérations permutables.

Exemple: T1: R(B), T1:R(A), T2:R(A), T2:W(A, 10)


T1: T2:
R(B)

R(A)
R(A)

W(A, 10)
Temps
27
Exécution sérialisable
Une exécution de transactions sérialisable est une exécution
pouvant être ramenée à une exécution sérielle équivalente par
un ensemble de permutations d'opérations permutables.

Exemple: T1: R(B), T1:R(A), T2:R(A), T2:W(A, 10)


T1: T2:
R(B)

R(A)
R(A)
Cette exécution est équivalente à
une exécution en série. C'est une
W(A, 10)
exécution sérialisable.
Temps
28
Exécution non sérialisable

Exemple: T1: R(B), T2:R(A), T1:W(A, 24), T2:W(A, 36)


A=8
T1: T2:
R(B)
R(A)

W(A, 24)
W(A, 36)

Temps
29
Exécution non sérialisable

Exemple: T1: R(A), T2:R(A), T1:W(A, 24), T2:W(A, 36)


A=8
T1: T2:
R(B)
R(A)

W(A, 24)

W(A, 36)

Temps
30
Exécution non sérialisable

Exemple: T1: R(A), T2:R(A), T1:W(A, 24), T2:W(A, 36)


A=8
T1: T2:
R(B)
R(A)

W(A, 24)
Pas d'exécution sérielle
équivalente à cette exécution!!! W(A, 36)
Ce n'est pas une exécution
sérialisable Temps
31
Contrôle de concurrence
Pour contrôler la concurrence des accès, il est possible
d'utiliser des verrous.

Chaque transaction pose un verrou sur les données


qu'elle manipule (en lecture ou en écriture) pour
empêcher les autres transactions d'y accéder.

Une transaction voulant poser un verrou sur une donnée


déjà verrouillée doit attendre que celle-ci soit
déverrouillée.
32
Contrôle de concurrence
Le verrouillage dégrade les performances du SGBD car il
impose des délais d'attente aux transactions.

Il est possible pour améliorer les performances de définir


plusieurs granules (types d'objets) de verrouillages:
Verrouillage de d'attribut
Verrouillage de tuple
Verrouillage de table
…

33
Contrôle de concurrence
L'utilisation de granules trop petits multiplie le nombre
de verrous à gérer.
Poser des verrous au niveau des attributs conduit le SGBD
à gérer potentiellement un très grand nombre de verrous
et à réduire ses performances.
L'utilisation de granules trop gros augmente le nombre
de blocages.
Verrouiller toute une table pour modifier un tuple bloque
toutes les transactions voulant accéder à la table.

34
Modes de verrouillage
Deux modes de verrouillage sont toujours utilisés:

 Verrou partagé (Shared, S): demandé pour lire un objet.


Un verrou partagé peut être obtenu si aucune
transaction n'a posé de verrou exclusif n'est posé sur cet
objet. Plusieurs verrous partagés peuvent être posés sur
le même objet.

 Verrou exclusif (eXclusive, X): demandé pour modifier


un objet. Un verrou exclusif peut être obtenu si aucun
verrou n'est posé sur cet objet.

35
Compatibilité des verrous

Cette matrice définie la compatibilité des verrous posés sur un


même objet (attribut, tuple, table…).

Partagé S Exclusif X
Partagé S Compatible Incompatible
Exclusif X Incompatible Incompatible

Un transaction disposant d'un verrou partagé sur un


objet peut demander à le remplacer par un verrou
exclusif si aucune autre transaction ne dispose d'un
autre verrou partagé sur cet objet.
36
Verrouillage à deux phases
Le verrouillage à deux phases consiste pour un transaction à :
 poser des verrous sur les objets qu'elle manipule dans une
première phase.
 libérer les verrous posés dans une deuxième phase.
Plus aucun verrou ne doit être posé par la transaction à partir
du moment où elle commence à libérer des verrous.

Il a été démontré que l'exécution d'un ensemble de


transactions utilisant le verrouillage à deux phases est
sérialisable.

37
Exécution non sérialisable

Exemple: T1: R(B), T2:R(A), T1:W(A, 24), T2:W(A, 36)


A=8
T1: T2:
R(B)
R(A)

W(A, 24)

W(A, 36)

Temps
38
Exécution sérialisable avec
verrouillage
Exemple: T1: R(B), T2:R(A), T1:W(A, 24), T2:W(A, 36)
T1: T2:
Lock (B, S) OK
R(B)
Lock(A, X) attente Lock(A, S) OK
. R(A)
.
.
. Lock(A, X) OK
. W(A, 36)
Ok Unlock(A)
W(A, 24)
Unlock(A)
Exécution sérialisable
Temps 39
Verrou mortel (Deadlock)
T1: R(A), T2:R(B), T1:W(B, 12), T2:W(A, 10)
T1: T2:
Lock (A, S) OK
R(A) Lock(B, S) OK
R(B)
Lock(B, X) attente
.
. Lock(A, X) attente
. .
. .
. .
.
La transaction T1 attend La transaction T2 attend
pour prendre un verrou pour prendre un verrou
posé par la transaction T2 posé par la transaction T1
Temps 40
Verrou mortel (Deadlock)
Le graphe d'attente est un graphe orienté dont les
sommets représentent les transactions et les arcs la
relation d'attente entre transactions.

T1 T2

Un verrou mortel (interblocage) lorsque il y a un


circuit dans le graphe d'attente
41
Verrou mortel (Deadlock)

T1 T2

T3

Verrou mortel
T4

42
Résoudre le verrou mortel
 Prévention:
 Verrouiller toutes les données nécessaire à une
transaction avant d'autoriser son exécution.
 Détection:
 Détecter un circuit dans le graphe d'attente. Annuler
une des transactions responsable du blocage.
 Comment choisir la transaction à annuler:
1. La plus jeune
2. La plus vieille
3. Aléatoirement

43
Contrôle de concurrence
Hiérarchie de granules possibles:
BD->Table->Page->Tuple

L'utilisation de granules trop petits multiplie le nombre de


verrous à gérer.
Poser des verrous au niveau des attributs conduit le SGBD à
gérer potentiellement un très grand nombre de verrous et à
réduire ses performances.

L'utilisation de granules trop gros augmente le nombre de


blocages.
Verrouiller toute une table pour modifier un tuple bloque toutes
les transactions voulant accéder à la table.

44
Verrouillage intentionnel
Utiliser des granules de verrouillage de tailles différentes permet de réduire le
nombre de verrous utilisés lorsqu'un grand nombre d'objets est manipulé.

En plus des modes de verrouillage partagé (S) et exclusif (X) le verrouillage


intentionnel offre les modes de verrouillage suivants:

Verrou intention partagé (IS): permet de verrouiller un objet en intention


partagée. Cela indique l'intention de demander des verrous partagées sur des
composant de l'objet verrouillé. Utilisé pour lire certains composants d'un objet.

Verrou intention exclusif (IX): verrouille un objet en mode intention exclusif et


indique que des verrous exclusifs sur des composant de l'objet seront demandés.
Utilisé pour modifier certains composants d'un objet.

Verrou partagé en intention exclusif (SIX): Combinaison d'un verrou partagé et


en intention exclusif. Ce verrou est utilisé pour lire un objet et modifier certains
de ces composants.

45
Matrice de compatibilité

IS IX SIX S X
IS Compatible Compatible Compatible Compatible Incompatible
IX Compatible Compatible Incompatible Incompatible Incompatible
SIX Compatible Incompatible Incompatible Incompatible Incompatible
S Compatible Incompatible Incompatible Compatible Incompatible
X Incompatible Incompatible Incompatible Incompatible Incompatible

46
Verrouillage intentionnel
Aux niveaux de granularité intermédiaires (BD, table,
page) tous les verrous (IS, IX, SIX, S, X) peuvent être
utilisés.

Au niveau de granularité le plus fin (tuple) seuls les


verrous partagé (S) et exclusif (X) sont autorisés.

47
Relation Employé

Num_Employé Nom Prénom Date_Naissance Fonction Salaire


1001 Belaid Toufik 12/05/1965 Concepteur 35000
1009 Touati Rachid 13/09/1941 Chef de projet 55000
1023 Kadri Amine 23/11/1970 Développeur 28000
1053 Djabi Fatiha 04/06/1980 Analyste 23000
1026 Bouras Kamel 19/04/1968 Administrateur 31000
1005 Djabi Fatiha 22/08/1976 Développeur 26500

48
Exemple
UPDATE Employé SET Salaire = Salaire * 1.1
 Verrouiller la table Employé en mode X

UPDATE Employé SET Salaire = Salaire * 1.14 WHERE


Fonction = 'Analyste'
Verrouiller la table en mode SIX
Verrouiller le tuple Num_Employé = 1053 en mode X

SELECT * FROM Employé


Verrouiller la table Employé en mode S
49
Estampillage
Le verrouillage est une méthode de gestion des accès
concurrents pessimiste.

L'estampillage est une méthode optimiste permettant de


gérer les accès concurrent s aux données.

L'estampillage établit un ordre sur les transactions et


consiste à ce que les accès aux données se fassent dans
cet ordre.

50
Estampillage
Chaque transaction dispose d'une estampille (instant de
début, numéro d'ordre).

Chaque objet dispose d'une estampille en lecture (EL) et


d'une estampille en écriture (EE).

EL stocke l'estampille de la transaction la plus jeune


ayant lu l'objet.
EE stocke l'estampille de la transaction la plus jeune
ayant modifié l'objet.

51
Estampillage
Les transactions s'exécutent en parallèle et le système vérifie à chaque
accès à un objet que:
En cas d'accès en lecture: l'estampille EE de l'objet lu doit être <
l'estampille de la transaction qui souhaite le lire.
En cas d'écriture: l'estampille EL et EE de l'objet à modifier doivent être <
l'estampille de la transaction qui souhaite le modifier.

Une transaction souhaitant lire un objet déjà modifié par une transaction
plus jeune, ou souhaitant modifié un objet déjà lu ou modifié par une
transaction plus jeune est une transaction dite "en retard".

Pour garantir qu'une exécution est sérialisable, il faut éliminer les


transactions en retard.

52
Exemple estampillage
Trois transactions T1, T2 et T3 sont lancées dans cet ordre.
L'estampille de T1, T2 et T3 sont respectivement 1, 2 et 3.
A A B B C C
EL EE EL EE EL EE
BEE < BEL
0 0 0 0 0 0
T1 CEL > CEE
1
Lire(A)
Lire(B) T2 1
Lire(A) 2
Lire(B) T3 2
Ecrire(C) 3
Ecrire (B)
1
Lire (C)
2
Ecrire (B)
Temps 3
53
Estampillage
L'estampillage est une solution au problème des accès
concurrents. Elle présente un inconvénient majeur qui
est le risque d'avoir des annulation de transactions en
cascade. Annuler une transaction en retard impose
d'annuler l'ensemble des transactions plus jeunes qui
ont lu des objets qu'elle a modifié (en cascade).

Le verrouillage est la solution utilisée par la totalité des


SGBD.

54
Verrouillage vs. Estampillage
Verrouillage Estampillage
Approche Pessimiste Optimiste
Complexité Importante Simple
(synchronisation
au niveau du
système
d'exploitation)
Surcoût Réduit les Réduit les
performances performances si
dans tous les cas transaction en
retard
Gestion des En cas En cas de retard
conflits d'interblocage une annulation en
seule annulation cacade
permet le
déblocage
55
Multiversionning Oracle
Pour ne pas pénaliser les transactions voulant lire une
donnée en cours de modification, Oracle fournit à
chaque transaction qui veut lire une donnée la version
de la donnée correspondant à sa date de début.

Cette stratégie permet d'améliorer les temps de réponse.

Oracle dispose de l'historique des versions de chaque


donnée en cours de modification.

56
Isolation
 L'isolation est l'une des 4 propriétés ACID que doivent vérifier les
transactions.

 L'isolation des transactions est garantie par une exécution sérialisable


de celles-ci.

 Assurer une exécution sérialisable augmente les temps de réponse et


réduit les performances du système.

 Toutes les applications n'ont pas les mêmes besoins en terme


d'isolation.

 Il est possible de ne pas appliquer totalement la propriété d'isolation


pour augmenter le parallélisme et améliorer les temps de réponse.

57
Degrés d'isolation
La norme SQL2 de l'ISO a normalisé 4 degrés d'isolation:
 Degré 0 (Read Uncommitted): Une donnée en cours
de modification (pas encore validée) peut être vue par
la transaction (lecture sale).
 Degré 1 (Read Committed): Une modification n'est vue
que si elle a été validée.
 Degré 2 (Repeatable Read): Un tuple lu plusieurs fois a
toujours la même valeur.
 Degré 3 (Serializable): Une requête exécutée plusieurs
fois donne toujours le même résultat.

58
Degrés d'isolation
 Degré 0 (Read Uncommitted): garantit la non perte de
mises à jour. Pose des verrous courts exclusifs en écriture.
 Degré 1 (Read Committed): Garantit la cohérence des mises
à jour. Pose de verrous long exclusifs en écriture et courts
partagés en lecture.
 Degré 2 (Repeatable Read): Garantit la reproductibilité des
lectures en posant des verrous longs exclusifs en écriture et
longs partagés en lecture (apparition d possible de tuples
fantômes).
 Degré 3 (Serializable): Garantit la reproductibilité de
requêtes (pas de fantômes). Pose de verrous longs sur de
gros granules de données.
59
Tuples fantômes
Tuples insérés par une transaction et ne pouvant être pris
totalement en compte par une autre transaction.

T1: en mode d'isolation repeatable read (degré 2)


SELECT COUNT(*)
FROM Employé ;  6 tuples //Verrous longs partagés sur les tuples de la table

T2:
INSERT INTO Employé VALUES(7, 'Fareh', 'Salim', '12/10/1977', 'Concepteur', 44000);
COMMIT;

T1:
SELECT COUNT(*)
FROM Employé ;  7

60
Isolation sous Oracle
Oracle n'implémente que 2 degrés d'isolation:
 Read Committed
 Serializable

Beaucoup de SGBDR implémentent les 4 degrés


d'isolation:
PostgreSQL
MySQL (moteur INNODB)
…

61
Isolation sous Oracle
Le degré d'isolation par défaut est read committed.

Pour définir le degré d'isolation d'une transaction:


SET TRANSACTION ISOLATION LEVEL [READ COMMITTED| SERIALIZABLE];

Le degré d'isolation doit être définit au début de la


transaction (avant d'avoir exécuter aucune instruction SQL).

62
Reprise sur panne
Les propriétés d'atomicité et de durabilité des transactions doit être
garantie quelque soit le type de panne pouvant survenir.

En cas de panne:
Annuler les effets des transactions annulées.
Préserver les effets des transactions validées.

Types de pannes:
Transaction failure: annulation, contrainte d'intégrité non respectée …
System failure: panne de courant, panne matériel (ram, cpu) …
Media failure: perte du support de stockage (incendie, vol, virus,
panne…)
Communication failure: défaillance du réseau …

63
Gestion de cache
La reprise sur panne nécessite de savoir à chaque moment quels sont
mises à jours écrites sur disque dur et celles encore en RAM.

Pour modifier des données, il faut les lire à partir du disque dur, les
charger en RAM, les modifier, puis les réécrire dur disque.

La gestion de cache consiste à déterminer à quel moment les pages


modifiées par une transaction (en RAM) doivent être écrites sur disque.

STEAL: Des pages modifiées par une transaction non validée peuvent être
écrites sur disque en remplacement des pages d'origine.

NO-STEAL: Des pages modifiées par une transaction non validée ne


peuvent être écrites sur disque. L'écriture ne se fait qu'aprèsla validation
de la transaction.

64
Gestion de cache
FORCE: Des pages modifiées par une transaction validée
doivent être écrites sur disque.

NO-FORCE: Des pages modifiées par une transaction


validée peuvent ne pas être écrites sur disque. L'écriture
sur disque de ces pages se fait à n'importe quel moment
après la validation de la transaction (pour des raisons
d'optimisation de performances).

65
Gestion de cache
4 politiques de gestion de cache sont possibles:

NO-STEAL/FORCE: politique la plus logique


NO-STEAL/NO-FORCE:
STEAL/FORCE:
STEAL/NO-FORCE: politique la plus souple (permet
d'optimiser les écritures)

66
Atomicité
Les effets de toutes les transaction annulées (transaction
failure, system failure, communication failure) doivent
être effacés.

Deux techniques de mise à jour:


Mise à jour en place (STEAL). Nécessite la mise ne place
d'un journal permettant de revenir à l'état précédent de la
base de données.
Mise à jour dans un espace temporaire (NO STEAL). Pas
de besoin d'effacer les modifications des transactions.

67
Journal des images avant
Le journal des images avant permet de défaire les
modifications faites par les transactions annulées.

Conserve l'historique des mises à jours réalisées par les


transactions en cours (pas encore validées).

Journalisation physique
<Num transaction, numéro page, image page avant>
Journalisation logique
<Num transaction, opération de compensation>
Exemple: T1: Update Employé SET Salaire = Salaire + 100;
<T1, Update Employé SET Salaire = Salaire – 100;>

68
Journal des images avant
Avantages du journal logique:
Plus compact qu'un journal physique (dans la majorité
des cas)
Exploite la commutabilité des opérations logiques

Inconvénients du journal logique:


Reprise sur panne moins rapide
Empêche d'écrire sur disque des éléments de mise à jour
pour une opération logique
Difficulté d'exprimer l'opération inverse pour certaines
opérations complexes.
69
Durabilité
La durabilité consiste à ne pas perdre de mises à jours
validées même en cas de panne.

Types de pannes concernées:


System failure
Media failure
Communication failure

Pour assure la durabilité: Enregistrer les modifications des


transactions validées dans un journal des images après.

70
Journal des images après
Le journal des images après doit être écrit sur disque dès
que la transaction est validée (Force Log At Commit).

Pour garantir la durabilité des mises à jour le journal des


images après doit être stocké sur un disque dur (serveur)
différent de celui stockant la base de données.

71
Reprise sur transaction failure
Lors de l'annulation d'une transaction les actions à
effectuer dépendent de la politique de gestion de cache
utilisée.

Pour assurer l'atomicité de la transaction:


NO-STEAL: Effacer les mises à jour de la transaction dans
le cache (RAM).
STEAL: Effacer les mises à jour de la transaction dans le
cache, ainsi que celles déjà écrites sur le disque.

72
Reprise sur system failure
/Communication failure
En cas reprise sur une panne système (reprise à chaud). Il faut
garantir l'atomicité des transactions non validée et la durabilité des
transactions validées.

Garantir l'atomicité:
NO-STEAL: rien à faire
STEAL: Effacer les modifications reportées sur disque des
transactions non validées au moment de la panne. Utiliser pour cela le
journal des images avant.
Garantir la durabilité:
FORCE: rien à faire
NO-FORCE: rejouer les transactions validées dont les effets n'avaient
pas été écrits sur disque. Utiliser pour cela le journal des images après
sauvegardé au moment des validations.

73
Reprise sur media failure
La reprise d'une perte du support de mémoire secondaire
(reprise à froid) stockant la base de données (disque dur)
ne peut se faire que si une copie de sauvegarde de la base
de données est disponible.

La reprise consiste à charger une copie de la dernière


sauvegarde de la base de données et à rejouer toutes les
transactions depuis cette sauvegarde. Les transactions à
rejouer se trouvent dans le journal des images après.

74
Conclusion
Les transactions permettent:

De maintenir la cohérence de la base de données dans un


contexte d'accès concurrents.

De définir des mécanismes de reprise sur panne.

De faciliter le travail des utilisateurs, développeurs


d'applications et administrateurs de bases de données

75