Module 106

Jour 8 - Gestion des transactions

Interroger, traiter et assurer la maintenance des bases de données

# Objectifs du jour

Objectifs du jour

  • Modification du Mindmap

  • Correction de l'exercice de modification de la BDD (Exercice 6.1)

  • Présentation des transactions

  • Critères du principe ACID

  • Commandes du LCT (GRANT, REVOKE, SAVEPOINT)

  • Exercices sur les transactions (Exercice 7.1)

# Mindmap

Modification du Mindmap

  • Mise à jour du Mindmap
# Sauvegardes des bases de données

Exercice 5.1

Exercice de sauvegarde et restauration

Correction de l'exercice des sauvegardes

https://divtec.gitbook.io/ict-106

# Sauvegardes des bases de données

Exercice 6.1

Modification de la base de données

Correction de l'exercice de modification de la BDD

https://divtec.gitbook.io/ict-106

Transactions

# Notions ACID des SGBDRs

Une transaction dans le contexte des bases de données est un ensemble d'opérations (lecture, écriture, mise à jour, suppression) qui sont traitées comme une seule unité de travail.
Elle représente un changement cohérent de l'état de la base de données.

Transactions

# Notions ACID des SGBDRs

Exemple

Prenons l'exemple d'un transfert bancaire :

  1. Débiter le compte A de CHF 100
  2. Créditer le compte B de CHF 100

Ces deux opérations forment une seule transaction. Si l'une des opérations échoue, l'ensemble de la transaction est annulé pour maintenir la cohérence des données bancaires.

Garantir la cohérence des données malgré des interruptions, erreurs ou accès concurrents.

Pourquoi utiliser des transactions en base de données ?

# Notions ACID des SGBDRs

Dans un SGBDR notamment Oracle, une transaction se termine par un COMMIT (validation) ou un ROLLBACK (annulation).

Il est donc importance de gérer les erreurs lors des transactions. Par exemple, si une erreur survient pendant une transaction, elle doit être annulée avec un ROLLBACK pour éviter une base de données incohérente.

Exemple

BEGIN
    -- Débiter 100 CHF du compte A
    UPDATE comptes SET solde_compte = solde_compte - 100 WHERE code_compte = 'CC001';

    -- Créditer 100 CHF au compte B
    UPDATE comptes SET solde_compte = solde_compte + 100 WHERE code_compte = 'CC002';

    -- Valider la transaction
    COMMIT;
EXCEPTION
    -- En cas d'erreur, annuler tout
    WHEN OTHERS THEN
        ROLLBACK;
END;
/

# Notions ACID des SGBDRs

A - Atomicité : Une transaction est indivisible. Soit toutes ses opérations réussissent, soit aucune. Il n'y a pas d'état intermédiaire.

C - Cohérence : Une transaction doit amener la base de données d'un état cohérent à un autre. Cela signifie que toutes les règles d'intégrité doivent être respectées avant et après la transaction.

I - Isolation : Chaque transaction est indépendante des autres, empêchant les conflits et les incohérences.

D - Durabilité : Une fois validée, une transaction ne peut être annulée. Même en cas de panne du système.

Les grands principes des transactions

# Notions ACID des SGBDRs

A - Atomicité : Une transaction est indivisible. C'est tout ou rien, soit toutes ses opérations réussissent, soit aucune. Il n'y a pas d'état intermédiaire.

Les grands principes des transactions

C - Cohérence : Une transaction doit amener la base de données d'un état cohérent à un autre. Cela signifie que toutes les règles d'intégrité doivent être respectées avant et après la transaction.

Si le débit du compte A réussit mais que le crédit du compte B échoue, alors le débit est annulé. Aucun argent ne disparaît.

Si une règle interdit un solde négatif, elle doit être respectée avant et après la modification (on peut temporairement violer des règles)

# Notions ACID des SGBDRs

I - Isolation : Chaque transaction est indépendante des autres, empêchant les conflits et les incohérences.

Les grands principes des transactions

D - Durabilité : Une fois validée, une transaction ne peut être annulée. Même en cas de panne du système. Les modifications sont "gravées dans le marbre".

Si une autre transaction consulte le compte A ou B pendant le transfert, elle ne verra ni un état intermédiaire ni des données incohérentes.

 Si le transfert est validé (COMMIT) et que le serveur tombe en panne juste après, le transfert est conservé. S'il n'y a pas eu de commit, les modifications en cours sont annulées.

Exercice de gestion des transactions

https://divtec.gitbook.io/ict-106

Exercice 8.1

Exercice de gestion des transactions et

des exceptions :

# Notions ACID des SGBDRs

# Notions ACID des SGBDRs

L'isolation garantit que chaque transaction s'exécute de manière indépendante des autres, empêchant les conflits et les incohérences.

