Gestion des Transactions: Survol

Slides:



Advertisements
Présentations similaires
Contrôle de la concurrence
Advertisements

Atomicité Transactions Atomiques Recouvrement à Base de Journal
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Contrôle de lAccès Simultané Chapitre 17.
1 Gestion des Transactions: Survol Chapitre Transactions Une transaction est la vue abstraite qua le SGBD dun programme dusager: cest une séquence.
1 Reprise Chapitre Objectifs Vol et forçage: rappel Le log organisation maintient et utilisation Autres structures de données Protocole WAL Points.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Gestion des Transactions: Survol Chapitre 16.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Gestion des Transactions: Survol Chapitre 16.
MI-SESSION 2007 Miguel Garzon CSI3530. Q1. Idée Tri Externe à 3 voies en utilisant 3 tampons Main memory buffers INPUT 1 INPUT 2 OUTPUT Disk INPUT 2INPUT.
Ait Ahmed Madjid Cohen Lior Jaballah Seddik Leborgne Fabien
Module 7 : Restauration de bases de données
Gestion de la concurrence avec Entity Framework Développement d’application avec base de données Chapitre 23 Hugo St-Louis – Automne 2015.
Le système Raid 5 Table des matières Qu'est ce que le RAID ? Les objectifs Le raid 5 Les avantages et les inconvénients Les composants d’un Raid.
Marlène Côté et Christèle Charbonneau Thème: Mathématiques et univers social Les élèves seront amenés à effectuer des additions et des soustractions, de.
1- Introduction 1ère partie Le langage SQL 2- Connexion 3- Structure & Contenu 4- Requêtes.
Introduction Bases de Données NoSQL Principe de base Avantages/Inconvénients L’évolution du Web 2.0 et actuellement Web 3.0, a montrée l’insuffisance des.
ANNEE ACADEMIQUE Institut Supérieur Emmanuelle D’Alzon de Butembo COURS: THEORIE DE BASE DE DONNEES : 45H PROMOTION: G2 Gestion Informatique.
Utilisation du logiciel EduStat©
Les Instructions Itératives (Les Boucles)
Introduction au Langage Pascal
Introduction aux Systèmes de Gestion de Bases de données
Ce videoclip produit par l’Ecole Polytechnique Fédérale de Lausanne
Qualité de Web Services (QoS ou QdS)
Pointeurs et langage C.
Qu'est-ce que POSIX? Une librairie en langage C
Javadoc et débogueur Semaine 03 Version A17.
Master Réseaux et Systèmes Distribués (RSD) Algorithmique des systèmes
Radiographie industrielle
Ce videoclip produit par l’Ecole Polytechnique Fédérale de Lausanne
AP Examen Pratique commentaires
Work: ISA8895 Implementation Section: Interoperability Chapter: B2O
Téléchargement IOS - Commande tftpdnld du ROM Monitor
Chapitre 12 Surveillance des ressources et des performances
IDL_IDL bridge The IDL_IDLBridge object class allows an IDL session to create and control other IDL sessions, each of which runs as a separate process.
Orthographe à retenir :
PROGRAMMATION INFORMATIQUE D’INGÉNIERIE II
Architecture de clients Duniter
L’I NSTRUCTION DE T EST A LTERNATIF Réalisé par : OUZEGGANE Redouane Département de Technologie Faculté de Technologie – Université A.Mira, Bejaia Année.
L ES I NSTRUCTIONS I TÉRATIVES (L ES B OUCLES ) Réalisé par : OUZEGGANE Redouane Département de Technologie Faculté de Technologie – Université A.Mira,
Manipulation D’Une Base De Données
Calcul Relationnel Chapitre 4, Section 4.3.
Contrôle de l’Accès Simultané
Type Concret – Type Abstrait
1 Bases de Données Distribuées Chapitre 22, Sections 22.6–22.14.
Introduction en systèmes d’information et bases de données B.Shishedjiev -Introduction en BD 1.
I Copyright © 2004, Oracle. Tous droits réservés. Introduction.
1 Copyright © 2004, Oracle. Tous droits réservés. Extraire des données à l'aide de l'instruction SQL SELECT.
8 Copyright © 2004, Oracle. Tous droits réservés. Manipuler les données.
Chapitre2: SGBD et Datawarehouse. On pourrait se demander pourquoi ne pas utiliser un SGBD pour réaliser cette structure d'informatique décisionnelle.
Contrôle de l’Accès Simultané
© Robert Godin. Tous droits réservés.
8 L'intégrité et la gestion des transactions
Tri Externe Chapitre 13: 13.1—13.5
BUFFER CIRCULAIRE Meryem EL BAKRI. PLAN Introduction Buffer circulaire Fonctionnement.
Info Bases de données avancées
Algèbre Relationnelle
Le Modèle Entité-Relation (Entité-Association)
Support construit à partir des cours de
Plan I.Définitions II.Objectifs III.Intérêt IV.Quoi tester ? V.Processus VI.Exemples VII.Conclusion VIII.Références.
Piles et files.
Gestion des Transactions: Survol
Gestion des Transactions: Survol
STREAMS (et fichiers).
Lecture/Écriture de fichiers (I/O)
Variables et accès en Java
Tableau de bord d’un système de recommandation
Evaluation des Operations Relationnelles
Test de performances. Test de performances:  Un test de performance est un test dont l'objectif est de déterminer la performance d'un système informatique.
SQL: Contraintes et Triggers
Algèbre Relationnelle
Contenu Systèmes de test parallèles Multithreading Synchronisation
Transcription de la présentation:

