Discussion :

[sygale]

Bonjour, je recherche des explications sur les différents types de lock, j'ai trouvé ce post :
http://www.developpez.net/forums/vie...ighlight=locks

Mais peut on m'expliquer les decodes suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
DECODE ( 
            wk.TYPE, 
            'MR', 'Media Recovery', 
            'RT', 'Redo Thread', 
            'UN', 'USER Name', 
            'TX', 'Transaction', 
            'TM', 'DML', 
            'UL', 'PL/SQL USER LOCK', 
            'DX', 'Distributed Xaction', 
            'CF', 'Control FILE', 
            'IS', 'Instance State', 
            'FS', 'FILE SET', 
            'IR', 'Instance Recovery', 
            'ST', 'Disk SPACE Transaction', 
            'TS', 'Temp Segment', 
            'IV', 'Library Cache Invalidation', 
            'LS', 'LOG START OR Switch', 
            'RW', 'ROW Wait', 
            'SQ', 'Sequence Number', 
            'TE', 'Extend TABLE', 
            'TT', 'Temp TABLE', 
            wk.TYPE 
         ) lock_type, 
         DECODE ( 
            hk.lmode, 
            0, 'None', 
            1, 'NULL', 
            2, 'ROW-S (SS)', 
            3, 'ROW-X (SX)', 
            4, 'SHARE', 
            5, 'S/ROW-X (SSX)', 
            6, 'EXCLUSIVE', 
            TO_CHAR (hk.lmode) 
         ) mode_held, 
         DECODE ( 
            wk.request, 
            0, 'None', 
            1, 'NULL', 
            2, 'ROW-S (SS)', 
            3, 'ROW-X (SX)', 
            4, 'SHARE', 
            5, 'S/ROW-X (SSX)', 
            6, 'EXCLUSIVE', 
            TO_CHAR (wk.request) 
         ) mode_requested,

lock_type
Renseigne la provenant du lock ?

mode_held
Que signifie les valeurs :
- None : Pas de lock ?
- NULL : Pas de lock ?
- ROW-S (SS) :
- ROW-X (SX) : juste un update ?
- SHARE :
- S/ROW-X (SSX) :
- EXCLUSIVE :


mode_requested
Je suppose que c'est la même siginification que pour mode_held non ?

Merci

[bouyao]

ENQUEUE est un mécanisme de verrous très sophistiqué qui consiste à gérer les accès au ressources partagés, il peuvent être des tables, des transactions ou tous autres structures representants quelque chose pratageable entre sessions. Normalement il est utilisé pour éviter que plusieurs processes accedent à la même structure de données en même temps.

On associe un Enqueue à une session ou à une transaction et non pas à un processe, et il est souvent synonyme au mot LOCK et on peut le trouver dans la vue V$LOCK.

Chaque Enqueue est identifié par un nom unique de la forme : <TYPE-ID1-ID2>.

TYPE : est un mot de deux lettres (exemple : MR, RT, XR, TS, TX, TM)

ID1 et ID2 sont deux identifiants numériques de 4 bits qui depends du type de verrou. Avant oracle 10g ces deux valeurs n'etaient pas publique, a partir de la 10g vous pouvez trouver facilement leurs significations dans les colonne PARAMETER2 et PARAMETER3 de la vue V$EVENT_NAME.

Type de verrou TX

ID1 : Indique le rollback segement et le numéro du slot (fente).
Ces valeurs se trouvent dans les colonnes XIDUSN et XIDSLOT de la
Vue V$TRANSACTION.

ID2 : Wrap du rollback segement ou le numéro de sequence. Cette valeur se
trouve dansla colonne XIDSQN de la vue V$TRANSACTION.

Type de verrou TM

ID1 : Indique l'id objet de la table, on le trouve dans
DBA_OBJECTS.OBJECT_ID

ID2 : 0

Type de verrou TS

ID1 : le numéro de la tablespace qu'ont peut le trouver dans TS#.TS#.

ID2 : Adresse relatif du bloc de la base RDBA

Type de verrou JQ

ID1 : 0

ID2 : Indique le numéro du job

Type de verrou MR

ID1 : Id du fichier de données. Oracle accepte un enqueue MA par fichier de
Données

ID2 : 0

Type de verrou RT

ID1 : le numéro du redo thread

ID2 : 0

Par exemple pour la table EMP de l'utilisateur SCOTT il existe un seul Enqueue identifié par :

TYPE = TM
ID1 = identifiant de l'objet EMP
ID2 = 0

