RecentChanges
|
FindPage
|
LikePages
|
BackLinks
View Source:
TmeConcurrence
Note:
This page has been locked and cannot be edited.
!!! TME Contrôle de concurrence Les objectifs: mettre en place des situations de concurrence entre transactions. Comprendre les mécanismes de contrôle de concurrence. !!Documentation * Livre Concepts: [chapitre 13|http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14220/consist.htm#g43931]. * Livre Performance tuning: [chapitre 10|http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14211/sql_1016.htm#sthref1060] * Les vues du dictionnaire : [dba_blockers| http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14237/statviews_3062.htm#sthref1967], [ dba_waiters| http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14237/statviews_4178.htm#sthref2769], [v$lock| http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14237/dynviews_1147.htm#REFRN30121], [v$session_event | http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14237/dynviews_2091.htm#REFRN30226], [v$session_wait| http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14237/dynviews_2094.htm#REFRN30229], [v$session | http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14237/dynviews_2088.htm#REFRN30223], [v$active_session_history | http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14237/dynviews_1007.htm#REFRN30299] * Divers : une notice pour identifier [quel nuplet est à l'origine d'un blocage |http://www-master.ufr-info-p6.jussieu.fr/2006/Ext/naacke/abdr2008/extra/tme/What_s_blocking_my_lock.pdf] !!Préparation * les vues mesurant les durées d'attente (v$waitstat, etc...) ne sont renseignées que si le paramètre d'initialisation timed_statistics vaut ''true''. Vérifier la valeur de ce paramètre en interrogant la vue [v$parameter| http://www-ari.ufr-info-p6.jussieu.fr/OUTILS/documentation/doc/oracle/doc10G-2/server.102/b14237/dynviews_2012.htm#REFRN30176]. Eventuellement modifier sa valeur avec la commande : ** SQL> alter session set timed_statistics = true * Schema: Employe(num, ...) * lecture d'un tuple: L(A) : select * from Employe where num = 1 * écriture ** E(A) : update Employe set age=age+1 where num=1 ** E(B) : update Employe set age=age+1 where num=2 Ouvrir 2 fenêtres de terminal Dans chaque fenêtre * lancer sqlplus etuNN/etuNN@ora2 dans chaque fenêtre * Choisir le niveau d'isolation (read committed ou serializable) ** SQL> alter session set isolation_level = read committed ** le niveau d'isolation est fixé pour toutes les transactions d'une session (= un terminal) ** il est possible de changer le niveau d'isolation en __début__ de transaction (juste après un commit) !! Ex1 Verrouillage Réaliser les expérience montrant le fonctionnement du gestionnaire de verrous d'oracle. !lecture non bloquante * L1A ne bloque pas L2A | __T1__ | L(A) | | __T2__ | | L(A) * L1A ne bloque pas E2A | __T1__ | L(A) | | __T2__ | | E(A) !lecture non bloquée * L2A non bloquée par L1A (voir ci-dessus) * L2A non bloquée par E1A | __T1__ | E(A) | | commit | | __T2__ | | L(A) | | commit T2 voit-elle l'écriture faite précédemment par T1 ? Quel est l'odre en série équivalent à cette exécution ? Est-ce le même que l'ordre chronologique des commit, pourquoi ? !Ecriture bloquante E2A bloquée par E1(A): Vérifier que E2(A) est en attente d'un VX sur A. | __T1__ | E(A) | | __T2__ | | E(A): attente Quelles requêtes sur le dictionnaire affichent les infos suivantes ? * la liste des verrous détenus par T1 * la liste des transactions en attente du verrou sur A détenu par T1 Que se passe-t-il lorsque T1 valide, lorsque T1 abandonne ? | __T1__ | E(A) | | commit | __T2__ | | E(A): attente | .... Recommencer en modifiant les niveaux d'isolation de T1 et de T2. 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. ! 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 qui modifie le ''schéma'' de la base ? ** M(Emp) : alter table Emp ... | __T1__ | M(Emp) | | __T2__ | | L(A): attente ? * Une écriture E2(A) est-ellle bloqué par M1(Emp) * Une écriture M2(Emp) est-ellle bloqué par E1(A) * Quels sont les verrous demandés avant de traiter E(A) et M(Emp) ? !Interblocage Vérifier l'interblocage suivant: | __T1__ | E(A) | E(B) | | __T2__ | E(B) | | E(A) Comment résoudre l'interblocage sans abandonner T2 ? Donner 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 La séquence suivante est-elle sérializable ? | __T1__ | L(A) | | | E(A) | __T2__ | | E(A) | commit | Que se passe-t-il ? 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 est-t-elle refusée ? !! Ex3 Impact du verrouillage sur les performances La granularité du verrouillage, au niveau d'un tuple ou d'une table toute entière, a-t-elle un effet sur les performances ? 1) Réaliser une expérience avec 4 sessions effectuant des mises à jour en concurrence. Chaque session exécute une procédure qui traite une séquence de 1000 écritures. * E(n): update Emp set age = age+1 where num = v . La valeur ''v'' de l'attribut num est choisie aléatoirement. * valider chaque mise à jour individuellement (commit). Déterminer le nombre total de mise à jour qui ont été retardées par l'attente d'un verrou. 2) Reprendre l'expérience en augmentant le nombre de mises à jour par transaction : effectuer un commit toutes les N mises à jour. Choisir N=100. A quel moment les verous sont-ils relachés ? A partir de quelle valeur de N observe-t-on un interblocage ? Lorsqu'il n'y a pas d'interblocage, déterminer le nombre total de mises à jour qui ont été retardées par l'attente d'un verrou. 3) Modifier l'expérience en demandant un verrou sur la table Emp avant chaque mise à jour, puis en le relachant juste après (commit). * lock table emp ...; update ...; comit; Déterminer le nombre total de mise à jour qui ont été retardées par l'attente d'un verrou. Observe-t-on un interblocage lorsque on augmente de nombre N de mises à jour par transaction ? Pourquoi ? Donner pour différentes valeurs de N, la durée d'attente totale de chaque session. Questions facultatives 4)La session 1 effectue des transactions avec N mises à jour par transactions. Par contre, les 3 autres sessions effectuent une seule mise à jour par transaction. Dans ces conditions, un interblocage peut-il se produire ? Pourquoi ? Modifier la session 1 pour que son niveau d'isolation soit ''serializable''. A partir de quelle valeur de N observe-t-on l'occurence d'une séquence non sérializable ? Les séquences non sérializables étant détectées et refusées par Oracle, proposer une solution pour poursuivre la session 1 en recommençant les transactions contenant une mise à jour refusée. 5) Proposer une expérience montrant le relachement partiel des verrous lors d'un rollback to savepoint. Cela a-t-il un impact sur les transactions déja en attente du verou avant le rollback to savepoint ? Pourquoi? ---- LesTme