3 - Gestion Des Transactions

Gestion des transactions
Sécurité de fonctionnement et
accès concurrents
 Une base de données est accédée par plusieurs utilisateurs

ou programmes en même temps  les SGBD comportent
un sous-système de gestion des accès concurrents
 Techniques qui s'inspirent de celles développées pour les
systèmes d'exploitation (verrouillage, exclusion mutuelle)
 Transaction : tout programme qui accède à la base ou qui
en modifie le contenu (suite de lectures/écritures)
2
EST Fès Administration des Bases de données
Les menaces
 Problèmes de concurrence
– pertes d ’opérations
– introduction d ’incohérences
– verrous mortels (deadlock)
 Panne de transaction
– erreur en cours d'exécution du programme applicatif
– nécessité de défaire les mises à jour effectuées
 Panne système
– reprise avec perte de la mémoire centrale
– toutes les transactions en cours doivent être défaites
 Panne disque
– perte de données de la base
3
Propriétés des transactions
 Atomicité
– Unité de cohérence : toutes les mises à jour doivent être effectuées ou
aucune.
 Cohérence
– La transaction doit faire passer la base de donnée d'un état cohérent à un
autre.
 Isolation
– Les résultats d'une transaction ne sont visibles aux autres transactions
qu'une fois la transaction validée.
 Durabilité
– Les modifications d ’une transaction validée ne seront jamais perdue
4
Commit et Abort (ROLLBACK)
 INTRODUCTION D’ACTIONS ATOMIQUES
– Commit (fin avec succès) 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
– Annulation de la transaction
– Défait toutes les mises à jour de la transaction
5
Schéma de transaction simple
 Fin avec succès ou échec
 Begin_Transaction
– update
- Provoque l'intégration réelle des mises
– update à jour dans la base
- Relâche les verrous
– .....
– Commit ou Abort
- Provoque l'annulation des mises à jour

- Relâche les verrous
- Reprend la transaction
6
Effet logique
Mémoire de la
transaction
Update
Update
Abort
Commit
Bases de données Poubelle
7
Problèmes liés aux transactions :
non atomicité
Virement d'un montant m d'un compte C1 vers un compte C2 :
Début
x  Lire(C1)
xx-m
Pb : Si le programme s'arrête avant
C1  Ecrire(x)
l'écriture de y dans C2, la base entre
y  Lire(C2) dans un état incohérent
yy+m
C2  Ecrire(y)
Fin
 Transaction = unité atomique d'actions
(si la transaction n'a pas pu exécuter toutes ses actions, la base est remise dans l'état
où elle se trouvait avant le début de la transaction)
8
non isolation
T1 inscrit un débit N sur un solde X et T2 inscrit un crédit M sur X :
Ex : X = 100, N = 10, M = 50
Résultat attendu : 100-10+50 = 140
Actions X x y
T1 T2 T1: x  Lire(X) 100 100
x  Lire(X) y  Lire(X) T1: x  x - N 100 90
xx-N yy+M T2: y  Lire(X) 100 90 100
X  Ecrire(x) X  Ecrire(y) T2: y  y + M 100 90 150
T1: X  Ecrire(x) 90 90 150
T2: X  Ecrire(y) 150 90 150
 Il faudrait que T1 travaille en isolation,Pb : l'opération

c'est-à-dire de débit estavec
sans interférence perdue !
d'autres transactions, jusqu'à sa terminaison
9
non cohérence
Ex : on impose la CI (A = B)
Actions de T1 Actions de T2
t11 : AT1  Lire(A) t21 : AT2  Lire(A)
t12 : AT1  AT1 + 1 t22 : AT2  AT2  2
t13 : A  Ecrire(AT1) t23 : A  Ecrire(AT2)
t14 : BT1  Lire(B) t24 : BT2  Lire(B)
t15 : BT1  BT1 + 1 t25 : BT2  BT2  2
t16 : B  Ecrire(BT1) t26 : B  Ecrire(BT2)
Pb : chaque transaction satisfait la contrainte, mais leur
exécution concurrente peut la violer
Ex : <t21; t22; t11; t12; t23; t13; t14; t15; t16; t24; t25; t26>
10
non permanence des modifications
 Non répétabilité des lectures
