Oracle
 sql >> Base de données >  >> RDS >> Oracle

Verrous Oracle et verrous de table :comment ça marche

La base de données Oracle est la base de données largement utilisée dans l'industrie. Ici, j'essaie d'expliquer les verrous Oracle, les verrous de table Oracle

Table des matières

  • Qu'est-ce qu'Oracle Enqueue et les verrous
  • Qu'est-ce qu'un identifiant de file d'attente
  • Qu'est-ce que la ressource Enqueue ?
  • Comment se fait la recherche dans le tableau des ressources ?
  • Comment fonctionnent les opérations de mise en file d'attente ?
  • Comment la file d'attente est vérifiée lorsque le verrou Oracle est libéré ou converti
  • Types courants de mise en file d'attente
  • Vues et tableau pour afficher la mise en file d'attente Oracle et les verrous Oracle
    • V$session et v$session_wait
    • V$locked_object
  • Comment les verrous DML sont-ils gérés dans le serveur Oracle
  • Comment les verrous de table Oracle sont implémentés
  • Comment désactiver les verrous de table ?
  • Comment les verrous de ligne DML sont mis en œuvre
  • Qu'est-ce que la liste des transactions intéressées (ITL)
  • Qu'est-ce qu'une transaction ?
  • Exemple détaillé pour expliquer le fonctionnement des verrous oracle
  • Cours recommandés

Qu'est-ce qu'Oracle Enqueue et les verrous

Les files d'attente sont des verrous Oracle qui sérialisent les opérations dans la structure partagée. La structure partagée peut être une table, des threads de rétablissement et des transactions.

Lorsqu'un utilisateur A met à jour une ligne 12 de la table, il acquiert la transaction Enqueue (lock). Ceci est acquis de sorte que tout utilisateur que j'essaie de mettre à jour cette même ligne 12 dans la table attendra que l'utilisateur A valide la transaction. Alors maintenant, si l'utilisateur B essaie de mettre à jour la même ligne, il attendra dans la file d'attente.

Une fois que l'utilisateur A a validé la transaction, la transaction de l'utilisateur B se poursuivra

Nous avons une mise en file d'attente locale dans la base de données d'instance unique tandis qu'avec Oracle RAC, nous avons une mise en file d'attente locale et une mise en file d'attente globale pour gérer la ressource partagée

Qu'est-ce que l'identifiant de mise en file d'attente ?

Les files d'attente sont identifiées de manière unique à l'aide du format

La ressource peut

TM -> verrous de table

MR-> Récupération de média

TX-> Transaction

Id1 et id2 sont des nombres différents pour différents types de ressources

Comme pour le verrou de table (TM), il s'écrit

TM--0

Lorsqu'un utilisateur demande l'accès à la ressource dans un certain mode, un identifiant de mise en file d'attente est généré, comme expliqué ci-dessus

La mise en file d'attente est maintenue dans ces modes

SS : Mode de partage de lignes

SX :Mode exclusif de ligne

S :  Verrouiller le tableau en mode de partage

SSX :Verrouillez la table en mode partage et la ligne en mode exclusif

X :Verrouiller la table en mode exclusif

Qu'est-ce que la ressource Enqueue ?

Chaque file d'attente est maintenue via une structure de ressources par le serveur Oracle et elle est identifiée comme expliqué ci-dessus. Une structure de ressource a trois listes

  1. Liste des propriétaires
  2. Liste d'attente
  3. Liste des convertisseurs

Lorsqu'un utilisateur demande un verrou sur une ressource dans un certain mode, il obtient une structure de verrou et fait une demande pour acquérir le verrou sur une certaine ressource. Il est placé dans ces listes de la structure de ressource selon le verrou requis.

Ainsi, l'utilisateur  demande d'abord cette ressource, puis elle sera placée dans la liste des propriétaires

La structure des ressources est obtenue à partir de la table des ressources et la structure des verrous est obtenue à partir de la table des verrous. Elles sont toutes deux allouées dans SGA

Le nombre de lignes dans la table des ressources est défini par le paramètre d'initialisation enqueue_resources. Les valeurs utilisées peuvent être vues dans la vue v$resource

Le nombre de lignes dans la table de structure de verrouillage est défini par le paramètre d'initialisation _enqueue_locks. Les valeurs utilisées peuvent être vues dans v$enqueue_lock