BL : Buffer hash table instance
CF : Control file schema global enqueue
CI : Cross-instance Call Invocation
CU : Bind Enqueue
DF : Datafile
DL : Direct Loader Index Creation
DM : Database Mount
DR : Distributed Recovery
DX : Distributed TX
FS : File Set
HW : HighWater Mark
IN : Instance Number
IR : Instance Recovery
IS : Etat de l'instance
IV : Library Cache Invalidation
JQ : Job Queue
KK : Redo Log "Kick"
LA ..LP : Library Cache Lock
MM : Mount definition global enqueue lock
MR : Media Recovery
NA .. NZ : Library Cache Pin
PF : Password File
PI : Parallel Slaves
PR : Process Startup
PS : Parallel Slave Synchronizatio
QA .. QZ : Row Cache
RT : Redo Thread
SC : System Commit Number
SM : SMON
SN : Sequence number instance lock
SQ : Sequence Number Enqueue
SS : Sort Segment
ST : Space Management Transaction
SV : Sequence Number Value
TA : Transaction Recovery
TS : (id2=1)Nouvelle attribution de bloc
TS : (id2=0) Segment temporaire (toujours une tablespace)
TT : Table temporaire
TX : Transaction
UL : User-defined Locks
UN : Nom de l'utilisateur
US : Serialisation du segement undo
WL : Début d'ecriture dans le redo log
XA : Verrou d'attribution de l'instance
XI : Verrou de registration de l'instance


Le mode Exclusive interdit qu'une ressource soit partagée. Ce mode de blocage est obtenu suite à une modification de données. La première transaction qui bloque la ressource en mode exclusive est la seule qui est capable de liberer cette ressource.

Le mode partagée consiste à partagé les ressources, suivant l'operation impliqué. Plusieurs utilisateurs en mode lectures peuvent partagés ces données, avoir un verrouillage partagée previent l'access en mode écriture (surtout celui qui a besoin un verrouillage en mode exclusive). Plusieurs transactions peuvent avoir un verrouillage partagés dans une même ressource.

SS : verrou un enregistrement en mode partagé
SX : verrou un enregistrement en mode exclusive
S : verrou la table entirement en mode partagée
SSX : verrou la table en mode partagée mais l' enregistrement en mode exclusive

X : verrou la table entirement en mode exclusive

Les modes d'Enqueues ou de Verrous n'a aucun sens réel tout seule. Le vrai sens de ses modes est la manière d'être utilisés. (R: lecture, W: écriture)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
Operation	Mode de verrou	LMODE	Description
Select			NULL	1	Null
Select for update	SS	2	Sub share
Insert			SX	3	Sub exclusive
Update			SX	3	Sub exclusive
Delete			SX	3	Sub exclusive
Lock for update		SS	2	Sub share
Lock Share		S	4	Share
Lock Exclusive		X	6	Exclusive
Lock Row Share		SS	2	Sub share
Lock Row Exclusive	SX	3	Sub exclusive
Lock Share Row ExclusiveSSX	5	Share/sub exclusive
Alter table		X	6	Exclusive
Drop table		X	6	Excusive
Drop Create index	S	4	Share
Drop index		X	6	Exclusive
Truncate table		X	6	exclusive

[sygale]

Super, c'est un doc en ligne ?

[bouyao]

C'est mon première tuto que je n'ai pas encore mis en ligne.

[sygale]

C'est mon première tuto que je n'ai pas encore mis en ligne.

Tu sais que tu pourrrais faire des heureux avec ce genre de truc toi ??

[bouyao]

Les enqueus sont utilisés pour contrôler l'accès au ressources partagés. En interne ces ressources sont representés par une structure de ressource.

Quand une session veut acquerir un enqueue, une structure de verrou est obtenus et une demande est crée pour avoir l'accès au ressource à un ceratin niveau (mode).

La structure de verrou est :

 dans la liste OWNER si la session à acqui un verrou
 dans la liste WAITER si la session attend d'avoir un verrou
 dans la liste CONVERTER si la session à acqui un verrou, mai elle attend que le verrou soit converti dans un autre mode.




La table des ressources se trouvent dans la mémoire SGA. Le nombre total de lignes dans la table de ressources est determiné par le parametre d'initialisation ENQUEUE_RESOURCES. Normalement la valeur par defaut est suffisante, par contre vous devez augmenter cette valeur si vos applications utilisent des opération DML en paralleles.

Les opération DML en pralleles utilisent plus de verrous que les opération DML en series.