Transaction T1 Transaction T2
a  Lire(A)
b  Lire(A)
Imprimer(b) Pb : les impressions de T2
a  a + 100 produiront des valeurs
A  Ecrire(a) différentes
b  Lire(A)
Imprimer(b)
11
non permanence des modifications
 Tuples "fantômes"
Transaction T1 Transaction T2
S  Lire(A), A = {a | a < 4000} V  Lire(A), A={a | a < 4000}
Pb : La deuxième impression de V rend un ensemble vide
Imprimer(V)
Les modifications des données par T1 ne sont pas répercutées dans la base avant leur utilisation par T2
Pour chaque s, s  S : a = 5000
A  Ecrire(S)
V  Lire(A), A={a | a < 4000}
Imprimer(V)
12
Plusieurs outils pour résoudre ces
problèmes
 Le sous-système d'intégrité : permet de détecter les

incohérences prévues par le programmeur (CI)
 Le sous-système de reprise : permet d'assurer l'atomicité

des transactions et la cohérence de la base en cas d'accident
 Le sous-système de contrôle de la concurrence : permet de

contrôler les accès concurrents aux données par la
technique des "verrous"
13
Atomicité des transactions :
politique du "tout ou rien"
BEGIN TRAN MaTransaction

Action1
...
Action n
Si toutes les actions se sont bien passées
Alors COMMIT TRAN Valide la transaction
Sinon ROLLBACK TRAN
Annule les effets de la

transaction
14
Utilisation de points de
sauvegarde
BEGIN TRAN MaTransaction

