Вы находитесь на странице: 1из 38

Bases de donnes

Giovanna Di Marzo Serugendo


Giovanna.Dimarzo@unige.ch, room B 235, 022 379 00 72

University of Geneva
http://cui.unige.ch/~dimarzo Transparents en partie emprunt au Prof. Lonard (unige) / Prof. Stockinger (epfl)

Admin Information

Heure et lieu

Dokeos

Printemps 2011 Batelle, BAT 403 Lundi: 10h00 - 12h00 Cours Lectures supplmentaires

Evaluation
2

33%: TPs 66%: Examen crit

Agenda
Mcanisme de transactions des SGBD
Transactions, proprits ACID Gestion de la concurrence, verrous Reprise aprs erreur

Principes des systmes rpartis appliqus aux bases de donnes


Rpartition, duplication
3

Sommaire
Rappels Transactions Proprits ACID

Atomicit, Cohrence, Isolement, Durabilit

Concurrence

Entrelacement, Srialisabilit Verrous (Locks) Etreinte fatale (Deadlock)

Recovery (recupration des erreurs)


4

Commit / Abort / Rollback / Checkpoints

Rappel: Table
Table
Schma: NomTable(Attribut1, Attribut2, ..) Record/Tuple: une entre dans la table Element: une valeur dune entre dans la table

Cls: attribut avec valeur unique

NomTable(Attribut1, Attribut2, ..)

Rappel: Oprations
Crer / Altrer / Dtruire des tables tables et leurs attributs Requtes sur une ou plusieurs tables Insrer / Dtruire / Modifier des Tuples dans les tables

Rappel: Opration
Crer / Dtruire / Modifier schma des tables CREATE TABLE NomTable Attribut1 TypeAttribut1 Attribut2 TypeAttribut2 .. DROP NomTable ALTER TABLE NomTable ADD Attribut3 TypeAttribut3

Rappel: Opration
Requtes / Query (sur une ou plusieurs tables existantes): SELECT attributes FROM relations (multiple, join) WHERE conditions (selections) Modifier une ou plusieurs entre (tuples) dans une table: Insert, Delete, Update INSERT INTO R(A1,., An) VALUES (v1,., vn) DELETE FROM NomTable WHERE conditions UPDATE NomTable SET atttribut = valeur WHERE conditions

Rappel: Rgles dintgrit


Cls -> unicit des valeurs de la cl Attributs -> conditions Tuple (record) -> conditions Global (assertions) -> travers plusieurs tables

Rappel: SGBD
Query engine Query optimisation Gestion du stockage Gestion des Transactions (concurrence, rcupration aprs erreur)

Transaction
Transaction = squence doprations qui soit russissent toutes, soit chouent toutes Transaction = programme qui transforme une base de donnes dun tat cohrent un autre tat cohrent

Exemple
1: Begin_Transaction 2: get (K1, K2, CHF) from terminal 3: Select BALANCE Into S1 From ACCOUNT Where ACCOUNTNR = K1; 4: S1 := S1 - CHF; 5: Update ACCOUNT Set BALANCE = S1 Where ACCOUNTNR = K1; 6: Select BALANCE Into S2 From ACCOUNT Where ACCOUNTNR = K2; 7: S2 := S2 + CHF; 8: Update ACCOUNT Set BALANCE = S2 Where ACCOUNTNR = K2; 9: Insert Into BOOKING(ACCOUNTNR,DATE,AMOUNT,TEXT) Values (K1, today, -CHF, 'Transfer'); 10: Insert Into BOOKING(ACCOUNTNR,DATE,AMOUNT,TEXT) Values (K2, today, CHF, 'Transfer'); 12: If S1<0 Then Abort_Transaction 11: End_Transaction

Problmes
Si plusieurs transactions sont excutes en mme temps
Dautres applications ont accs un tat intermdiaire inconsistent Solution: contrle de la concurrence Exemple: 10 clients utilisent le mme serveur en parallle

Systme crashe (a une panne) pendant une transaction


Base de donnes reste dans un tat intermdiaire inconsistent Solution: recovery / recupration aprs erreur

Transaction

START

COMMIT

ABORT

Transaction
Une transaction peut se terminer normalement (aprs un commit)
Elle est alors valide. Toutes les modifications de la base de donnes sont enregistres et la base de donnes est cohrente. Le systme ne reviendra pas en arrire.

de manire avorte (aprs un abort)


Elle ne peut pas tre mene au bout. La base de donnes est purge des modifications effectues par cette transaction et ramene ltat dans lequel elle se trouvait avant dbut de la transaction

Proprits ACID
Atomicit
Toutes les oprations sont excutes ou aucune ne lest ( tout ou rien )

Cohrence
Une transaction valide les rgles dintgrit de la BD (tat consistent avant et aprs la transaction)

