長時間のトランザクションや集中的なトランザクションで、ORA-02049 が発生することがあります。これにはパターンがないように見えますが、単純な INSERT で発生します。
何らかの情報やオラクルを入手する方法がわかりませんが、方法が必要ですか? ロックに関するログ、または少なくとも現在のロックを確認する方法はありますか?
100435 次
5 に答える
13
考えられる 1 つの方法は、INIT.ORAパラメーターをdistributed_lock_timeoutより大きな値に増やすことです。v$lockこれにより、ロックが長く続くため、テーブルを観察する時間が長くなります。
これを自動化するには、次のいずれかを実行できます
5 ～ 10 秒ごとに SQL ジョブを実行して、
v$lock上でサンドスが指定した値またはクエリをテーブルに記録し、それを分析して、どのセッションがロックを引き起こしているかを確認します。STATSPACKまたはAWRレポートを実行します。ロックされたセッションは長い経過時間で表示されるため、識別できます。
v$sessionblocking_instance, blocking_session, blocking_session_status上記のクエリに追加できる3 つの列があり、何がロックされているかを把握できます。
于 2010-03-24T14:11:23.657 に答える
6
このクエリを使用して、考えられるブロッキングロックを特定します。
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
于 2010-03-24T09:36:19.010 に答える
3
init.ora の SHARED_POOL_SIZE 値を増やしてみてください。
それが失敗した場合は試してくださいALTER SYSTEM FLUSH SHARED_POOL
これも参照してください。
于 2010-03-24T09:25:45.367 に答える
1
here で説明されているように、エラーの原因となっているビットマップインデックスでしょうか?
于 2010-03-24T12:44:39.560 に答える
0
わかりました、これはばかげた問題でした。
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 で同じログインを使用していました。同僚は、デバッグ中にこれらの複数の接続をすべて強制終了する必要があると指摘しました....そしてそれはうまくいきました。したがって、私の場合の解決策は、同じログインでデータベースに複数回接続しないことでした。
于 2018-12-12T17:40:19.033 に答える