Ait Ahmed Madjid Cohen Lior Jaballah Seddik Leborgne Fabien Les Transactions Ait Ahmed Madjid Cohen Lior Jaballah Seddik Leborgne Fabien

Introduction Beaucoup d'opérations sur une BD doivent être atomiques: Transfert d'argent entre les comptes: UPDATE Compte1 Val = Val -100 UPDATE Compte2 Val = Val + 100 Si seulement une de ces requêtes est exécutée, la BD perd sa cohérence

Transactions Opérations atomiques inexprimables avec une requête relationnelle. entièrement ou pas du tout Préservant la consistance de la BD Comme si l'usager était isolé sur la BD ***Notion de transactions ***

Transactions: Les primitives Notions: COMMIT, ROLLBACK Sous Oracle les opérations sont placées dans un buffer en attendant d ’être finaliser. =>Verrouillage des tables concernées COMMIT: Finaliser une transaction, aucune annulation possible ROLLBACK: Annuler une transaction, les opérations placées qui n ’ont pas été finalisées par un COMMIT sont effacées

Transactions: Les primitives Seul l'utilisateur ayant effectué les modifications les voit Exemple: COMMIT, ROLLBACK Début TRANSACTION INSERT INTO Medicament VALUES (2, 'lexomil'); ROLLBACK; INSERT INTO medicament VALUES (3,  ’doliprane'); COMMIT; Fin Seul doliprane a été inséré définitivement

Remarque Il existe plusieurs niveaux de ROLLBACK Appel automatique si instruction erronée Exemple: Insertion d ’un tuple dont la clé existe déjà

Les points de sauvegarde Permet de diviser une transaction en morceaux SAVEPOINT Point1; ... ROLLBACK TO SAVEPOINT Point1;

COMMIT Automatique Il est possible de rendre la finalisation des opérations automatique UTILISATION: « SET AUTOCOMMIT ON; » Certaines opérations provoquent des COMMIT automatiquement Liste des opérations

Les opérations qui valident… toutes seules ALTER AUDIT NOAUDIT COMMENT CONNECT CREATE DISCONNECT DROP EXIT GRANT REVOKE QUIT RENAME

Reconnaissance de transactions Oracle affecte aux transactions un ID Possibilité de nommer une transaction SET TRANSACTION ... NAME Possibilité de commenter un COMMIT COMMIT COMMENT ‘mon commentaire ici’

Les transactions en lecture seule Possibilité de spécifier qu’une transaction est en lecture seule. Gestion optimisé Pas de verrous à gérer Utilisation: SET TRANSACTION READ ONLY;

Transactions autonomes Définition: Il s'agit d'une transaction au sein d'une transaction « primaire » qui est autonome par rapport à cette dernière. Cas d'utilisation: Il peut être utile dans certain cas que la base soit modifié même si la transaction est annulée.

Exemple La transaction autonome. CREATE OR REPLACE PROCEDURE TransAutonome IS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN -- Transaction autonome et validation INSERT INTO Medicament VALUES (7, 'lexomil',15.2); INSERT INTO medicament VALUES (8, 'vitamine B',5.2); COMMIT; END; /

Exemple (suite) La transaction principale. CREATE OR REPLACE PROCEDURE lanceTransaction IS BEGIN -- Transaction principale INSERT INTO Medicament VALUES (9, 'aspro 500',5); -- lancement d'une transaction autonome TransAutonome(); -- Reprise de la transaction principale INSERT INTO Medicament VALUES (10, 'doliprane 200',8); -- Invalidation de la transaction principale ROLLBACK; END; /

Exemple (fin) Résultat. La base contient ces information après l'annulation de la transaction principale: ID_M NOM_M PRIX_M ---------- -------------------- ---------- 8 vitamine B 5.2 7 lexomil 15.2 Les opérations réalisées dans la transaction autonome ont été conservées malgré l'annulation de la transaction principale.

Implémentation de transactions T-ID : Identificateur de transaction Inscription dans la BD seulement après le COMMIT Journalisation: Toute opération d'une transaction est notée avant et après l'exécution dans un fichier journal présumé à l'abris de pannes Les opérations de commitement sont notées avant d'être exécutées sur la BD (write- ahead log protocol) Points de reprise (checkpoints) sauvegardes de l'état de la BD et notamment de TIDs de transactions en cours à intervalles réguliers

Et si la casse arrive... On ferme l'accès à la base On reprend le dernier checkpoint On retrouve sur le journal toutes les transactions commises après commencées avant ou après le checkpoint On re-exécute chronologiquement ces transactions et seulement ces transactions On rouvre la base aux usagers

Concurrence Les BDs étant partagées, les transactions pourraient être exécutées: l'une après l'autre simultanément meilleures performances possibilités d'inconsistances dans la base Théorie de concurrence analyse les problèmes d'accès simultané

Exemple A = 100 R2 (A) R1 (A) A := A +200 A := A +100 W1 (A) A = 200 La base

Exemple A = 100 R2 (A) R1 (A) A := A +200 A := A +100 W1 (A) A = 200 La base

Quelques Verrous

Gestion de la concurrence Verrouillage exclusif toute opération d'une transaction T sur une donnée D ne peut fait que si T obtient un verrou sur D si D est déjà verrouillé par T' quand T le demande, alors T est mis en attente Ce type de verrou est dit exclusif

Exemple La base L (A) A = 100 L (A) R1 (A) A := A +100 W1 (A) A = 200 U (A)

Exemple La base L (A) A = 100 L (A) R1 (A) A := A +100 W1 (A) A = 200 U (A) R2 (A) A := A +200 A = 400

les lectures ont les verrous partagés Verrouillage partagé les lectures ont les verrous partagés T et T' peuvent lire D simultanément les écritures doivent obtenir les verrous exclusifs si D est déjà verrouillé par T', alors T est mis en attente C'est la méthode la plus utilisé Avantage: meilleures performances, mais...

Exemple Lr (A) A = 100 Lr (A) R1 (A) R2 (A) A := A +100 A := A +200 Lw (A) Lw (A) La base

Verrou mortel Les transactions s'attendent mutuellement (deadlock) Solution typique: avorter une des transactions (la victime) le choix est fait par le gestionnaire des verrous (lock manager)

Exemple Lr (A) A = 100 Lr (A) R1 (A) R2 (A) A := A +100 A := A +200 Lw (A) Lw (A) A W2 (A) A = 300 La base

Lr (A) A = 300 R1 (A) A := A +100 Lw (A) W1 (A) A = 400 La base

Toujours plus loin dans les transactions Commit à 2 phases: Cette technique permet d’assurer qu'une transaction a fait avec succès la mise à jour de tous les fichiers appropriés dans un environnement de base de données réparties flashback query : conservation d'un historique de la base Et aussi, permet de retourner à un état précédent de la base (malgré la validation).

COMMIT ?