TP2 - Oracle PL/SQL

Contrôle de bases de données
Isty 2 - 2003/2004
Les transactions – Concurrence, reprise après panne, contraintes d’intégrité
Partie I –Concurrence d’accès
Question I.1
Dire, pour chacune des affirmations suivantes, si elle est vraie ou fausse en justifiant la réponse.
1. Avec un algorithme de verrouillage deux phases, des qu’une transaction lève un verrou, elle ne peut
plus ni lire ni écrire.
Faux. Elle ne peut plus poser de verrou, et pour lire ou écrire, elle doit poser un verrou sur l’objet. Elle peut
donc en théorie lire ou écrire les objets pour lesquels elle détient déjà un verrou. Cependant, dans la
pratique, la libération des verrous n’a lieu qu’en fin de transaction. Des la première libération de verrou,
aucune lecture ou écriture de donnée n’est faite.
2. En verrouillage deux phases, l’abandon d’une transaction peut entraîner l’abandon d’autres
transactions
Faux. L’abandon d’une transaction est exclusivement réservé, dans le cas du verrouillage deux phases, à
résoudre le problème du verrou mortel. Les mises à jour de la transaction abandonnée sont annulées. Or,
aucune autre transaction ne peut avoir lu ou écrit une variable modifiée par cette transaction abandonnée. Il
n’y a donc aucune raison qu’un abandon génère d’autres abandons en cascade.
3. Avec un algorithme d’estampillage, une transaction T1 est abandonnée des qu’elle lit ou écrit un
objet lu ou écrit par T2, plus jeune que transaction T1.
Faux. Une transaction peut lire un objet qui a été lu par T2.
4. Le seul problème de l’algorithme d’estampillage est le fait qu’une transaction puisse mourir N fois
avant de s’exécuter.
Faux. Le problème principal est l’abandon en cascade. Abandonner une transaction mène à abandonner
toutes celles plus jeune qui ont été autorisé à lire ou écrire les objets modifiés par la transaction abandonnée.
Le problème décrit ici (privation) peut être endigué par d’autres techniques algorithmiques (par exemple le
traitement par paquet).
5. Avec l’algorithme d’estampillage, l’abandon d’une transaction à un instant 2 qui a modifié une
donnée à l’instant 1 entraîne l’abandon de toutes les transactions plus jeunes qui ont lu ou modifié
cette donnée entre les temps 1 et 2.
Vrai. C’est le problème de l’abandon en cascade.
Partie II – La gestion du cache de données
On se place dans un contexte ou un serveur de base de données reçoit des requêtes SQL de plusieurs clients. Les
données de la base sont stockées dans 10.000 pages de mémoire secondaire (disque magnétique) du serveur. Le
serveur possède un cache de données de 100 pages en mémoire primaire (RAM).
Chaque page présente dans le cache peut avoir été modifiée par une des transactions. Une structure additionnelle
de type bitmap indique les pages qui ont été modifiées. Chaque page modifiée par rapport à son image sur disque
a une entrée égale à 1 dans le bitmap. La figure suivante présente l’état du bitmap à l’instant t. Seuls les ‘1’ y
sont représentés. Les pages 0, 3, 16, 22 et 99 du cache ont été modifiées par une transaction.
Page 0 à 9 1 1
1
1
1
Page 90 à 99
Figure 1. Bitmap représentant l’état des pages du cache de données