Comment se fait la recherche dans le tableau des ressources ?

  • La table des ressources contient toute la structure des ressources. Un algorithme de hachage est utilisé pour trouver et accéder à la structure des ressources dans la table des ressources.
  • La table des ressources est organisée en compartiment de hachage. Chaque compartiment de hachage contient une liste de la structure des ressources sous forme de liste liée.
  • Lorsque la ressource est recherchée, son hachage est obtenu à l'aide d'un algorithme de hachage, puis le verrou est obtenu pour trouver le compartiment de hachage correspondant, puis la ressource est recherchée dans la liste du compartiment de hachage. Si la ressource est trouvée, la structure de verrouillage est obtenue et la demande est placée sur le propriétaire, le serveur et la liste de conversion selon le niveau de verrouillage spécifié demandé

Exemple de ressource TM-575-0 hachée dans le compartiment 1, une chaîne de hachage de mise en file d'attente de verrouillage est obtenue pour accéder au compartiment de hachage et la liste est accessible dans le compartiment pour obtenir la structure de la ressource

  • Si la ressource est introuvable dans la liste des compartiments et qu'une nouvelle structure de ressources est obtenue à partir de la liste des ressources libres et placée dans la liste des compartiments. Cela se produit sous le verrou Enqueue. Une structure de verrouillage est également allouée

La demande de verrouillage est placée sur la liste des propriétaires de la structure de ressource

Comment fonctionnent les opérations de mise en file d'attente ?

Lorsqu'un utilisateur demande un verrou sur la ressource, le serveur Oracle fait les choses suivantes

  • Si elle n'appartient pas actuellement, la ressource est accordée à l'utilisateur
  • S'il est possédé et qu'il y a des serveurs et un convertisseur, il est placé au bas de la file d'attente des serveurs
  • S'il est possédé mais qu'il n'y a pas de serveur et de convertisseur, s'il est compatible avec le verrou du propriétaire, la demande est accordée. S'il n'est pas compatible, il est placé sur la liste des serveurs
  • Un convertisseur est autorisé à continuer si la demande est moins restrictive que le verrou actuellement détenu ou si le mode demandé est compatible avec le verrou détenu par l'autre propriétaire
  • Un serveur est autorisé à continuer si la liste des convertisseurs est vide, s'il n'y a pas de serveur devant lui et que le verrou demandé est compatible avec le verrou dont il dispose actuellement
  • Le convertisseur est toujours traité avant les serveurs.
  • Le serveur Oracle vérifie ces files d'attente chaque fois que le verrou est libéré ou converti.

Comment la file d'attente est vérifiée lorsque le verrou Oracle est libéré ou converti

  • Les processus attendant les ressources dorment sur les sémaphores, et les sémaphores sont utilisés comme mécanismes de veille/réveil. Après s'être placé dans la file d'attente, le processus demandeur dormira sur le sémaphore à l'aide de l'appel sync_op.

sync_op(SYNC_WAIT, SYNCF_BINARY, 300) =1

  • Une fois que le processus contenant la ressource est prêt à libérer la ressource, il examine la file d'attente attachée à la structure de la ressource. S'il y a un processus dans la file d'attente, il envoie un signal de sémaphore au processus en attente en utilisant

appel sync_op.

sync_op(0x0005, SYNCF_BINARY, 134491620) =1

  • Le processus d'attente traitera le signal et se réveillera. Ce processus d'attente modifie le statut selon les étapes indiquées dans l'opération de mise en file d'attente

Types courants de mise en file d'attente

