長時間実行されるトランザクションや集中的なトランザクションで、ORA-02049が発生することがあります。これにはパターンはないようですが、単純なINSERTで発生します。
私はどのような情報やOracleを取得するのかわかりませんが、方法がなければなりませんか?ロックのログまたは少なくとも現在のロックを確認する方法は?
考えられる1つの方法は、INIT.ORA
のdistributed_lock_timeout
パラメータをより大きな値に増やすことです。これにより、ロックが長く続くため、v$lock
テーブルを監視する時間が長くなります。
これを自動化するには、次のいずれかを実行できます
v$lock
の値またはサンドスが上記で指定したクエリをテーブルに記録するSQLジョブを5〜10秒ごとに実行し、それを分析して、ロックを引き起こしているセッションを確認します。
STATSPACK
またはAWR
レポートを実行します。ロックされたセッションは、長い経過時間で表示されるため、識別できます。
v$session
にはさらに3つの列blocking_instance, blocking_session, blocking_session_status
があり、上記のクエリに追加して、何がロックされているかを示すことができます。
このクエリを使用して、可能なブロッキングロックを判断します。
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
Init.oraのSHARED_POOL_SIZE値を増やしてみてください。
それが失敗した場合は、ALTER SYSTEM FLUSH SHARED_POOL
this も参照してください。
説明されているようにエラーを引き起こすビットマップインデックスである可能性があります here ?
わかりました、これはばかげた問題でした。
Entity Framework 6.0(6.2にアップグレード、変更なし)、Oracle.ManagedDataAccess + EntityFramework 12.2.1100、.NET 4.5を使用しています。
ORA-02049: timeout: distributed transaction waiting for lock
次のクエリを使用:
update "schemaname"."tablename"
set "DUE_DATE" = :p0
where ("ID" = :p1)
(EF context.Database.Logイベントを介して)。本当に単純なクエリで、問題はないはずです。
まあ、私はリモートサーバー、ローカルデバッガー、およびOracle SQL Developerで同じログインを使用していました。同僚は、デバッグ中にこれらすべての複数の接続を強制終了する必要があると指摘しました....そしてそれはうまくいきました。したがって、私の場合の解決策は、同じログインでデータベースに複数回接続することではありませんでした。