Gestion des Transactions: Survol

1
Gestion des Transactions Survol

• Chapitre 16

2
Transactions

• Une transaction est la vue abstraite qua le SGBD
  dun programme dusager cest une séquence de
  lectures (reads) et écritures (writes).
• Lexécution simultanée de plusieurs programmes
  dusagers est essentielle pour une bonne
  performance du SGBD.
• Augmenter le débit (throughput) du système (
  de transactions complétées à chaque instant) en
  chevauchant les opérations de I/O et de CPU.
• Augmenter le temps de réponse (temps de
  complétion dune transaction) en évitant de voir
  les courtes transactions (abrégées en
  transactions) être bloquées derrière les longues
  transactions.
• Un programme dutilisateur peut exécuter beaucoup
  dopérations sur des données puisées dune base
  de données, mais le SGBD est seulement intéressé
  aux données qui sont lues (écrites) de (dans) la
  base de données.

3
Les Propriétés ACID

• Atomicité Soit que toutes les actions dune
  transaction sont exécutées soit aucune nest
  exécutée.
• Consistance Toute transaction qui commence son
  exécution dans un état consistant de la base de
  données doit laisser la base de données dans un
  état consistant.
• Isolation Une transaction est protégée des
  effets des autres transactions exécutant
  simultanément.
• Durabilité Les effets des transactions ayant été
  validées doivent persister et survivre toute
  défaillance du système (crash/défaillance des
  medias).

4
Consistance et Isolation

• Les utilisateurs soumettent les transactions et
  peuvent les concevoir comme exécutant isolément.
• Laccès simultané est réalisé par le SGBD qui
  entrelace les actions de plusieurs transactions.
  Leffet net est le même que celui dexécuter les
  transactions lune après lautre en série.
• Chaque transaction doit laisser la base de
  données dans un état consistant si la base de
  données était dans un état consistant au début de
  la transaction.
• Le SGBD vérifie quelques ICs, dépendant des ICs
  déclarées dans les instructions CREATE TABLE.
• Au delà de cela, le SGBD ne comprend pas la
  sémantique des données.
• Tâche Soccuper des effets de lentrelacement
  des transactions (Contrôle daccès simultané ).

5
Atomicité et Durabilité

• Une transaction devrait être validée après
  complétion de toutes ses actions, ou être
  terminée sans succès
• Elle pourrait être abandonnée après quelques
  actions.
• Le système peut tomber en panne pendant que des
  transactions sont entrain dexécuter.
• Il pourrait y avoir une défaillance des media
  empêchant les lectures/écritures.
• Commit Validation Abort Abandon crash
  panne, plantage
• Deux propriétés très importantes garanties par le
  SGBD pour toutes les transactions sont
  latomicité et la durabilité.
• Atomicité Le SGBD maintient un log de toutes les
  actions de manière à défaire les actions des
  transactions abolies.
• Durabilité les actions des transactions validées
  sont écrites sur disque ou (en cas de crash) le
  système doit refaire les actions des transactions
  validées qui nétaient pas encore écrites sur
  disque.
• Tâche Soccuper des effets des incidents
  (Reprise Recovery).

6
Planification des Transactions

• Plan (historique) Entrelacement des actions de
  différentes transactions.
• Plan sériel (séquentiel) Plan qui nentrelace
  pas les actions des différentes transactions.
• Plans équivalents Pour toute base de données,
  deux plan S1 et S2 sont équivalents ssi leffet
  de lexécution de S1 est identique à leffet de
  lexécution de S2.
• Plan sérialisable Un plan est sérialisable ssi
  ce plan produit le même résultat que un plan
  séquentiel des transactions impliquées.
• (Note Si chaque transaction préserve la
  consistance, chaque plan sérialisable préserve
  aussi consistance. )

7
Contrôle de lAccès Simultané Exemple

• Considérez les deux transactions suivantes

T1 BEGIN AA100, BB-100 END T2 BEGIN
A1.06A, B1.06B END

• Intuitivement, la première transfère 100 du
  compte B au compte A. La seconde crédite les deux
  comptes avec un intérêt de 6.
• Si les deux sont soumises au même moment, il ny
  a aucune garantie que T1 exécutera avant T2 ou
  vice-versa. Cependant le net effet doit être
  équivalent à celui des deux transactions
  exécutant en série dans un certain ordre.

8
Exemple (Suite)

• Considérez cet entrelacement

T1 AA100, BB-100 T2
A1.06A, B1.06B

• Ceci est faisable (car sérialisable). Mais pas

T1 AA100, BB-100 T2
A1.06A, B1.06B

• Le SGBD voit le 2nd plan de la manière suivante

T1 R(A), W(A), R(B), W(B) T2
R(A), W(A), R(B), W(B)
9
Anomalies des Exécutions Entrelacées

• Lecture des données non validées (Conflits WR,
  dirty reads)
• Lectures non répétables (Conflits RW,  non
  repeatable reads )

T1 R(A), W(A), R(B), W(B),
Abort T2 R(A), W(A), C
T1 R(A), R(A), W(A), C T2 R(A),
W(A), C
10
Anomalies (Suite)

• Écrasement des données non validées (Conflits WW,
  lost updates)

T1 W(A), W(B), C T2 W(A), W(B), C
11
Contrôle dAccès Simultané par des Verrous

• Un SGBD sassure que seuls les plans
  sérialisables sont permis en utilisant un
  protocole de contrôle daccès.
• Protocole Strict Two-phase Locking (Strict
  2PL)
• Chaque transaction doit obtenir un verrou
  (partagé) du genre S sur un objet avant de le
  lire, et un verrou (exclusif) du genre X sur un
  objet avant de le lire.
• Tous les verrous sont retenus par une transaction
  jusquà sa fin complète.