JQ – File d'attente des tâches. Lorsqu'un travail (soumis par DBMS_JOB.SUBMIT) est en cours d'exécution, il est protégé par une mise en file d'attente JQ (ce qui signifie qu'un seul processus SNP peut exécuter le travail).

ST – Transaction de gestion de l'espace . La mise en file d'attente ST doit être maintenue chaque fois que la session alloue/désalloue des étendues (ce qui signifie qu'elle souhaite modifier les tables de dictionnaire UET$ et FET$), comme la fusion, la suppression/troncature de segments et le tri sur disque. Si la session obtient un délai d'expiration lors de la demande de mise en file d'attente ST, "ORA-1575 délai d'attente pour la gestion de l'espace" est renvoyé.

TM – DML (Table)  mise en file d'attente. Chaque fois qu'une session veut verrouiller une table, une mise en file d'attente TM est demandée. Si une session supprime une ligne dans la table parent (DEPT) et qu'une contrainte référentielle (clé étrangère) est créée sans index sur la table enfant (EMP), ou si la session met à jour la ou les colonnes que la les références de clé à un verrou de partage (niveau 4) sont prises sur la table enfant. Si une autre session essaie d'apporter des modifications à la table enfant, elle doit attendre (car elle souhaite la mise en file d'attente en mode exclusif de ligne, ce qui n'est pas compatible avec le mode de partage). Si un index est créé sur la colonne de clé étrangère de la table enfant, aucun verrou partagé n'est requis sur la table enfant.

TX – Transaction. Dès qu'une transaction est lancée, une mise en file d'attente TX est nécessaire. Une transaction est définie de manière unique par le numéro de segment d'annulation, le numéro d'emplacement dans la table des transactions du segment d'annulation et le numéro de séquence du numéro d'emplacement. Une session peut être en attente sur une file d'attente TX pour plusieurs raisons :

1) Une autre session verrouille la ligne demandée.

2) Lorsque deux sessions essaient d'insérer la même clé unique dans une table (aucune d'entre elles n'a fait de COMMIT), alors la dernière session attend que la première COMMIT ou ROLLBACK.

3) Il n'y a pas d'ITL (liste de transactions intéressées) libre dans l'en-tête du bloc (augmentez INI_TRANS et PCT_FREE pour le segment).

UL - Verrouillage de l'utilisateur . Une session a pris un verrou avec la fonction DBMS_LOCK.REQUEST.

Vues et tableau pour afficher la mise en file d'attente Oracle et les verrous Oracle

V$session et v$session_wait

Lorsqu'une session est en attente de mise en file d'attente ou de verrouillage, il peut s'agir d'une session de V$session (en 11g et versions ultérieures) et de v$session_wait

Select * from v$session_wait where event like ‘enq%’;

The parameter of the enqueue wait event   has following meaning

P1: resource type and mode wanted

P2:ID1 of the resource

P3: ID2 of the resource

Nous pouvons utiliser la requête ci-dessous pour obtenir toute la file d'attente dans le système

Select event,p1, p2,p3 from v$session_wait  where wait_time=0 and event like 'enq%';
  1. V$lock est une autre vue utile pour vérifier les mises en file d'attente
  2. V$lock répertorie toutes les structures de verrouillage actuellement détenues dans le système
  3. Le type de colonne, id1 et id2 représentent le type de ressource , id1 et id2 de la structure de ressource. Il peut donc être joint à V$resource qui contient la liste de toute la structure de ressource
  • LMODE et la requête nous indiquent quelle file d'attente (propriétaire, convertisseur, serveurs) est la session
LMODE Demande Nom de la file d'attente
> 0 =0 Propriétaire
=0 > 0 Serveur
> 0    >  0 Convertisseur

La requête ci-dessous peut être utilisée pour trouver le titulaire et le serveur

SELECT inst_id,DECODE(request,0,'Holder: ','Waiter: ')||sid sess,
id1, id2, lmode, request, type
FROM V$LOCK
WHERE (id1, id2, type) IN
(SELECT id1, id2, type FROM V$LOCK WHERE request>0)
ORDER BY id1, request
;

En cas de RAC, la requête ci-dessous peut être utilisée pour trouver les bloqueurs et les serveurs

SELECT inst_id,DECODE(request,0,'Holder: ','Waiter: ')||sid sess,
id1, id2, lmode, request, type
FROM GV$LOCK
WHERE (id1, id2, type) IN
(SELECT id1, id2, type FROM gV$LOCK WHERE request>0)
ORDER BY id1, request
;

V$locked_object

c'est une autre vue utile pour les verrous de table Oracle

Il contient tous les verrous TM de la base de données. Il donne l'emplacement de transaction, le processus du système d'exploitation et l'identifiant de session de la session qui détient les verrous TM

Il existe plusieurs vues qui peuvent être utilisées pour trouver les informations sur les serrures. Ces vues sont créées par catblock.sql

