Tme Transactions
Les objectifs: mettre en place des situations de concurrence entre transactions. Comprendre les mécanismes de contrôle de concurrence.
Documentation
- Livre Concepts:
8i, chap 24 - Les vues du dictionnaire 8i : v$lock, v$locked_object, user_objects, dba_waiters, v$session, v$transaction, v$session_event, v$session_wait
Préparation
- Lire PréparationTme, et obtenir votre login oracle
- décompresser l'archive trans-etu.tgz
Une BD contient un stock de produits. Pour chaque produit, on a le n°, le nom et la quantité restant en stock.
- Produit(num, nom, reste)
Depuis sqlplus, exécuter le fichier nommé produit.sql pour créer la base
- SQL> @produit
Chaque transaction effectue des opérations parmi les suivantes.
Lecture d'un tuple:
- L(A) : select * from Produit where num = 1;
- L(B) : select * from Produit where num = 2;
- L(C) : select * from Produit where num = 3;
Ecriture d'un tuple :
- E(A) : update Produit set reste=&1 where num = 1;
- E(B) : update Produit set reste=&1 where num = 2;
- E(C) : update Produit set reste=&1 where num = 3;
- D(A): update Produit set reste=reste*2 where num = 1 (doubler la quantité restante);L(A);
Modification du schéma d'une relation
- SR : alter table Produit modify (nom varchar2(15));
Ouvrir 2 fenêtres de terminal, juxtaposées l'une en haut à gauche de l'écran, l'autre en bas à gauche (certaines questions peuvent nécessiter d'ouvrir une troisième fenêtre)
Dans chaque fenêtre
- cd trans-etu (aller dans le répertoire de travail)
- récupérer le numéro de terminal par la commande tty
- sqlplus L3NNN/L3NNN@oracle (se connecter au SGBD)
Choisir le niveau d'isolation read committed :
- SQL> alter session set isolation_level = read committed; (voir fichier isol1.sql)
- le niveau d'isolation est fixé pour toutes les transactions d'une session (= un terminal)
- il est possible de changer le niveau d'isolation uniquement en début de transaction (au début de la session ou juste après un commit).
Prendre connaissance de tous les fichiers sql situés dans votre répertoire de travail.
Ex1 : Verrouillage
Réaliser les expériences montrant le fonctionnement du gestionnaire de verrous. Ci-après, chaque séquence d'opérations est représentée par un tableau. L'axe horizontal représente le temps. L'opération de la colonne n+1 débute après l'opération de la colonne n. Exécuter T1 dans le 1er terminal, et T2 dans le 2ème.
Une lecture peut-elle être bloquante ?
- L1(A) ne bloque pas L2(A)
| T1 | L(A) | |
| T2 | L(A) |
- L1(A) ne bloque pas E2(A)
| T1 | L(A) | |
| T2 | E(A) |
Une lecture peut-elle être bloquée ?
- L2(A) non bloquée par L1(A) (voir ci-dessus)
- L2(A) non bloquée par E1(A)
| T1 | E(A) | commit | ||
| T2 | L(A) | commit |
La transaction T2 voit-elle l'écriture faite précédemment par T1 ? Quel est l'ordre en série équivalent à cette exécution ? Est-ce le même que l'ordre chronologique des commit, pourquoi ?
Une écriture peut-elle être bloquante ou bloquée ?
E2(A) bloquée par E1(A): Vérifier que T2 est en attente d'un verrou exclusif sur A.
| T1 | E(A) | |
| T2 | E(A): attente |
Quelles requêtes sur le dictionnaire affichent les infos suivantes ?
1. la liste des tables pour lesquelles une session en attend une autre, avec les numéros des sessions concernées, le mode de verrou demandé et celui accordé. Utiliser dba_waiters, v$locked_object , v$session et user_objects.
2. la liste des estampilles (SCN) des transactions actives (ayant déjà fait au moins une écriture ) ainsi que le numéro de session correpondant , triées par nom d'utilisateur. Utiliser v$transaction et v$session (voir les attributs addr et taddr)
3. la liste des sessions et le terminal associé. Utiliser v$session.
Que se passe-t-il lorsque T1 valide, lorsque T1 abandonne (rollback) ?
| T1 | E(A) | commit ou rollback | |
| T2 | E(A): attente | .... |
Granularité du verrouillage
- Vérifier qu'E2(B) n'est pas bloquée par E1(A)
Une lecture est-t-elle bloquée par une écriture SR qui modifie le schéma d'une relation ?
- a) Une écriture E2(A) est-ellle bloqué par SR1 ?
| T1 | SR | |
| T2 | E(A) attente ? |
- b) Une écriture SR2 est-ellle bloqué par E1(A) ?
| T1 | E(A) | |
| T2 | SR attente ? |
- Quels sont les verrous demandés avant de traiter E(A) et SR ?
Interblocage
Vérifier l'interblocage suivant:
| T1 | E(A) | E(B) | |
| T2 | E(B) | E(A) |
Comment résoudre l'interblocage sans abandonner T1 ? Définir une situation d'interblocage qui implique 3 transactions (sans attente mutuelle directe entre 2 transactions). On souhaite abandonner la transaction la plus récente. Quelle requête du dictionnaire affiche la date de début des transactions actives ? Voir l'estampille system change number (SCN) d'une transaction.
Ex2 : Sérialisation
Pour cet exercice, le niveau d'isolation des sessions est serializable
- SQL> alter session set isolation_level = serializable; (ou @isol2)
a) La séquence suivante est-elle sérializable ? Si oui, quel est l'ordre en série équivalent?
| T1 | L(A) | ED(A) | ||
| T2 | E(A) | commit |
Que se passe-t-il ?
b) La séquence suivante est-elle sérializable ? Si oui, quel est l'ordre en série équivalent?
| T1 | L(A) | E(A) | ||
| T2 | E(A) | commit |
Pourquoi cette séquence est-t-elle refusée ?
c) La séquence suivante est-t-elle sérializable ? Si oui, quel est l'ordre en série équivalent?
| T1 | L(B) | E(A) | ||
| T2 | E(A) | commit |
Pourquoi cette séquence est-t-elle refusée ?
d) Recommencer en modifiant les niveaux d'isolation de T1 et de T2. (voir fichiers isol1 et isol2) Est ce possible de garantir le niveau d'exécution sérializable pour T2, lorsque T1 est au niveau read committed ? Commenter les résultats obtenus.
Doc Diverses
TmeTransactionSupplément (suite de l'exercice sur la sérialisation)