• Si une transaction retient un verrou X sur
  objet, aucune autre transaction ne peut obtenir
  un verrou sur cet objet.
• Strict 2PL permet cependant des deadlocks, i.e.
  des cycles de transactions qui attendent que des
  verrous soient relâchés. Un SGBD doit prévenir ou
  détecter (et résoudre) des deadlocks.

12
Abandon dune Transaction

• Si une transaction Ti est abandonnée, toutes ses
  actions sont défaites. De plus, si Tj lit un
  objet écrit en dernier lieu par Ti, Tj doit
  aussi être abandonnée!
• La plupart des systèmes évitent de tels abandons
  en cascade en ne relâchant les verrous dune
  transaction quaprès la validation de celle-ci.
• Si Ti écrit un objet, Tj ne peut le lire quaprès
  la validation de Ti.
• Pour défaire les actions dune transaction
  abandonnée, un SGBD maintient un log où toute
  action décriture est enregistrée. Ce mécanisme
  est aussi utile pour la reprise des activités
  après une panne Toutes les transactions actives
  au moment de la panne sont abandonnées lors de la
  reprise du système.

13
Support pour les Transactions en SQL

• SQL fournit un support pour spécifier les
  comportement des transactions. Une transaction
  est automatiquement initiée avec chaque
  instruction SQL (exceptée CONNECT) et est terminé
  avec soit une instruction COMMIT ou ROLLBACK.
• SQL99 supporte des transactions avec des points
  de sauvegarde (savepoints) et des
  transactions chaînées.
• On définit un savepoint et on y revient plutard
  de manière sélective p.ex. SAVEPOINT point1 ...
  ROLLBACK TO SAVEPOINT point1.
• On peut valider/abandonner et initier
  immédiatement une autre transaction SELECT
  FROM Sailors COMMIT AND CHAIN
  SELECT FROM Students ROLLBACK
• Un SGBD peut verrouiller un objet de la BD avec
  différentes granularités row-level vs.
  table-level.
• La granularité row-level nest pas immune aux
  fantômes i.e. une transaction voit deux fois
  une collection différente dobjets.

14
Transactions en SQL (Suite)

• SQL fournit un moyen de contrôle pour
• Mode daccès READ ONLY / WRITE ONLY / READ
  WRITE.
• Degré disolation contrôle ce que les autres
  transactions voient dune transaction donnée.
• Degré disolation Dirty read
  Unrepeatable read Fantôme
• READ UNCOMMITTED Possible Possible
  Possible
• READ COMMITTED Non
  Possible Possible
• REPEATABLE READ Non Non
  Possible
• SERIALIZABLE Non
  Non Non
• Exemple
• SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
  READ WRITE

15
Reprise à Partir dune Panne

• Rappel
• Le recovery manager sassure que les
  transactions sont atomiques et durables.
• Le transaction manager sassure que les
  transactions sont consistantes et isolées en
  utilisant un protocole approprié de verrouillage.
  
• Alternatives dans la gestion des pages tampon
• Le vol (steal) Les changements effectués sur
  un objet O par une transaction T peuvent être
  écrits sur disque avant que T ne soit validée.
• Le forçage Forcer tous les changements faits par
  les transactions validées sur disque.
• Approche réaliste alliant le vol et le non
  forçage
• Si un cadre modifié est choisi pour remplacement,
  la page quil contient est écrite sur disque
  (vol) .
• Les pages changées en mémoire ne sont pas forcées
  sur disque lors de la validation des transactions
  associées (non forçage).

16
Reprise à Partir dun Panne le Log

• Les actions suivantes sont enregistrées dans le
  log
• Ti écrit un objet La vieille valeur de lobjet
  ainsi que la nouvelle valeur.
• Lenregistrement du log doit aller au disque
  avant la page modifiée (protocole WAL)!
• Ti est validée/abandonnée un enregistrement du
  log indiquant cette action.
• Les enregistrements du log sont chaînés ensemble
  par lidentité des transactions ainsi il sera
  facile de défaire un transaction spécifique.
• Le log est copié plusieurs fois et archivé sur
  disque/bande.
• Toutes les activités relatives au log sont
  traitées de manière transparente par le SGBD.

17
Reprise Lapproche ARIES

• Vol et non forçage en 3 phases
• Analyse Scanner le log vers lavant (à partir
  du plus récent checkpoint) afin didentifier
  toutes les transactions qui étaient actives et
  toutes pages modifiées en mémoire au moment de la
  panne.
• Refaire ( Redo ) Refait tous les changements
  des pages modifiées dans la mémoire tampon pour
  assurer que tous les changements inscrits au log
  sont effectués et écrits sur disque.
• Défaire ( Undo ) Les changements effectués
  sur disque par toutes les transactions actives au
  moment de la panne sont défaites (en restaurant
  les valeurs antérieures des objets modifiés,
  lesquelles valeurs ont été enregistrées dans le
  log avant la panne). Pour ce faire, le log est
  scanné darrière en avant. (Une attention
  particulière doit être faite aux les pannes
  survenant pendant le processus de reprise!)

18
Résumé

• Le contrôle de laccès simultané et la reprise
  sont parmi les plus importantes fonctions dun
  SGBD.
• Les usagers nont pas besoin de soccuper de
  laccès simultané.
• Le SGBD insère automatiquement les requêtes de
  verrouillage/déverrouillage dobjets et planifie
  les actions des différentes transactions de
  manière à assurer que lexécution qui en résulte
  est équivalente à une exécution séquentielle de
  ces transactions.
• Un log astreint au protocole WAL est utilisé pour
  défaire les actions des transactions abandonnées
  et pour restaurer le système à un état consistant
  après une panne.
• État consistant Seulement les effets des
  transactions validées sont vus par de
  lextérieur.