On considère qu’un processus ‘Pflush’ (thread NT ou process UNIX) du serveur est alloué pour reporter des
pages du cache sur disques de manière asynchrone au traitement des requêtes des clients. Ce processus peut
repérer les pages modifiées grâce à la structure bitmap.
Question II.1
a) Si le serveur ne gère pas de journal, et qu’il garantit l’atomicité des transactions des clients avec un
commit atomique, quelles pages le processus ‘Pflush’ peut-il reporter sur disque si le cache est dans
l’état présenté figure 1 ? Justifiez.
Si on ne gère pas de journal, il faut reporter les pages modifiées sur un espace libre du disque avant d’acquiescer
au commit, puis écraser la table des pages en une entrée sortie. Rien n’empêche de flusher les pages modifiées
sur disque. Vu qu’elles sont écrites sur une zone de mémoire libre, l’atomicité n’est pas mise en danger. Pflush
peut donc reporter sur disque toutes les pages modifiées du cache, même avant la demande de validation, pour
répartir les I/O dans le temps.
b) Et si le serveur maintient un journal avant ?
Si le serveur maintient un journal avant, on peut reporter les pages modifiées sur disque en lieu et place des
pages avant modification, à condition que la page du cache contenant le journal (les valeurs avant modification
élémentaires de chaque page) soit reportée avant pour éventuellement défaire les mises à jour.
Le serveur reçoit la demande de validation (commit) de la transaction Ti.
Question II.2
a) Si le serveur ne gère pas de journal, quelles pages le processus ‘Pflush’ doit-il reporter sur disque pour
garantir la durabilité des transactions face à la reprise à chaud ? Justifiez.
Il doit reporter toutes les pages modifiées dans une zone libre de la mémoire et écraser la table des pages. La
durabilité est ainsi assurée.
b) Et si le serveur maintient un journal après ?
Il doit écrire sur disque les modifications faites dans la page de journal après présente en cache au commit de la
transaction, si celle ci a fait des modifications depuis le dernier report du journal après. Toutes les autres pages
modifiées peuvent rester en cache.
Partie III – Politique STEAL/NO FORCE et reprise après panne
On suppose maintenant que le serveur gère un journal avant et un journal après. Il y a donc une page disponible
en RAM pour chaque journal.
La figure suivante représente les structures de données de la mémoire primaire :
1. La structure bitmap indiquant les pages de données modifiées par rapport à leur image sur disque
2. Les 5 pages de données
3. Une page pour le journal d’images avant et une autre pour le journal d’images après
1 1
1
1
1
Bitmap
Cache de données Journal après
Journal avant
Figure 2. Contenu de la mémoire primaire
Supposons que A,B,C,D,E,F,G,H,I et J soient des articles de la base de données, valant tous 0, contenus deux par
deux sur disque dans 5 pages distinctes. A et B sont stockés dans une même page, de même que C et D, E et F, G
et H, I et J. Supposons que le cache de données est vide au départ, ainsi que les pages de la mémoire primaire
allouées aux journaux.

Les modifications suivantes sont opérées sur les objets présents dans le cache, selon les commandes des
transactions T1 à T5, dans l’ordre indiqué. Ces modifications sont présentées figure 3.
Valeur des objets Journal avant Journal après temps Réponse
serveur
type
I/O
commandes
cache disque disque cache disque cache
0 Début T1 à T5
1 T1 : update (A,10) AÅ10
2 T2 : update (B,10) BÅ10
3 T3 : update (C,10) CÅ10
4 T4 : update (D,10) DÅ10
5 T1 : update (F,10) FÅ10
6 fin T1
7 T5 : update (E,10) EÅ10
8 T2 : update (G,10) GÅ10
9 T3 : update (H,10) HÅ10
10 fin T2
11 fin T3
12 T4 : update (I,10) IÅ10
13 T5 : update (J,10) JÅ10
14 fin T4
15 fin T5
16
Figure 3. Evolution des objets de la base de données
NB : ‘T1 : E(A,10)’ signifie que la transaction 1 demande à écrire 10 dans l’article A.
Les pages en mémoire primaire dédiées aux journaux peuvent contenir chacune 6 articles au maximum, chacun
d’entre eux correspondant à la modification élémentaire d’une transaction. Les marques de début et de fin de
transaction (begin et commit) seront considérées ici comme étant de taille 1/6 d’article pour le stockage dans les
journaux.
Question III.1
Supposons qu’aucune autre transaction que T1 à T5 ni aucune autre requête SQL que celles présentées figure 3
ne provienne au serveur. En répartissant au maximum le nombre d’entrées sorties entre les mémoires primaire et
secondaire par unité de temps (par ligne du tableau), remplir le tableau ci-dessus. Toutes les pages doivent être
reportées sur disque à temps=16. De plus, vous essayerez de répartir le plus possible les entrées sorties disque
dans le temps, c’est à dire d’avoir une seule entrée sortie par ligne du tableau. Vous devez aussi indiquer la
réponse que le serveur renvoie aux clients, il peut y avoir plusieurs envois de réponse par ligne du tableau. Vous
essayerez de minimiser le temps de réponse du serveur au client, en essayant de répondre aux requêtes au plus
tard la ligne suivant la réception de la requête.
Valeur des objets Journal avant Journal après temps Réponse
serveur
Nb
I/O
commandes
cache disque disque cache disque cache
0 Début T1 à T5
1 Upd. ok 1 R T1 : update (A,10) AÅ10 T1 : A=0 T1 : A=10
2 Upd. ok 1 J- T2 : update (B,10) BÅ10 T1 : A=0
T2 : B=0
T2 : B=0 T2 : B=10
3 Upd. ok 1 R T3 : update (C,10) CÅ10 T3 : C=0 T3 : C=10
4 Upd. ok 1 W T4 : update (D,10) DÅ10 A=10
B=10
T4 : D=0 T4 : D=10
5 Upd. ok 1 R T1 : update (F,10) FÅ10 T1 : F=0 T1 : F=10
6 val1. ok 1 J+ fin T1 T1 : end T1 : A=10
T2 : B=10
T1 : end

