Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Gestion des Transactions: Survol Chapitre 16.

Présentation au sujet: "Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Gestion des Transactions: Survol Chapitre 16."— Transcription de la présentation:

1 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Gestion des Transactions: Survol Chapitre 16

2 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke2 Transactions Une transaction est la vue abstraite qua le SGBD dun programme dusager: cest une séquence de lecture (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 Xacts être bloquées derrière les longues Xacts. 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 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke3 Les Propriétés ACID Atomicité : Soit que toutes les actions dune Xact sont exécutées soit aucune nest exécutée. Consistance: Toute Xact 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 Xact est protégée des effets des autres Xacts exécutant simultanément Durabilité: Les effets des Xacts ayant été validées doivent persister et survivre toute défaillance du système (crash/défaillance des medias).

4 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke4 Consistance et Isolation Les utilisateurs soumettent les Xacts et peuvent les concevoir comme exécutant isolément. Laccès simultané est réalisée par le SGBD qui entrelace les actions (reads/writes) de plusieurs Xacts. Leffet net est le même que celui dexécuter les Xacts lune après lautre en série. Chaque Xact 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 Xact. 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 (p.ex., il ne comprend pas comment une banque calcule les intérêts des comptes). Tâche: Soccuper des effets de l entrelacement des Xacts ( Contrôle daccès simultané – Concurrency control ).

5 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke5 Atomicité et Durabilité Une Xact 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 Xacts 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 l atomicité et la durabilité. Atomicité: Le SGBD maintient un log de toutes les actions de manière à défaire les actions des Xacts abolies. Durabilité: les actions des Xacts validées sont écrites sur disque ou (en cas de crash) le système doit refaire les actions des Xacts validées qui nétaient pas encore écrites sur disque. Tâche: Soccuper des effets des incidents ( Reprise –Recovery ).

6 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke6 Contrôle de Accès Simultané: Exemple Considérez les deux Xacts suivantes: T1:BEGIN A=A+100, B=B-100 END T2:BEGIN A=1.06*A, B=1.06*B 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 Xacts exécutant en série dans un certain ordre.

7 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke7 Exemple (Suite) Considérez cet entrelacement ( historique / plan ): T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Ceci est faisable. Mais pas: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Le SGBD voit le 2nd schedule de la manière suivante: T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B)

8 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke8 Planification des 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 une exécution séquentielle des transactions impliquées. (Note: Si chaque transaction préserve la consistance, chaque plan sérialisable préserve aussi consistance. )

9 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke9 Anomalies des Exécutions Entrelacées Lecture des données non validées (Conflits WR, dirty reads): Lectures non répétables (Conflits RW): 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 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke10 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 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke11 Contrôle dAccès Simultané par des Verrous Un SGBD sassure que seuls les plans sérialisable sont permis en utilisant un protocole de contrôle daccses. Protocole Strict Two-phase Locking (Strict 2PL) : Chaque Xact 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 Xact jusquà sa fin complète. Si une Xact retient un verrou X sur objet, aucune autre Xact ne peut obtenir un verrou () sur cet objetno other Xact can get a lock (S or X) on that object. Strict 2PL does however allow deadlocks, i.e. cycles of Xacts waiting for locks to be released. A DBMS must either prevent or detect (and resolve) deadlocks.

12 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke12 Abandon dune Transaction Si une Xact Ti est abandonnée, toutes ses actions sont défaites. De plus, si Tj lit un objet lu en dernier lieu par Ti, Tj doit aussi être abandonnée! Laplupart des systèmes évitent de tels cababdons en cascade en ne relâchent les verrous dune Xact quapres la validations 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 Xact 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 Xacts actives au moment de la panne sont abandonnées lors de la reprise du système.

13 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke13 Support pour les Transactions en SQL SQL fournit un support pour spécifier les comportement des Xacts. Une Xact est automatiquement initiée avec chaque instruction SQLt (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 chainées. On definit un savepoint et on y revient plutard de maniere selective: p.ex.: SAVEPOINT point1... ROLLBACK TO SAVEPOINT point1. On peut valider/abandonner et initier immédiatement une autre Xact: 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 phantomes; i.e. une Xact voit deux fois une collections différentes dobjets.

14 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke14 Transactions en SQL (Suite) SQL fournit un moyen de contrôle pour : Taille des diagnostiques: # derreurs que le système peut retenir. Mode daccès: READ ONLY / WRITE ONLY / READ WRITE. Degré disolation: contrôle ce que les autres Xacts voient dune Xact donnée. De Dirty read Unrepeatable read Phantome READ UNCOMMITTED Possible Possible Possible READ COMMITTED No Possible Possible REPTEATABLE READ No No Possible SERIALIZABLE No No No Exemple: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE READ WRITE

15 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke15 Reprise à Partir dune Panne Le recovery manager sassure que les Xacts sont atomiques (en défaisant les actions des Xacts non validées) et durables (en garantissant que les Xacts validées survivent aux pannes). Le transaction manager contrôle lexécution des Xacts 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 Xact T peuvent être écrits sur disque avant que T ne soit validée. Ceci survient lorsque le buffer manager décide de remplacer le cadre contenant O par une page appartenant à une Xact différente. Le forçage : Forcer tous les changements faits par les Xacts validées sur disque. La plupart des systèmes utilisent une approche alliant le vol et le non forçage laquelle est réaliste: Si un cadre modifié est choisi pour remplacement, la page quil contient est écrite sur disque (vol). Les pages changé en mémoire ne sont pas forcées sur disque lors de la validation des Xacts associées (non forçage).

16 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke16 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! 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 Xacts; ainsi il sera facile de défaire un Xact 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 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke17 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 Xacts qui étaient actives et toutes pages modifiées en mémoire au moment de la panne. Refaire : 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. Undo : Les changements effectués sur disque par toutes les Xacts 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 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke18 Résumé Le contrôle de laccès simultané et la reprise à partir des pannes 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 Xacts de manière à assurer que lexécution qui en résulte est équivalente à une exécution séquentielle de ces Xacts. Un log astreint au protocole WAL est utilisé pour défaire les actions des Xacts abandonnées et pour restaurer le système à un état consistant après une panne. État consistant : Seulement les effets des Xacts validées sont vus par de lextérieur.