TP ORACLE 3 Solutions - Cedric

TP ORACLE 3
Solutions
Francois Barthélémy∗et Cédric du Mouza∗
1 Administration
1.1 Création des tables
1. create table Games (
codeG number(10),
nomG varchar2(40),
genre varchar2(40),
annee number(4),
codeEd number(10),
prix number (5,2),
CONSTRAINT Games_codeG_pk PRIMARY KEY (codeG),
CONSTRAINT Games_codeEd_fk FOREIGN KEY (codeEd) REFERENCES Editeur(codeEd)
);
CREATE INDEX Games_codeEd_idx ON Games(codeEd); CREATE INDEX Games_prix_idx ON
Games(prix);
2. create table Editeur (
codeEd number(10),
nomEd varchar2(40),
pays varchar2(40),
fondation number(4),
CONSTRAINT Editeur_codeEd_pk PRIMARY KEY (codeEd)
);
CREATE INDEX Editeur_pays_idx ON Editeur(pays);
1.2 Utilisation des tables
1. insert into Editeur
values(2,’Blizzard’,’USA’,1994);
2. insert into Games
values(2,’Warcraft 3’,’Temps-reel’,2004,2,50);
3. delete from Games
where nomG = ’Warcraft 3’;
1
Lab. CEDRIC, équipe VERTIGO, CNAM, Paris, France, {barthe,dumouza}@cnam.fr
1
4. delete from Editeur
where nomEd = ’Blizzard’;
5. update Games
set prix = 10
where nomG = ’The Sims’;
6. update Games
set prix = 20
where codeEd = (select codeEd from Editeur where nomEd = ’Ubisoft’;
7. rollback;
2 Concurrence
2.1 Niveau read-commited
On constate que le verrouillage à deux phases d’ORACLE est un peu libéral. Le comportement par défaut
consiste, pour simplifier, à faire travailler chaque transaction de manière isolée sur une copie de la base (en
fait pour être plus précis chaque transaction copie ses modifications dans un espace mémoire dédié, modifications visibles par cette seule transaction). Quand la transaction est validée par un commit alors ses
modifications sont appliquées réellement à la base et deviennent visibles à tous.
Dans ce mode les lectures ne sont pas verrouillées (pas de verrou de lecture!), mais seules les modifications réalisées par la transaction faisant la lecture, ou alors les modifications réalisées par des transactions
validées, seront visibles. Par contre les écritures disposent d’un verrou. Ainsi si une transaction veut écrire
sur une ressource qu’une autre transaction a déjà modifiée, il faut attendre la fin de la transaction ayant pris
le verrou en écriture pour continuer. La transaction reste bloquée en attedant le verrou, conduisant parfois à
un interblocage.
Il est aisé de voir que ce verrouillage ne garantit pas la sérialisabilité... un exemple parmi 1000,
r1 .w2 [f if a].r2 .w1 [war3].c1 .c2 .
2.2 Avec verrou en lecture
Il est possible de verrouiller une ligne en lecture explicitement avec la clause FOR UPDATE. Chaque ligne
accéder par le select avant cette clause est verrouillée à la fois en lecture et écriture et donc seule la transaction avec le verrou peut accéder en lecture/écriture sur la ligne ainsi verrouillée. Il s’agit ici d’une restriction
très forte. On obtient des exécutions sérialisables pour une raison très simple... il n’existe plus un seul
conflit!!
2