Les transactions ACID

BEGIN, COMMIT, ROLLBACK et SAVEPOINT, la validation automatique, les quatre propriétés ACID (atomicité, cohérence, isolation, durabilité) et le journal qui les tient.

  • 24 cartes
  • 4 thèmes
  • Gratuit

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation

Quelques cartes du deck

  • Transaction : de quoi s'agit-il ?

    Voir la réponse

    Suite d'opérations sur la base traitée comme un tout indivisible : elle est validée en entier avec COMMIT, ou annulée en entier avec ROLLBACK.

    Un virement bancaire se compose d'un débit et d'un crédit. Sans transaction, une coupure entre les deux fait disparaître de l'argent ; avec elle, les deux opérations passent ou aucune.

  • Les soldes valent 500 et 200 au départ. Que renvoie le dernier SELECT ?

    ```sql
    BEGIN;
    UPDATE compte SET solde = solde - 100 WHERE id = 1;
    ROLLBACK;
    SELECT solde FROM compte WHERE id = 1;
    `

    • 500
    • 400
    • 100
    • NULL
    Voir la réponse

    500

    ROLLBACK défait tout ce que la transaction a fait depuis BEGIN : le débit est annulé et la ligne retrouve sa valeur de départ.

  • Hors d'un BEGIN explicite, la plupart des bases valident chaque instruction toute seule : c'est la … (autocommit).

    Voir la réponse

    Hors d'un BEGIN explicite, la plupart des bases valident chaque instruction toute seule : c'est la validation automatique (autocommit).

    Chaque UPDATE est alors sa propre transaction. Deux UPDATE successifs ne sont donc pas atomiques ensemble : il faut les entourer de BEGIN et COMMIT.

  • ACID : de quoi s'agit-il ?

    Voir la réponse

    Les quatre garanties d'une transaction : atomicité, cohérence, isolation, durabilité.

    Les quatre lettres donnent les quatre propriétés dans l'ordre : Atomicity, Consistency, Isolation, Durability. Chacune écarte un type d'incident différent.

  • Après une coupure, 100 € ont quitté le compte A sans arriver sur le compte B. Les deux UPDATE du virement sont exécutés l'un après l'autre en validation automatique. Quelle correction ?

    • Ajouter un SAVEPOINT entre les deux UPDATE
    • Les entourer de BEGIN et COMMIT pour qu'ils forment une seule transaction
    • Passer la transaction au niveau d'isolation SERIALIZABLE
    • Ajouter un COMMIT après chaque UPDATE pour les rendre durables
    Voir la réponse

    Les entourer de BEGIN et COMMIT pour qu'ils forment une seule transaction

    Le défaut est l'atomicité : sans bornes, chaque UPDATE se valide seul. Un SAVEPOINT ne protège pas d'une panne, et l'isolation règle les accès simultanés, pas les coupures.