Gestion des Transactions: Survol Chapitre 16 The slides for this text are organized into several modules. Each lecture contains about enough material for a 1.25 hour class period. (The time estimate is very approximate--it will vary with the instructor, and lectures also differ in length; so use this as a rough guideline.) This covers Lecture 1A in Module (6); it is a 1-lecture overview of the material, and is an alternative to Lectures 1 through 4 in this module, which provide more detailed coverage. Note that the text contains enough material for an even more detailed treatment than Lectures 1 through 4, e.g., view serializability, B-tree CC, non-locking approaches.) Module (1): Introduction (DBMS, Relational Model) Module (2): Storage and File Organizations (Disks, Buffering, Indexes) Module (3): Database Concepts (Relational Queries, DDL/ICs, Views and Security) Module (4): Relational Implementation (Query Evaluation, Optimization) Module (5): Database Design (ER Model, Normalization, Physical Design, Tuning) Module (6): Transaction Processing (Concurrency Control, Recovery) Module (7): Advanced Topics

Transactions Une transaction est la vue abstraite qu’a le SGBD d’un programme d’usager: c’est une séquence de lectures (‘reads’) et écritures (‘writes’). L’exécution simultanée de plusieurs programmes d’usagers 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 d’une transaction) en évitant de voir les courtes transactions (abrégées en transactions) être bloquées derrière les longues transactions. Un programme d’utilisateur peut exécuter beaucoup d’opérations sur des données puisées d’une 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.

Les Propriétés ACID Atomicité: Soit que toutes les actions d’une transaction sont exécutées soit aucune n’est 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).

Consistance et Isolation Les utilisateurs soumettent les transactions et peuvent les concevoir comme exécutant isolément. L’accès simultané est réalisé par le SGBD qui entrelace les actions de plusieurs transactions. L’effet net est le même que celui d’exécuter les transactions l’une après l’autre 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: S’occuper des effets de l’entrelacement des transactions (Contrôle d’accès simultané ).

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 d’exé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 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: S’occuper des effets des incidents (Reprise –’Recovery’).

Planification des Transactions Plan (historique): Entrelacement des actions de différentes transactions. Plan sériel (séquentiel): Plan qui n’entrelace pas les actions des différentes transactions. Plans équivalents: Pour toute base de données, deux plan S1 et S2 sont équivalents ssi l’effet de l’exécution de S1 est identique à l’effet de l’exé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. )

Contrôle de l‘Accès Simultané: Exemple Considérez les deux transactions 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 n’y 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.

Exemple (Suite) Ceci est faisable (car sérialisable). Mais pas: Considérez cet entrelacement: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Ceci est faisable (car sérialisable). Mais pas: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B 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)

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

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

Contrôle d’Accès Simultané par des Verrous Un SGBD s’assure que seuls les plans sérialisables sont permis en utilisant un protocole de contrôle d’accè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.

Abandon d’une 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 d’une transaction qu’après la validation de celle-ci. Si Ti écrit un objet, Tj ne peut le lire qu’après la validation de Ti. Pour défaire les actions d’une 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.

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’’ n’est pas immune aux fantômes; i.e. une transaction voit deux fois une collection différente d’objets.

Transactions en SQL (Suite) SQL fournit un moyen de contrôle pour : Mode d’accès: READ ONLY / WRITE ONLY / READ WRITE. Degré d’isolation: contrôle ce que les autres transactions voient d’une transaction donnée. Degré d’isolation ‘’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

Reprise à Partir d’une Panne Rappel: Le ‘’recovery manager’’ s’assure que les transactions sont atomiques et durables. Le ‘’transaction manager’’ s’assure 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 qu’il 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).

Reprise à Partir d’un Panne: le Log Les actions suivantes sont enregistrées dans le log: Ti écrit un objet: La vieille valeur de l’objet ainsi que la nouvelle valeur. L’enregistrement 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 l’identité 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.

Reprise: L’approche ARIES Vol et non forçage en 3 phases: Analyse: Scanner le log vers l’avant (à partir du plus récent checkpoint) afin d’identifier 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é d’arrière en avant. (Une attention particulière doit être faite aux les pannes survenant pendant le processus de reprise!)

Résumé Le contrôle de l’accès simultané et la reprise sont parmi les plus importantes fonctions d’un SGBD. Les usagers n’ont pas besoin de s’occuper de l’accès simultané. Le SGBD insère automatiquement les requêtes de verrouillage/déverrouillage d’objets et planifie les actions des différentes transactions de manière à assurer que l’exé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 l’extérieur.