Quand un process n'arrivent pas à avoir une ressource enqueue alors il obient l'erreur ORA-00052: "maximum number of enqueue resources exceeded". La vue V$REOURCE_LIMIT nous donnent des statistiques importante, comme l'utilisation actuelle, la taille du high watermark (MAX_UTILIZATION) par rapport à la limite (LIMIT_VALUE).

A partir d'oracle 8, le parametere ENQUE_RESOURCE fixe la taille du tableau X$KSQRS, et depuis oracle 9i oracle utilise d'autres algorithmes pour établir la taille du tableau X$KSQRS.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
Select * from v$resource_limit
Where resource_name in ('enqueue_resources','enqueue_locks','dml_locks','processes','sessions');
 
RESOURCE_NAME	CURRENT_UTILIZATION	MAX_UTILIZATION	INITIAL_ALL	LIMIT_VALU
Processes		438			643			2000		2000
Sessions			443			664			2205		2205
Enqueue_locks		402			465			27101		27101
Enqueue_resources	449			584			800		UNLIMITED
Dml_locks		68			778			600		UNLIMITED

Oracle utilise differents tableaux au lieu des tableaux de ressources enqueue pour gerer les verrous enqueue. Cette structure on peut la voir dans la vue X$KSQES (kernel service enqueue object) ou dans la vue V$ENQUEUE_LOCK. La taille de cette structure est défini par le parametre "_ENQUEUE_LOCKS".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Select * from x$ksqeq where bitand(kssobflg,1)!=0 and (ksqlkmod!=0 or ksqlkreq!=0);

Ou simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select * from v$enqueue_lock;

Il ne faut pas être surpris si vous ne voyez pas les verrous (TX) et (TM ) dans la vue V$ENQUEUE_LOCK. Ils ne sont pas dans la structure de X$KSQEQ.
/*
Oracle utilise differents structures pour gerer les enqueues TX et TM :

X$KTCXB (kernel transaction control transaction object) basé sur la vue V$TRANSACTION_ENQUEUE

X$KTADM (kernel transaction access definition dml lock).

X$KTCXB (kernel transaction control transaction object) basé sur la vue V$TRANSACTION_ENQUEUE

X$KTADM (kernel transaction access definition dml lock).

La taille des structures sont définies par les parametres TRANSACTION et DML_LOCKS. La vue V$LOCK est la meilleur car il affiche tous les verrous.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
Select * from x$ktcxb
Where KTCXBLKP in (select kaddr from v$lock where type='TX');
 
Select * from x$ktadm
Where KSQLKADR in (select kaddr from v$lock where type='TM');

La libération d'un verrous est réalisé par la session suite à un COMMIT ou un DLL (c.a.d Commit implicite), ou par SMON si la session à été tué (killed).

La Conversion est le proccessus de modifier un verrou d'un mode acqui à un autre mode different.

L'acquisition d'un verrou est le processus d'avoir un verrou dans une ressource dont laquelle on'a pas actuellement un verrou.

Si un verrou n'a pas pu être acqui ou converti, alors il y'aura un Deadlock et sera generé par la session en attente après un certain tiemout.

Les informations verrous et ressources se trouvent dans le SGA pour que PMON restaure si echec d'un processe. Le PMON est responsable de liberer des verrous si les processes sont tués ou un crash.



Dans cette exemple

On'a une structure de ressource sur l' enqueue <TM-123-0> ,

Etape 1. La session 1 tient un verrou partagé sur la table ayant comme id de l'objet 123. Il reste dans la liste Owners tant qu'il tient le verrous. En plus, la session 1 veut convertir l'enqueue du mode partagée en mode exclusif. La session 2,3 et 4 attends d'avoir un verrou, alors ils sont dans la liste Waiters.

Etape 2. Comme la liste owners est vide alors la session 1 convertit son mode. Dans ce cas la session 2 attends aussi un mode exclusif ce qui est incompatbile avec celui de la session 1. Donc la session 2 attends. La session 3 et 4 attends car dans la file d'attentente Waits ne sont pas prioritaire (FIFO).

Etape 3. Quand le verrou est liberé par la session 1, la liste converters est vérifié (dans ce cas il est vide) puis après la liste waiters, dans cet ordre. La session 2 est dans l'entête de la liste waiters, alors il acquis le mode exclusif. La session 3 se met dans l'entête de la liste waiters, comme son mode est incompatible avec celui du owners (session2), alors il attends.

Etape 4. La session 2 libere son verrou. La liste converters est vide, alors la session 3 acquis un verrou en mode partagé, comme le mode de la session 4 est compatible avec celui de l'owners, alors elle aussi acquis un verrou.


Voila je sais que c'est un peu dure à comprendre mais je suis ici pour te repondre.