Comment dépanner ORA-02049 et verrouiller les problèmes en général avec Oracle
Je reçois occasionnellement ORA-02049 pour des transactions longues et/ou intensives. Il n’ya apparemment aucune tendance à cela, mais cela se produit sur un simple INSERT.
Je ne sais pas comment obtenir des informations ou Oracle, mais il doit y avoir un moyen? Un journal sur le verrouillage ou au moins un moyen de voir les verrous actuels?
Une solution possible consiste à augmenter le paramètre INIT.ORA pour distributed_lock_timeout à une valeur supérieure. Cela vous donnerait alors un temps plus long pour observer la table v$lock car les verrous dureraient plus longtemps.
Pour automatiser cela, vous pouvez soit:
Exécutez une tâche SQL toutes les 5 à 10 secondes qui enregistre les valeurs de
v$lockou la requête donnée par sandos ci-dessus dans une table, puis analysez-la pour déterminer la session à l'origine du verrouillage.Exécutez un rapport
STATSPACKouAWR. Les sessions verrouillées doivent apparaître avec un temps écoulé élevé et peuvent donc être identifiées.
v$session a 3 colonnes supplémentaires blocking_instance, blocking_session, blocking_session_status qui peuvent être ajoutées à la requête ci-dessus pour donner une image de ce qui est verrouillé.
Utilisez cette requête pour déterminer les verrous de blocage possibles:
SELECT se.username,
NULL,
se.sid,
DECODE( se.command,
0, 'No command',
1, 'CREATE TABLE',
2, 'INSERT',
3, 'SELECT',
4, 'CREATE CLUSTER',
5, 'ALTER CLUSTER',
6, 'UPDATE',
7, 'DELETE',
8, 'DROP CLUSTER',
9, 'CREATE INDEX',
10, 'DROP INDEX',
11, 'ALTER INDEX',
12, 'DROP TABLE',
13, 'CREATE SEQUENCE',
14, 'ALTER SEQUENCE',
15, 'ALTER TABLE',
16, 'DROP SEQUENCE',
17, 'GRANT',
18, 'REVOKE',
19, 'CREATE SYNONYM',
20, 'DROP SYNONYM',
21, 'CREATE VIEW',
22, 'DROP VIEW',
23, 'VALIDATE INDEX',
24, 'CREATE PROCEDURE',
25, 'ALTER PROCEDURE',
26, 'LOCK TABLE',
27, 'NO OPERATION',
28, 'RENAME',
29, 'COMMENT',
30, 'AUDIT',
31, 'NOAUDIT',
32, 'CREATE DATABASE LINK',
33, 'DROP DATABASE LINK',
34, 'CREATE DATABASE',
35, 'ALTER DATABASE',
36, 'CREATE ROLLBACK SEGMENT',
37, 'ALTER ROLLBACK SEGMENT',
38, 'DROP ROLLBACK SEGMENT',
39, 'CREATE TABLESPACE',
40, 'ALTER TABLESPACE',
41, 'DROP TABLESPACE',
42, 'ALTER SESSION',
43, 'ALTER USER',
44, 'COMMIT',
45, 'ROLLBACK',
46, 'SAVEPOINT',
47, 'PL/SQL EXECUTE',
48, 'SET TRANSACTION',
49, 'ALTER SYSTEM SWITCH LOG',
50, 'EXPLAIN',
51, 'CREATE USER',
52, 'CREATE ROLE',
53, 'DROP USER',
54, 'DROP ROLE',
55, 'SET ROLE',
56, 'CREATE SCHEMA',
57, 'CREATE CONTROL FILE',
58, 'ALTER TRACING',
59, 'CREATE TRIGGER',
60, 'ALTER TRIGGER',
61, 'DROP TRIGGER',
62, 'ANALYZE TABLE',
63, 'ANALYZE INDEX',
64, 'ANALYZE CLUSTER',
65, 'CREATE PROFILE',
67, 'DROP PROFILE',
68, 'ALTER PROFILE',
69, 'DROP PROCEDURE',
70, 'ALTER RESOURCE COST',
71, 'CREATE SNAPSHOT LOG',
72, 'ALTER SNAPSHOT LOG',
73, 'DROP SNAPSHOT LOG',
74, 'CREATE SNAPSHOT',
75, 'ALTER SNAPSHOT',
76, 'DROP SNAPSHOT',
79, 'ALTER ROLE',
85, 'TRUNCATE TABLE',
86, 'TRUNCATE CLUSTER',
88, 'ALTER VIEW',
91, 'CREATE FUNCTION',
92, 'ALTER FUNCTION',
93, 'DROP FUNCTION',
94, 'CREATE PACKAGE',
95, 'ALTER PACKAGE',
96, 'DROP PACKAGE',
97, 'CREATE PACKAGE BODY',
98, 'ALTER PACKAGE BODY',
99, 'DROP PACKAGE BODY',
TO_CHAR(se.command) ) command,
DECODE(lo.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',
'JQ', 'Job Queue',
lo.type) ltype,
DECODE( lo.lmode,
0, 'NONE', /* Mon Lock equivalent */
1, 'Null Mode', /* N */
2, 'Row-S (SS)', /* L */
3, 'Row-X (SX)', /* R */
4, 'Share (S)', /* S */
5, 'S/Row-X (SSX)', /* C */
6, 'Excl (X)', /* X */
lo.lmode) lmode,
DECODE( lo.request,
0, 'NONE', /* Mon Lock equivalent */
1, 'Null', /* N */
2, 'Row-S (SS)', /* L */
3, 'Row-X (SX)', /* R */
4, 'Share (S)', /* S */
5, 'S/Row-X (SSX)', /* C */
6, 'Excl (X)', /* X */
TO_CHAR(lo.request)) request,
lo.ctime ctime,
DECODE(lo.block,
0, 'No Block',
1, 'Blocking',
2, 'Global',
TO_CHAR(lo.block)) blkothr,
'SYS' owner,
ro.name image
FROM v$lock lo,
v$session se,
v$transaction tr,
v$rollname ro
WHERE se.sid = lo.sid
AND se.taddr = tr.addr(+)
AND tr.xidusn = ro.usn(+)
ORDER BY sid
Essayez d'augmenter la valeur SHARED_POOL_SIZE dans init.ora.
Si cela échoue, essayez ALTER SYSTEM FLUSH SHARED_POOL
Voir aussi ceci .
Pourrait-il s'agir d'un index bitmap à l'origine de l'erreur décrite ici ?
Ok, c'était un problème idiot.
Nous utilisons Entity Framework 6.0 (mis à niveau vers la version 6.2, mais aucune modification), Oracle.ManagedDataAccess + EntityFramework 12.2.1100, .NET 4.5.
Je recevais ORA-02049: timeout: distributed transaction waiting for lock avec la requête suivante:
update "schemaname"."tablename"
set "DUE_DATE" = :p0
where ("ID" = :p1)
(via un événement EF context.Database.Log). Une requête très simple, ne devrait pas avoir de problèmes.
J'utilisais le même identifiant sur le serveur distant, sur mon débogueur local et dans Oracle SQL Developer. Un collègue a souligné que je devrais tuer toutes ces connexions multiples pendant le débogage… et cela a fonctionné. La solution dans mon cas était donc de ne pas vous connecter à la base de données plusieurs fois avec le même identifiant.