Isolation dans le Principe ACID

Lorsqu'il y a plusieurs transactions simultanées, elles peuvent interagir de manière imprévue et causer des problèmes de concurrence des données :

  • Lecture sale (Dirty Read) : Lire des données non validées par une autre transaction.
  • Lecture non répétable (Non-Repeatable Read) : Une même requête retourne différents résultats dans la même transaction.
  • Lecture fantôme (Phantom Read) : Des nouvelles lignes apparaissent alors qu’une transaction est en cours.
  • Interblocage (Dead Lock) : Deux transactions se bloquent mutuellement en attendant chacune une ressource verrouillée par l'autre, empêchant toute progression.

# Notions ACID des SGBDRs

Une transaction lit des données modifiées, mais non validées par une autre transaction. Si cette dernière est annulée (ROLLBACK), la première transaction aura utilisé des données incorrectes.

Lecture sale (Dirty Read)

Session 1 :
-- Démarrage de la transaction
UPDATE comptes SET solde_compte = solde_compte - 500 WHERE code_compte = 'IV001';
-- Pas encore de COMMIT, les changements ne sont pas définitifs

Session 2 :
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT solde_compte FROM comptes WHERE code_compte = 'IV001';
-- Ici, on voit le solde diminué alors que la transaction en Session 1 n'est pas validée !
Session 1 :
ROLLBACK;
-- La modification est annulée, mais la Session 2 a vu des données erronées.

  Comment s'en prémunir ?

  • Mettre l'isolation en READ COMMITED
  • Utiliser des verrous explicites (LOCK TABLE) pour éviter qu'une autre transaction accède aux données en cours de modification.

# Notions ACID des SGBDRs

Une lecture non répétable survient lorsqu'une transaction lit deux fois la même donnée, mais qu'entre-temps, une autre transaction l’a modifiée et validée.

Lecture non répétable

Session 1 :
SELECT solde_compte FROM comptes WHERE code_compte = 'CC001';
-- Résultat : CHF 1000
Session 2 :
UPDATE comptes SET solde_compte = solde_compte - 200 WHERE code_compte = 'CC001';
COMMIT;
Session 1 :
SELECT solde_compte FROM comptes WHERE code_compte = 'CC001';
-- Résultat : CHF 800 (différent de la première lecture)

  Comment s'en prémunir ?

  • Mettre l'isolation en REPEATABLE READ
  • Utiliser des verrous explicites (SELECT FOR UPDATE ou LOCK TABLE) pour éviter qu'une autre transaction accède aux données en cours de modification.

# Notions ACID des SGBDRs

Une lecture fantôme se produit lorsqu'une transaction lit un ensemble de lignes avec une condition donnée, puis une autre transaction insère de nouvelles lignes correspondant à cette condition avant que la première transaction ne se termine.

Lecture fantôme

Session 1 :
SELECT * FROM comptes WHERE solde_compte > 500;
-- 3 comptes affichés
Session 2 :
INSERT INTO comptes (code_compte, solde_compte) VALUES ('CC002', 600);
COMMIT;
Session 1 :
SELECT * FROM comptes WHERE solde_compte > 500;
-- 4 comptes affichés au lieu de 3 !

  Comment s'en prémunir ?

  • Mettre l'isolation en SERIALIZABLE
  • Utiliser des verrous explicites (LOCK TABLE) pour éviter qu'une autre transaction accède aux données en cours de modification.

# Notions ACID des SGBDRs

Un interblocage survient lorsque deux transactions se bloquent mutuellement, chacune attendant qu'une ressource détenue par l'autre soit libérée.

Interblocage (Deadlock)

Session 1 :
UPDATE comptes SET solde_compte = solde_compte - 100 WHERE code_compte = 'EP001';
-- Transaction non validée (en attente)
Session 2 :
UPDATE comptes SET solde_compte = solde_compte - 200 WHERE code_compte = 'CC001';
-- Transaction non validée (en attente)

Comment s'en prémunir ?

  • Modifier les données dans le même ordre
  • Utilisation des timeout WAIT ou NOWAIT pour retourner une erreur
Session 1 :
UPDATE comptes SET solde_compte = solde_compte - 100 WHERE code_compte = 'CC001';
-- BLOQUÉ et en attente car détenu par Session 2
Session 2 :
UPDATE comptes SET solde_compte = solde_compte - 200 WHERE code_compte = 'EP001';
-- BLOQUÉ car détenu par Session 1 → DEADLOCK !

Exercice de gestion des transactions

https://divtec.gitbook.io/ict-106

Exercice 8.1

Exercice de gestion des transactions et

des exceptions :

# Notions ACID des SGBDRs

Merci de votre attention 😊
Bonne fin de journée !