T3 : C=10
T4 : D=10
T1 : F=0
T1 : end
7 Upd. ok 1 J- T5 : update (E,10) EÅ10 T3 : C=0
T4 : D=0
T1 : F=0
T1 : end
T5 : E=0
T5 : E=0 T5 : E=10
8 Upd. ok 1 R T2 : update (G,10) GÅ10 T2 : G=0 T2 : G=10
9 Upd. ok 1 W T3 : update (H,10) HÅ10 C=10
D=10
T3 : H=0 T3 : H=10
10 1 W fin T2 E=10
F=10
T2 : end T2 : end
11 val2. ok
val3. ok
1 J+ fin T3 T3 : end T5 : E=10
T2 : G=10
T3 : H=10
T2 : end
T3 : end
T3 : end
12 Upd. ok 1 R T4 : update (I,10) IÅ10 T4 : I=0 T4 : I=10
13 Upd. ok 1 J- T5 : update (J,10) JÅ10 T2 : G=0
T3 : H=0
T2 : end
T3 : end
T4 : I=0
T5 : J=0
T5 : J=0 T5 : J=10
14 1 W fin T4 G=10
H=10
T4 : end
15 val4. ok
val5. ok
1 J+ fin T5 T4 : I=10
T5 : J=10
T4 : end
T5 : end
T5 : end
16 1 W I=10
J=10
Question III.2
Montrez que votre solution permet de garantir atomicité et durabilité en supposant
a) Qu’une coupure de courant survient à temps=10, et que le serveur redémarre ensuite.
Si une coupure de courant intervient à temps=10, on perd toute la mémoire primaire. Le SGBD a acquiescé à la
demande de validation de T1, il doit donc assurer sa durabilité. T1 a modifié A et F (A=10 et F=10), ces deux
modifications doivent donc se trouver dans la base. A=10 est déjà présente sur disque, mais F=10 doit être
refaite. Pour cela, le journal après sur disque est utilisé. On a sur disque dans le journal le fait que T1 a validé (et
elle seule). Les valeurs A=10 et F=10 sont ainsi modifiées sur disque.
Toutes les autres transactions doivent être annulées. Les modifications présentes dans la base (C=10 et D=10)
doivent être défaites. Le système sait grâce au journal avant sur disque que les transactions T2, T3, T4, T5 n’ont
pas validées. Les valeurs avant (B,C,D,E =0) sont utilisées pour défaire les modifications.
b) Qu’un crash disque survient à temps=14.
De même, si le crash survient à temps=14, le SGBD a acquiescé aux demandes de validation de T1, T2, T3. Il
doit donc assurer leur durabilité. Les effets de T4 et T5 doivent être annulés du disque. Le journal après contient
effectivement les balises de fin de transaction pour T1, T2, T3, le SGBD sait donc que ces transactions doivent
être refaites. A, B, C, F, G, H doivent donc valoir 10 sur le disque de la BD. Si la panne a lieu au début de T14,
Les valeurs de G et H n’ont pu être reportées, elles peuvent être refaites à partir du journal après. Le journal
avant contient les images avant de T4 et T5. Ces informations permettent de défaire G=10 et H=10, les
modifications présentes sur disque de ces deux transactions.