Isolation
Aucune mise--jour nest visible par les autres transactions avant la validation (commit). Indpendence des transactions.

Durabilit
Les changements raliss par la transaction sont enregistrs de manire permanente aprs la validation.

Gestion des Transaction


Le SGBD vrifie les proprits ACID Exemples dinterruption de transaction:
violation de rgle dintgrit panne arrt par intervention dun responsable treinte fatale (en cas de transactions concurrente)

Gestion des Transactions


Isolation + Cohrence => Contrle de la Concurrence
Transactions concurrentes apparaissent comme si elles taient excutes squentiellement

Atomicit + Durabilit => Recovery

Modle des Transactions


Chaque transaction lit/crit un ou plusieurs lments dune base de donne
Un block (schma) Une relation Un tuple (entre)

Contrle de la concurrence
Concurrence amliore la performance Interleaving des oprations des diffrentes transactions donne lieu des anomalies Problmes typiques/classiques
Perte dune mise jour (update) Lecture sale (dirty read) Lecture que lon ne peut pas reproduire

Perte dune mise jour


T1, T2 dposent de largent sur le compte acc1

Changements dus T2 sont perdus: R1(acc1) R2(acc1) W2(acc1) W1(acc1)

Perte dune mise jour


Rgle : Toute transaction T2 ne doit pas crire sur un objet dont la valeur a t modifie par une autre transaction T1 qui na pas t valide.
(write / write)

Dirty read
T1 dpose deux montants sur le compte acc1 T2 fait la somme de tous les comptes

T2 voit les valeurs intermdiaires (sales) de T1 R1(acc1) W1(acc1) R2(acc1) W2(sum) W1(acc1)

Dirty Read
Rgle : Toute transaction T ne doit pas lire des valeurs non confirmes et manipules par dautres transactions (write / read)

Lecture non reproductible


T1 lit plusieurs fois le compte acc1 T2 dpose un montant sur le compte acc1

T1 lit des valeurs diffrentes de acc1 R1(acc1) R2(acc1) W2(acc1) R1(acc1) W1(sum)

Lecture non reproductible


Rgle : Aucune transaction ne peut modifier une valeur lue par une autre transaction avant que cette dernire ne soit valide. (read / write)

Gestion de la concurrence
Srialisabilit
Graphe de Srialisabilit

Verrouillage (Locks)
Protocole de verrouillage deux phases Etreinte fatale (Deadlock) Problme des philosophes

Srialisabilit
Schedule = entrelacement (interleaving) des actions (read/write) dun ensemble de transactions, o les actions de chaque transactions sont dans lordre dorigine Schedule complet = avec les commit/abort

Srialisabilit
Schedule Complet: Etat initial de BD + Schedule complet -> tat final de la BD

Schedule Srialis
Une transaction la fois, sans entrelacement

Etat final est consistent Rsultat peut tre diffrent si la squence des transactions est diffrente

Schedule Srialisable
Schedule srialisable est un schedule avec des transactions entrelaces, sil existe un schedule srialis qui produit le mme rsultat Dans un schedule srialis, les transactions sont isoles

Srialisabilit
T1 r1(a) r2(a) w1(a) r2(a) r1(b) r2(b) T2

Peut-on trouver un schedule srialis?

Graphe de Prcdence
Graphe de de prcdence
nuds = transactions arcs = prcdences la transaction Ti prcde Tj (Ti -> Tj) dans le graphe si il y a une action de Ti qui prcde et est en conflit avec une action de Tj:
Ti et Tj sexcutent de manire concurrente, Tj modifie/crit un objet que Ti a dj lu ou crit, ou Tj lit un objet que Ti a dj modifi/crit (i.e. il y a deux actions sur un mme objet, lune des deux actions au moins est un write)

Si le graphe a un cycle alors le schedule nest pas srialisable Si le graphe na pas de cycle : nimporte quel ordre topologique des transactions peut tre pris comme schedule srialis.

Srialisabilit
T1 r1(a) r2(a) w1(a) r2(a) r1(b) r2(b) T2

Peut-on trouver un schedule srialis?

Graphe de Prcdence

Vrification de la srialisabilit
Optimiste: srialisabilit est vrifie aprs que les transactions soient effectues en utilisant le graphe de srialisabilit, sinon avorter les transactions Pessimiste: viter la non-srialisabilit avant quelle ne se produise utiliser des verrous

Rsum
Transactions Proprits ACID Transactions concurrentes et problmes Gestion de la concurrence

Srialisabilit Verrous

37

Lectures Recommendes
[Lewis] Philip M. Lewis, Arthur Bernstein, Michael Kifer: Databases and Transaction Processing - An application-oriented approach, Addison-Wesley.

38