DBA_LOCKS Afficher tous les verrous comme v$lock
DBA_DML_LOCKS Affiche tous les verrous DML™ détenus ou demandés
DBA_DDL_LOCKS Affiche tous les verrous DDL détenus ou demandés
DBA_WAITERS Affiche toutes les sessions en attente, mais pas en attente de verrous
DBA_BLOCKERS Affiche les sessions sans attente contenant des verrous en attente

Requête pour connaître les sessions en attente et les sessions en attente dans Oracle  

set linesize 1000
column waiting_session heading 'WAITING|SESSION'
column holding_session heading 'HOLDING|SESSION'
column lock_type format a15
column mode_held format a15
column mode_requested format a15
select
waiting_session,
holding_session,
lock_type,
mode_held,
mode_requested,
lock_id1,
lock_id2
from
dba_waiters
/

Requête pour connaître tous les objets verrouillés 

set term on;
set lines 130;
column sid_ser format a12 heading 'session,|serial#';
column username format a12 heading 'os user/|db user';
column process format a9 heading 'os|process';
column spid format a7 heading 'trace|number';
column owner_object format a35 heading 'owner.object';
column locked_mode format a13 heading 'locked|mode';
column status format a8 heading 'status';
select
substr(to_char(l.session_id)||','||to_char(s.serial#),1,12) sid_ser,
substr(l.os_user_name||'/'||l.oracle_username,1,12) username,
l.process,
p.spid,
substr(o.owner||'.'||o.object_name,1,35) owner_object,
decode(l.locked_mode,
1,'No Lock',
2,'Row Share',
3,'Row Exclusive',
4,'Share',
5,'Share Row Excl',
6,'Exclusive',null) locked_mode,
substr(s.status,1,8) status
from
v$locked_object l,
all_objects     o,
v$session       s,
v$process       p
where
l.object_id = o.object_id
and l.session_id = s.sid
and s.paddr      = p.addr
and s.status != 'KILLED'
/

Comment les verrous DML sont gérés dans le serveur Oracle

Lorsqu'une mise à jour, des insertions, des suppressions ou une sélection pour la mise à jour est exécutée sur la table oracle, Oracle prend ces deux verrous

  • Verrouillage de table DML :pour garantir la cohérence de la définition d'objet pendant toute la durée de la transaction. Cela empêche toute opération DDL de se produire pendant qu'un DML est en cours.
  • Verrouillage de ligne DML :cela permet d'assurer la cohérence des données lors de l'exécution de la transaction. Nous pouvons reformuler comme Ceci obtient un verrou sur la ligne particulière touchée et toute autre transaction tentant de modifier la même ligne est bloquée, jusqu'à ce que celle qui la possède déjà se termine

Comment les verrous de table Oracle sont implémentés

Nous avons déjà expliqué l'infrastructure de Enqueue dans la section précédente. Verrous de table Oracle sont implémentés en tant que TM Enqueue

La structure de mise en file d'attente serait donc

TM- -0

Les modes sont

RS :partage de lignes

RX :ligne exclusive

S :partager

SRX :partage de ligne exclusif

X :exclusif

Chaque curseur maintient une liste de structure de verrouillage de table qui est construite lors de l'analyse de l'instruction. Lors de la première exécution, un appel de fonction est effectué pour verrouiller toutes les tables de la liste. Les verrous sont libérés lorsque la transaction est validée ou annulée.

La possibilité de restauration, en particulier de restauration à un point de sauvegarde, ajoute une autre dimension de complexité au verrouillage du dictionnaire. À savoir, si une transaction est annulée au-delà du point auquel un verrou a été mis à niveau, le verrou doit être rétrogradé en conséquence, dans le cadre de l'opération de restauration, afin de réduire le risque de blocages artificiels.

Les exigences de verrouillage de dictionnaire pour les transactions et, en particulier, la maintenance d'un historique des conversions de verrous, sont fournies par les verrous DML en conjonction avec la mise en file d'attente TM. Chaque transaction contenant un verrou DML contient également un verrou de mise en file d'attente TM. La fonctionnalité de verrouillage de base est fournie par la mise en file d'attente, et le verrou DML ajoute la maintenance de l'historique des conversions.

Le tableau fixe des structures de verrouillage DML est dimensionné par le paramètre DML_LOCKS. Sa liste libre est protégée par le verrou d'allocation de verrou dml et les emplacements actifs sont visibles dans V$LOCKED_OBJECT .

Pour définir les DML_LOCKs, vérifiez l'utilisation dans v$resource_limit. Nous pouvons le placer généreusement car il prend très moins de place

Comment désactiver les verrous de table ?

  • Les verrous DML et les verrous de mise en file d'attente de TM associés peuvent être désactivés, soit entièrement, soit uniquement pour certaines tables.
  • Pour désactiver entièrement ces verrous, le paramètre DML_LOCKS doit être défini sur zéro. Dans une base de données de serveur parallèle, il doit être défini sur zéro dans toutes les instances.
  • Pour désactiver ces verrous sur une table particulière, la clause DISABLE TABLE LOCKS de l'instruction ALTER TABLE doit être utilisée.
  • Si les verrous sont désactivés pour une table, les instructions DML peuvent toujours modifier les blocs de la table et les verrous au niveau des lignes sont toujours maintenus. Cependant, les verrous de table en mode sous-partagé normalement associés aux requêtes et les verrous de table en mode sous-exclusif normalement associés à DML ne sont pas pris. Au lieu de cela, les transactions sur la table sont protégées contre les DDL en conflit en interdisant simplement toutes les tentatives de verrouiller la table entière, et donc tous les DDL sur la table.
  • La désactivation des verrous de table peut améliorer les performances car la surcharge d'acquisition de verrous est réduite Ceci est particulièrement important dans le cas de RAC où cette surcharge est assez élevée.
  • La désactivation des verrous de table empêche également la création d'index de clé étrangère. Comme la clé étrangère doit être indexée afin d'éviter le verrouillage de la table enfant pendant que les lignes sont manipulées dans la table parent. Donc, si nous désactivons le verrouillage de table tous ensemble, les index ne sont pas nécessaires
  • Il est préférable d'utiliser alter table pour désactiver les verrous de table sur certaines tables, puis de définir la table dml_locks. Comme si dml_locks est défini sur zéro, nous devrons faire rebondir l'instance pour la définir à nouveau
  • En insertion de chargement direct, une session prendra la file d'attente TM en mode "X". Cela empêche tout autre DML d'avoir lieu pendant le chargement direct, en plus de bloquer tous les DDL

Comment les verrous de ligne DML sont mis en œuvre

Les verrous de ligne DML sont implémentés en combinant les deux éléments suivants

  1. Verrouillage au niveau de la ligne :il est implémenté en tant qu'octet de verrouillage dans chaque en-tête de ligne et ITL (liste des transactions intéressées) dans chaque bloc de données ou d'index. Ceux-ci ne sont mis en cache nulle part et comme ils sont stockés dans le bloc lui-même et non dans SGA qui est limité, ce mécanisme de verrouillage par oracle est massivement évolutif
  2. Verrous de transaction :ils sont implémentés en tant que TX Enqueue

L'octet de verrouillage pointe vers l'entrée ITL dans le bloc et toutes les entrées ITL de la transaction pointent vers la file d'attente TX qui détermine finalement si la transaction est validée ou annulée. Les serveurs attendront le verrouillage de la transaction

Exemple

  • Une transaction A souhaite mettre à jour les lignes 2 et 3 du bloc. Il allouera un ITL (liste des transactions intéressées). La transaction accède aux lignes 2 et 3 et voit l'octet de verrouillage. Si l'octet de verrouillage est zéro, il n'est pas verrouillé. La transaction mettra à jour la ligne 3 ,3
  • Maintenant, une transaction B démarre et souhaite mettre à jour les lignes 1. Il allouera un ITL (liste des transactions intéressées). La transaction accède à la ligne 1 et voit l'octet de verrouillage. Si l'octet de verrouillage est 0, il n'est pas verrouillé. La transaction mettra à jour la ligne 1
  • Maintenant, la transaction veut mettre à jour la ligne 2. Elle accédera à la ligne et la trouvera verrouillée car l'octet de verrouillage ne sera pas nul. Il va chercher dans l'ITL qui détient le verrou. Il effectuera un nettoyage ITL pour savoir si la transaction est active ou non. Dans ce cas, il trouvera la transaction A active. La transaction B doit donc attendre la transaction A pour être annulée ou validée. La transaction B attendra pour demander la file d'attente TX que la transaction A maintient en mode exclusif

Qu'est-ce que la liste des transactions intéressées (ITL) ?

Lorsqu'une session veut modifier un bloc, elle doit allouer un ITL dans le bloc. ITL est la structure de données dans l'en-tête de bloc qui contient de nombreux créneaux pris par la transaction. Il est défini par les paramètres INITRANS et MAXTRANS lors de la création de la table. Les nombres initiaux d'emplacements sont créés selon INITTRANS et ils augmentent dynamiquement jusqu'au maximum de MAXTRANS

Qu'est-ce qu'une transaction ?

Lorsqu'une session met à jour/supprime/insère , une transaction est lancée. Il est terminé lorsque la validation ou la restauration s'est produite. Une transaction est identifiée par l'identifiant de transaction (XID). La transaction identifie se compose de trois parties

  1. Annuler ou annuler le numéro de segment
  2. Numéro d'emplacement du tableau des transactions
  3. Séquence ou wrap non

XID=usn#.slot#.wrap#

Chaque bloc ITL contiendra le XID

Un nettoyage ITL signifie rechercher le XID dans l'ITL et rechercher les segments d'annulation en fonction de celui-ci et rechercher la table de transaction et le numéro d'encapsulation pour vérifier l'activité de la transaction.

Nous pouvons utiliser la commande ci-dessous pour vider n'importe quel segment d'annulation

Alter system dump undo header  ;

Chaque transaction active peut être vue dans le tableau v$transaction

select addr, xidusn, xidslot, xidsqn
from v$transaction;
ADDR         XIDUSN    XIDSLOT     XIDSQN
-------- ---------- ---------- ----------
3C485875         50         5      3000

L'identifiant de transaction (XID) peut également être obtenu dans la propre session en utilisant

select dbms_transaction.local_transaction_id from dual;

L'attente sur TX enq sera vue dans v$session_wait

P1 :Nom|mode

P2:rbs3|wrap#

P3 :emplacement n°

Pour résumer les verrous de ligne DML

Le premier DML d'une session où une transaction n'existe pas déjà créera implicitement une transaction.

  • Un numéro de segment d'annulation, un emplacement et un retour à la ligne seront attribués
  • La mise en file d'attente TX sera instanciée

Lorsqu'une ligne à modifier est identifiée, la session prendra une entrée dans l'ITL du bloc de données, l'affectera à la transaction

  • USN/SLOT/WRAP sera écrit dans l'emplacement ITL, en réservant cet emplacement pour la transaction en cours
  • Le verrouillage sera pris sur la ligne, en définissant l'octet de verrouillage dans le répertoire de ligne pour pointer vers l'emplacement ITL de la transaction en cours

La mise en file d'attente TM et TX peut être vue dans V$lock

  • Le type identifie TM ou TX
  • ID1 et ID2 peuvent contenir des informations supplémentaires, mais sont contextuelles en ce qui concerne le TYPE de mise en file d'attente
  • Pour la mise en file d'attente de TM, ID1 est l'OBJECT_ID de l'objet verrouillé, qui peut être référencé dans DBA_OBJECTS, et ID2 est toujours 0
  • Pour la mise en file d'attente TX, ID1 et ID2 contiennent le numéro de segment d'annulation, le numéro d'emplacement et le bouclage

Exemple détaillé pour expliquer le fonctionnement des verrous oracle

  • Créer la table factice
Create table from j as select * from dba_objects where rownum < 3;

Table created

 Create table from j1 as select * from dba_objects where rownum < 3;

Table created
  • Séance A
Select * from j for update;

Voyons ce qui est présent dans v$lock

SQL> select distinct sid from v$mystat;

 SID
----------
2125

SQL> select * from v$lock where sid=2125;
ADDR             KADDR                   SID TY        ID1        ID2      LMODE
---------------- ---------------- ---------- -- ---------- ---------- ----------
REQUEST      CTIME      BLOCK
---------- ---------- ----------
00000006B5D9D0D0 00000006B5D9D148       2125 TX    2883613   16425600          6

0         44          0
FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2125 TM   21488781          0          3

0         44          0

Nous voyons donc ici

Le verrou de table Oracle DML est créé

TX (verrou de transaction) est créé

  • Commençons la session B
SQL>Select * from j1 for update;

SQL > select distinct sid from v$mystat;

 SID
----------
2302
SQL> select * from v$lock where sid=2302;

ADDR             KADDR                   SID TY        ID1        ID2      LMODE
---------------- ---------------- ---------- -- ---------- ---------- ----------
REQUEST      CTIME      BLOCK
---------- ---------- ----------
00000006AF7FF910 00000006AF7FF988       2302 TX    2949148   16884039          6

0         10          0
FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2302 TM      33544          0          3

0         10          0

00000006DC289D60 00000006DC289DB8       2302 AE   15062272          0          4

0        106          0

Nous voyons donc ici

Le verrou de table DML est créé

TX (verrou de transaction) est créé

Essayons maintenant de faire

Select * from j for update;

Cela va se bloquer

  • Démarrons une autre session pour analyser le problème

Si vous voyez les détails de session sid =2032 dans V$lock

select * from v$lock where sid=2302;
ADDR             KADDR                   SID TY        ID1        ID2      LMODE
---------------- ---------------- ---------- -- ---------- ---------- ----------
REQUEST      CTIME      BLOCK
---------- ---------- ----------
FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2302 TM      33544          0          3
0         47          0

00000006DC289D60 00000006DC289DB8       2302 AE   15062272          0          4
0        143          0

00000006DC289808 00000006DC289860       2302 TX    2883613   16425600          0
         6          7          0

FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2302 TM   21488781          0          3
0          7          0

La ligne en gras est la demande 6 (verrou exclusif) sur certains enq TX

Nous pouvons maintenant utiliser la requête ci-dessous pour trouver la session de blocage

select l1.sid, ' IS BLOCKING ', l2.sid
from v$lock l1, v$lock l2
where l1.block =1 and l2.request > 0
and l1.id1=l2.id1
and l1.id2=l2.id2
SID 'ISBLOCKING'         SID
---------- ------------- ----------
2125  IS BLOCKING        2302

Nous pouvons maintenant valider ou annuler la session 2125 pour que la transaction B se poursuive. Nous pouvons également arrêter la session 2125 à l'aide de la commande ci-dessous pour libérer le verrou

Alter system kill session ‘2125,<serial>’;

Quelques informations supplémentaires supplémentaires

Les verrous TX dans v$lock n'indiquent pas aux informations de ligne où se trouve le conflit. Nous pouvons voir ces choses en utilisant les requêtes

La requête ci-dessous doit être exécutée à partir de la session en attente

SQL> select row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#

from v$session where sid=2302

ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#
------------- -------------- --------------- -------------
21488781            461           81063             0

 

select do.object_name,
row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#,
dbms_rowid.rowid_create ( 1, ROW_WAIT_OBJ#, ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, ROW_WAIT_ROW# )
from v$session s, dba_objects do
where sid=2302
and s.ROW_WAIT_OBJ# = do.OBJECT_ID ;  
OBJECT_NAME  ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW# DBMS_ROWID.ROWID_C
------------- -------------- --------------- ------------- ------------------

J
21488781            461           81063             0 ABR+SNAHNAAATynAAA

 

SQL> Select * from j where rowid=’ ABR+SNAHNAAATynAAA’;

Articles connexes

Fonctionnement du verrouillage Oracle
Comment trouver les détails de la session dans la base de données Oracle
Vérification de l'état de la base de données importante
Questions d'entretien avec Oracle Apps dba
Requêtes pour vérifier les verrous dans la base de données Oracle
Oracle dba questions d'entretien

Cours recommandés

Voici quelques-uns des cours recommandés que vous pouvez acheter si vous souhaitez aller plus loin

Vous trouverez ci-dessous les liens vers certains des cours


Oracle DBA 11g/12c – Administration de base de données pour Junior DBA :Ce cours est bon pour les personnes qui commencent en tant que DBA junior ou qui aspirent à devenir DBA Oracle. Cela fournira une bonne compréhension des tâches de sauvegarde et de restauration et d'administration générale
Base de données Oracle :Administration d'Oracle 12C R2 RAC :Ce cours couvre l'installation, l'administration d'Oracle RAC. Un bon cours pour Oracle DBA qui souhaite mettre à niveau ses compétences pour Oracle RAC
Oracle Data Guard :Administration de base de données pour Oracle 12C R2 :Ce cours couvre l'installation, l'administration d'Oracle Dataguard. Un bon cours pour Oracle DBA qui souhaite mettre à niveau ses compétences pour Oracle Dataguard