{Séquence 1 d'actions}
SAVE TRAN Point1
SAVE TRAN Point2
ROLLBACK TRAN Point2 Annule les effets de Séquence 3
ROLLBACK TRAN Annule les effets de toutes les
séquences
15
Exemple
Transaction ComprendreLesTransactions à partir des
tables suivantes :
Etudiant Resultat Matiere

Et# Nom Et# Mat# Moy Mat# Libelle
E1 Bastian E1 M1 10 M1 BD
E2 Boutantin E1 M2 12 M2 Réseaux
E3 Chabot E2 M3 14 M3 Système
E2 M2 14 M4 Malg
E3 M3 15
E2 M4 14
16
Transactions imbriquées
BEGIN TRAN
...
BEGIN TRAN
...
BEGIN TRAN
...
COMMIT/ROLLBACK TRAN
...
...
Il y a annulation des effets de toutes les transactions si une des transactions filles ou si la
transaction mère échoue
17
Le journal des transactions
 Pour pouvoir procéder à la reprise en cas d'accident, le

système garde une trace (journal ou log) des opérations
(transactions) effectuées sur la base
 Le journal est conservé sur un support non volatile (disque,

bande) et doit être archivé périodiquement
18
Le journal des transactions
 Pour chaque transaction T, le journal comporte :
– <début_transaction, identification de T>
– <écriture, identification de T, donnée concernée, ancienne valeur,
nouvelle valeur>
– <lecture, identification de T, donnée concernée>
– <COMMIT, identification de T>
 Ainsi si un accident se produit, le système peut

– annuler (UNDO) les effets des transactions non validées
– refaire (REDO) les actions des transactions validées
19
Reprise en cas d'accident
 Reprise (recovery) : reconstruire un état cohérent de la base à
partir du passé, cet état devant être le plus proche possible de l'instant
où s'est produit l'incident  utilisation du journal des transactions
 La stratégie de reprise dépend de la gravité de l'incident

qui la provoque :
– Reprise à froid : pour des dégâts importants, on recharge une
sauvegarde de la base et on ré-exécute (REDO) les transactions
marquées valides dans le journal, depuis la date de la sauvegarde
– Reprise à chaud : pour des dégâts moins importants, on défait
(UNDO) les actions des transactions non validées
20
Contrôle de la concurrence et
plan d'exécution
Un plan d'exécution P de n transactions est un ordre sur les
opérations des transactions tel que pour toute transaction Tk
participant à P, si une opération Oi précède une opération Oj
dans Tk, alors Oi précède aussi Oj dans P
 L'objectif du contrôle de la concurrence est de n'autoriser
que les plans d'exécution corrects
Exemple : problème du transparent 62
– <t11; t12; t13; t21; t22; t23; t14; t15; t16; t24; t25; t26> est un plan
d'exécution correct
– <t21; t22; t11; t12; t23; t13; t14; t15; t16; t24; t25; t26> est un plan
d'exécution incorrect
21
Plan d'exécution sérialisable
 Un plan d'exécution P des transactions T1, ..., Tn est une
succession s'il existe une permutation  de (1, ..., n) telle que
P = <T (1) ; ...; T (n)>
 Une exécution des transactions T1, ..., Tn est sérialisable ssi

elle donne, pour chaque Ti, le même résultat qu'une
succession
 Le problème revient à ce que ne soient autorisées que des

exécutions sérialisables
22
Contrôle de la concurrence : la
technique du verrouillage
Granule = unité d'accès (BD, relation, tuple, attribut ...)
 Verrou binaire : un granule est accessible ou inaccessible
 Verrou partagé et verrou exclusif : en lecture un verrouillage en mode
partagé (share) permet des accès multiples à un granule. Par contre, en
écriture, il est nécessaire de verrouiller le granule en mode exclusif (exclusive)
 Verrou d'intention ou verrou de mise à jour (update) : verrou de lecture
avec intention d'écriture
Compatibilité des verrous : verrous demandés sur le même granule

Share Exclusive Update
verrous Share oui non non
apposés sur Exclusive non non non
un granule Update oui non non
23
Les quatre niveaux d'isolation
SQL-92 (1/2)
 Niveau 0 (READ UNCOMMITTED)
Une transaction T peut lire des objets modifiés par une autre
transaction, pas de verrou en mode lecture
 risque de lectures impropres, lectures non reproductibles et
tuples fantômes
 Niveau 1 (READ COMMITED)

= niveau 0, sauf : T lit uniquement les mises-à-jour des transaction
validées (verrou exclusif en écriture)
 plus de risque de lectures impropres
24
Les quatre niveaux d'isolation
SQL-92 (2/2)
 Niveau 2 (REPEATABLE READ)

= niveau 1, sauf : aucun objet lu par T ne peut être modifié par une autre
transaction (verrou partagé en lecture)
 plus de risque de lectures non reproductibles
 Niveau 3 (SERIALIZABLE)
= niveau 2, sauf : possibilité de poser des verrous sur un ensemble d'objets
 plus de risque de tuples fantômes
25
Application au SGBD Sybase
 Sybase ne supporte que les niveaux d'isolation 0, 1 et 3
 Pour une transaction ou une session, un utilisateur peut
choisir un des niveaux :
set transaction isolation level {0 | 1 | 3}
 Un niveau d'isolation peut aussi être fixé pour l'exécution

d'une seule requête :
select * from T at isolation {read uncommited |
read commited | serializable}
26
Les verrous : problèmes
 Inter-blocage
T1 détient le granule G1 et attend que T2 libère G2

pendant que T2 attend la libération de G1
 Famine
Une transaction est perpétuellement en attente alors que

d'autres continuent à s'exécuter
27
Exemple
begin tran
begin tran
set isolation level 0
<111> select * from T
insert into T values (12)
<111,12> select * from T
commit tran
begin tran
select * from T <111,12>
insert into T values (34) Attente commit

select * from T
commit tran
select * from T <111,12,34>
begin tran ...
select * from T at Verrou
Verrou select * from V for isolation serializable
sur T
sur V Attente
update
insert into V values (56) sur V
Attente
insert into T values (78)
sur T select * from V
select * from T
temps Interblocage ! 28
Solutions pour l'inter-blocage
 La prévention : imposer à toute transaction de verrouiller en avance
tous les éléments dont elle a besoin (n'apposer aucun verrou si un de
ces éléments n'est pas libre)
 La détection : tester périodiquement si une situation d'inter-blocage
s'est produite (solution implémentée dans Sybase) :
– détection de cycles dans un graphe d'attente, dont les nœuds représentent
les transactions et les arcs la relation est_en_attente_de
– si une telle situation se produit, une des transactions impliquée est avortée
T1 T3 - T1 détient R1 et attend R2
- T2 détient R2 et attend R3
T2 - T3 détient R3 et attend R1
29
Solutions pour la famine
Cette situation se produit si la priorité est toujours donnée aux

mêmes transactions 
– avoir un mécanisme de type "premier arrivé, premier servi" (First In
First Out)
– adopter une stratégie avec priorité dynamique
– Sybase : après trois tentatives infructueuses de satisfaction d'une

demande d'apposition d'un verrou exclusif, toute nouvelle demande
de verrou partagé est refusée
30
Journaux et Sauvegarde
 Journal des images avant
– Journal contenant les débuts de transactions, les valeurs
d'enregistrement avant mises à jour, les fins de transactions
(commit ou abort)
– Il permet de défaire les mises à jour effectuées par une transaction
 Journal des images après

– Journal contenant les débuts de transactions, les valeurs
d'enregistrement après mises à jour, les fins de transactions
(commit ou abort)
– Il permet de refaire les mises à jour effectuées par une transaction
31
Journal des images avant
 Utilisé pour défaire les mises à jour : Undo
2.Log
Page lue Page modifiée

3.Update
1.Read 4.Write
Base de données
32
Journal des images après
 Utilisé pour refaire les mises à jour : Redo
3.Log
Page lue Page modifiée
2.Update
1.Read 4.Write
Base de données
33
Gestion du journal
 Journal avant et après sont unifiés
 Écrits dans un tampon en mémoire et vider sur disque en début de
commit
 Structure d'un enregistrement :
– N° transaction (Trid)
– Type enregistrement {début, update, insert, commit, abort}
– TupleId
– [Attribut modifié, Ancienne valeur, Nouvelle valeur] ...
 Problème de taille
– on tourne sur N fichiers de taille fixe
– possibilité d'utiliser un fichier haché sur Trid/Tid
34
Sauvegarde
 Sauvegarde périodique de la base
– toutes les heures, jours, ...
– Doit être effectuée en parallèle aux mises à jour
 Un Point de Reprise (checkpoint) est écrit dans le journal pour le
synchroniser par rapport à la sauvegarde
– permet de situer les transactions effectuées après la sauvegarde
 Pose d'un point de reprise :
– écrire les buffers de journalisation (Log)
– écrire les buffers de pages (DB)
– écrire un record spécial "checkpoint" dans le journal
35
Scénarios de Reprise
 Les mises à jour peuvent être effectuées directement dans
la base (en place)
– la base est mise à jour immédiatement, ou au moins dès que
possible pendant que la transaction est active
 Les mises à jour peuvent être effectuées en mémoire et
installées dans la base à la validation (commit)
– le journal est écrit avant d'écrire les mises à jour
36
Stratégie do-undo
 Mises à jour en place
– l'objet est modifié dans la base
 Utilisation des images avant

– copie de l'objet avant mise à jour
– utilisée pour défaire en cas de panne
2. LogPage
Update Mémoire Journal avant
cache
3. WritePage
1. LirePage Undo
Base
37
Stratégie do-redo
 Mises à jour en différentiel
– l'objet est modifié en page différentielle (non en place/journal)
 Utilisation des images après

– copie de l'objet en journal après mise à jour (do)
– utilisée pour refaire en cas de panne (redo)
3. LogPage
Update Journal après
Mémoire
cache
2. WritePage
1. LirePage Redo
Base Ombre
Commit 38
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 mémoire
– le vidage sur disque s'effectue en différé (processus E/S)
 Synchronisation journaux / base

– le journal doit toujours être écrit avant modification de la base !
39
Commits bloqués
 AFIN D'EVITER 3 E/S POUR 1:
– Le système 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'améliorer les
performances lors des pointes sans faire attendre trop sensiblement
les transactions
40
Reprise à froid
 En cas de perte d'une partie de la base, on repart de la
dernière sauvegarde
 Le système retrouve le checkpoint associé
 Il ré-applique toutes les transactions commises depuis ce
point
– (for each committed Ti : redo (Ti))
41
Modèles étendus
 Applications longues composées de plusieurs transactions
coopérantes
 Seules les mises-à-jour sont journalisées
 Si nécessité de défaire une suite de transactions:

– contexte ad-hoc dans une table temporaire
– nécessité d'exécuter des compensations
42
Points de Sauvegardes
 Introduction de points de sauvegarde intermédiaires
– (savepoint, commitpoint)
 Begin_Trans
– update
unité d'oeuvre
– update
– savepoint Non perte du contexte
– update unité d'oeuvre

– update
 Commit
43
Transactions Imbriquées Begin(T)
 OBJECTIFS Begin(t'1) Begin(t1)
– Obtenir un mécanisme de
reprise multi-niveaux
– Permettre de reprendre des Commit(t1)
parties logiques de transactions Commit(t'1) Commet t1
– Faciliter l'exécution parallèle Begin(t2)

de sous-transactions Begin(t21)
 SCHEMA
– Reprises et abandons partiels
Commit(t21)
– Possibilité d'ordonner ou non Abort(t2)
les sous-transactions
Commit(T) Annule t2 et t21
44
Conclusion
 Des techniques complexes
 Un problème bien maîtrisé dans les SGBDR
 La concurrence complique la gestion de transactions
 Les transactions longues restent problématiques
 Enjeu essentiel pour le commerce électronique
– validation fiable
– reprise et copies
– partage de connections
– partage de charge
45
Optimisation des performances
Adaptation des modèles logiques
 Adapter les schémas logiques (SLD et SLT) dans le but de

réduire le coût d'implantation de la base
 Facteurs à prendre en compte :

– volume des données
– nombre d'accès à la base
– coût des traitements (supposé négligeable par rapport au coût des

lectures - écritures dans la base)
47
Evaluation des volumes (1/2)
 Taille d'une relation représentant un type d'entité :
– attribut : nombre de caractères nécessaires à sa représentation
– n-uplet : somme des tailles de ses types d'attributs
– relation : produit du nombre d'occurrences du type d'entité par la
taille du n-uplet de la relation
 Exemple :
Attribut Type Taille
no_ass entier 10 Si 10000 assurés sont attendus sur une
nom_ass chaîne 30 période de deux ans, l'estimation de la
adr_ass chaîne 40 taille de la relation est de
te_ass chaîne 10 10000(10+30+40+10+10)  1Mo
no_agence entier 10
48
Evaluation des volumes (2/2)
 Taille d'une relation représentant un type d'association :
suppose connu le nombre moyen d'occurrences des types d'entité

associés
 Exemple :
" Un produit est stocké en moyenne dans 3 dépôts "
 taille de la relation stock = taille d'un n-uplet de stock  3 

nombre de produits
49
Optimisation des volumes
Seul type d'optimisation possible : compression des types
d'attributs
 perte de lisibilité et coût supplémentaire dû au processus
de compression et de décompression
50
Evaluation du coût des
traitements
 Dépend du type des opérations de base (recherche, insertion,
suppression, modification)
 Processus d'évaluation et d'optimisation :

1. évaluer le coût de chaque type d'opération (SLD et SLT  fréquence
de chaque opération, objets concernés et actions élémentaires à
effectuer sur ces objets)
2. identifier les opérations les plus coûteuses
3. essayer d'en réduire le coût
51
Coût de la recherche d'un n-uplet
(1/2)
 La recherche d'un n-uplet dans un ensemble de n n-uplets
coûte :
– 1 accès si un mécanisme d'accès direct existe
– en moyenne n/2 accès sinon
52
Coût de la recherche d'un n-uplet
(2/2)
 Remarques :
– coût d'un accès direct < coût d'un accès séquentiel
 créer des index

– coût d'une recherche dans un ensemble ordonné < coût d'une
recherche dans un ensemble non ordonné
 ordonner les instances

– coût d'une lecture < coût de plusieurs lectures
 fusionner des relations, introduire de la redondance ou grouper

physiquement des occurrences (clustering)
53
Coût de l'ajout d'un n-uplet
 Insertion :
– écriture dans la base
– mise à jour éventuelle des index existant sur la relation concernée
 Coût :
– 1 écriture si la relation n'est pas ordonnée
– n/2 lectures en moyenne pour la recherche du point d'insertion si

la relation est ordonnée
54
Coût de la modification d'un
n-uplet
 Modification :
– recherche dans la base
– modification en mémoire centrale
– réécriture dans la base
 Coût :
– coût d'une recherche
– coût d'un ajout
– (éventuellement) coût du maintien d'ordre
– (éventuellement) coût de mise à jour d'index
– (éventuellement) coût de mise à jour de données redondantes
55
Coût de la suppression d'un
n-uplet
 Suppression :
– recherche du tuple à supprimer
– mise-à-jour éventuelle d'index
– autres suppressions, dans le cas de données redondantes
 Coût :
– coût d'une recherche
– (éventuellement) coût de la maintenance des index
– (éventuellement) coût de la suppression des données redondantes

56
Optimisation des traitements
 Index et critères d'ordre
 Redondance et dénormalisation de relations
 Ajout de nouveaux types d'attributs
 Fusion de relations
 Fragmentation verticale de relations
57
Rappel sur les index
 Index : structure de données qui associe à une valeur d'un
attribut, appelé clé de l'index, la ou les adresses des tuples
contenant cette valeur
Possible pour un attribut non
clé de la relation
 Exemple :
1 1
3 3
1 7
5
1
7
12
7 7
12 5
1
Espace index Espace données
58
Choix des index et des critères
d'ordre
 Opérations d'interrogation :
attributs de sélection et de jointure
 Opérations de mise à jour :
attributs de sélection
pas les attributs à modifier car cela entraînerait un coût

supplémentaire pour la maintenance
59
Redondance et dénormalisation
de relations
 Exemple : Expert
chargé du
Expert(no_exp, nom_exp, ...) dossier
Sinistre(no_dossier, ..., no_exp)
Si le nom de l'expert est accédé à chaque référence à un sinistre 
Sinistre(no_dossier, ..., no_exp, nom_exp)
Viole la 3NF de Sinistre, mais permet de faire l'économie de
l'opération de jointure pour obtenir le nom
 accroissement de l'espace de stockage et de l'activité en

mise à jour
60
Ajout de nouveaux types
d'attributs
 Exemple :
" L'expert désigné pour un dossier de sinistre est celui qui a le moins de
dossiers en cours d'instruction "
 nécessite le parcours de la relation sinistre avec comptage et
recherche du no_exp ayant le plus petit nombre de dossiers puis
accès à la relation Expert pour connaître ses coordonnées
 Expert(no_exp, nom_exp, ..., nb_dossiers-en_cours)
 Attention à la cohérence de la base :

incrémenter nb_dossiers-en_cours à chaque fois que l'expert est
désigné, et décrémenter quand le dossier est clos
61
Fusion de relations
clé1 ... clé2 ...

1-1 1-1
E1 E2
RE1(clé1, ...)
RE2(clé2, ...)
 si jointures très fréquentes de RE1 et RE2, fusionner en une
seule relation
62
Fragmentation verticale de
relations
 Quand une relation comporte un grand nombre d'attributs,

dont seul un sous-ensemble est fréquemment utilisé, on
peut la décomposer en deux relations
 Exemple :
R(cléR, utilisé1, utilisé2, peu_utilisé1, peu_utilisé2,
peu_utilisé3)
 R1(cléR, utilisé1, utilisé2)
R2(cléR, peu_utilisé1, peu_utilisé2, peu_utilisé3)
63
Exemple : coût de l'opération
Ouvrir_dossier
Pour 10000 dossiers et 20 experts :
P1 Vérifier _déclaration Recherche de l'assuré  10000/2 accès
P2 Attribuer_no_dossier Accès au dernier numéro de dossier affecté  1 accès
P3 Enregistrer_dossier Ecriture du nouveau dossier  1 accès
P4 Désigner_Expert Recherche de l'expert  20 / 2 accès

Ajout d'un dossier à la relation Sinistre  1 accès
P5 Transmettre_dossier Total : 5013 accès  50 sinistres par jour  260 jours

ouvrés  coût annuel de 65.106 accès
64
Coût de l'opération
Ouvrir_dossier optimisée
 Si on décide de :
– conserver en mémoire le dernier numéro de dossier pendant toute une
journée de travail
– indexer les assurés sur leur numéro de police
– indexer les experts sur le nombre de dossiers en cours avec ordre
 Nouveau coût :
260 jours  (1 accès au dernier numéro de dossier + 50
sinistres  (1 pour
la recherche de l'assuré +1
pour l'écriture du nouveau dossier +1
pour la recherche de l'expert +1
pour l'ajout d'un sinistre)) = 52.103 accès / an
65

3 - Gestion Des Transactions

Transféré par

Droits d'auteur :

Formats disponibles

3 - Gestion Des Transactions

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

3 - Gestion Des Transactions

Transféré par

Droits d'auteur :

Formats disponibles

Gestion des transactions

 Une base de données est accédée par plusieurs utilisateurs

- Provoque l'annulation des mises à jour

Bases de données Poubelle

 Il faudrait que T1 travaille en isolation,Pb : l'opération

 Le sous-système d'intégrité : permet de détecter les

 Le sous-système de reprise : permet d'assurer l'atomicité

 Le sous-système de contrôle de la concurrence : permet de

BEGIN TRAN MaTransaction

Annule les effets de la

BEGIN TRAN MaTransaction

Etudiant Resultat Matiere

 Pour pouvoir procéder à la reprise en cas d'accident, le

 Le journal est conservé sur un support non volatile (disque,

 Ainsi si un accident se produit, le système peut

 La stratégie de reprise dépend de la gravité de l'incident

 Une exécution des transactions T1, ..., Tn est sérialisable ssi

 Le problème revient à ce que ne soient autorisées que des

Compatibilité des verrous : verrous demandés sur le même granule

 Niveau 1 (READ COMMITED)

 Niveau 2 (REPEATABLE READ)

 plus de risque de lectures non reproductibles

 plus de risque de tuples fantômes

 Un niveau d'isolation peut aussi être fixé pour l'exécution

T1 détient le granule G1 et attend que T2 libère G2

Une transaction est perpétuellement en attente alors que

insert into T values (34) Attente commit

Cette situation se produit si la priorité est toujours donnée aux

– Sybase : après trois tentatives infructueuses de satisfaction d'une

 Journal des images après

Page lue Page modifiée

Page lue Page modifiée

 Utilisation des images avant

 Utilisation des images après

 Bufferisation des bases

 Synchronisation journaux / base

 Seules les mises-à-jour sont journalisées

 Si nécessité de défaire une suite de transactions:

– update unité d'oeuvre

 OBJECTIFS Begin(t'1) Begin(t1)

– Faciliter l'exécution parallèle Begin(t2)

 Adapter les schémas logiques (SLD et SLT) dans le but de

 Facteurs à prendre en compte :

– nombre d'accès à la base

– coût des traitements (supposé négligeable par rapport au coût des

 Taille d'une relation représentant un type d'association :

suppose connu le nombre moyen d'occurrences des types d'entité

" Un produit est stocké en moyenne dans 3 dépôts "

 taille de la relation stock = taille d'un n-uplet de stock  3 

Seul type d'optimisation possible : compression des types

 perte de lisibilité et coût supplémentaire dû au processus

 Processus d'évaluation et d'optimisation :

2. identifier les opérations les plus coûteuses

3. essayer d'en réduire le coût

 La recherche d'un n-uplet dans un ensemble de n n-uplets

– 1 accès si un mécanisme d'accès direct existe

– en moyenne n/2 accès sinon

 créer des index

 ordonner les instances