Transaction recovery: lock conflict caught and ignored

1 数据库alert日志频繁告警，每分钟报一次。根据告警信息，认为是事务在进行回滚导致的锁冲突。Transaction recovery: lock conflict caught and ignoredTransaction recovery: lock conflict caught and ignoredTransaction recovery: lock conflict caught and ignoredTransaction recovery: lock conflict caught and ignored 2   查看恢复使用的回滚段 SYS@XXDB3 >select  b.name,b.inst#,b.status$,a.ktuxeusn,a.ktuxeslt,a.ktuxesqn,a.ktuxesiz,a.ktuxesta  from x$ktuxe a, undo$ b   where a.ktuxecfl like '%DEAD%' and a.ktuxeusn = b.us#; NAME                                INST#    STATUS$   KTUXEUSN   KTUXESLT   KTUXESQN   KTUXESIZ KTUXESTA ------------------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------------- _SYSSMU60_3444085615$                   2          2         60         15    6684846          0 INACTIVE _SYSSMU606_4051243031$                  2          2        606         13     139201          0 INACTIVE _SYSSMU883_22107100$                    3          3        883          9   13962437    2731264 ACTIVE 根据如上信息，将事务信息进程转换。 活动的会话 _SYSSMU883_22107100$  将 883          9   13962437 转换为  十六进制  373.9.D50CC5 3   查看死的事务及其恢复进度，还有270万数据块还没有回滚完成。 SYS@XXDB3 >select ktuxeusn,ktuxeslt,ktuxesqn,ktuxesta,ktuxesiz from x$ktuxe where ktuxesta <> 'INACTIVE'  and ktuxecfl like '%DEAD%' order by ktuxesiz ;   KTUXEUSN   KTUXESLT   KTUXESQN KTUXESTA           KTUXESIZ ---------- ---------- ---------- ---------------- ----------        883          9   13962437 ACTIVE              2728325 4  通过v$fast_start_transactions视图查看事务恢复信息,及进度信息 SYS@XXDB3 >select t.USN,t.SLT,t.SEQ,t.STATE,t.UNDOBLOCKSDONE,t.UNDOBLOCKSTOTAL,t.PID,t.CPUTIME,t.XID   from v$fast_start_transactions t;        USN        SLT        SEQ STATE            UNDOBLOCKSDONE UNDOBLOCKSTOTAL        PID    CPUTIME XID ---------- ---------- ---------- ---------------- -------------- --------------- ---------- ---------- ----------------          1          1   28197245 RECOVERED                 18582           18582                 30429 010001007D41AE01         79          0   18624142 RECOVERED               2131645         2131645                115595 4F0000008E2E1C01        883          9   13962437 RECOVERING               269974         2775242                 23418 73030900C50CD500         26          7    9559527 RECOVERED                   570             570                     1 1A000700E7DD9100         38          4    5652761 RECOVERING                85313           86927              26852095 2600040019415600         95          8   10571398 RECOVERED                   175             175                     1 5F000800864EA100 6 rows selected.   或通过如下语句进行查找 SYS@XXDB3 >select t.USN,t.SLT,t.SEQ,t.STATE,t.UNDOBLOCKSDONE,t.UNDOBLOCKSTOTAL,t.PID,t.CPUTIME,t.XID   from v$fast_start_transactions t   2  where t.USN=883 and t.SLT=9;        USN        SLT        SEQ STATE            UNDOBLOCKSDONE UNDOBLOCKSTOTAL        PID    CPUTIME XID ---------- ---------- ---------- ---------------- -------------- --------------- ---------- ---------- ----------------        883          9   13962437 RECOVERING               270889         2775242                 23526 73030900C50CD500 5  通过dump undo header 寻找事务使用的undo segment  执行的SQL语句 alter system dump undo header '_SYSSMU883_22107100$';     生成的文件 -rw-r----- 1 oracle asmadmin       124 Nov 18 14:15 XXDB3_ora_159663.trm -rw-r----- 1 oracle asmadmin     39321 Nov 18 14:15 XXDB3_ora_159663.trc 查看生成文件的内容，找到异常的数据块，state=10  意味活动事务，DBA为数据块的地址 查询对应dba号，并转换为十进制。  SYS@XXDB3 >select to_number('9e45f736','xxxxxxxxxxxxxxxxxx') from dual; TO_NUMBER('9E45F736','XXXXXXXXXXXXXXXXXX') ------------------------------------------                                 2655385398 6 根据DBA号， 查看数据文件的ID 及数据块                    SYS@XXDB3 >select dbms_utility.data_block_address_file(2655385398) from dual; DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(2655385398) ------------------------------------------------                                              633                SYS@XXDB3 >select dbms_utility.data_block_address_block(2655385398) from dual;  DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(2655385398) -------------------------------------------------                                            390966      7  dump对应的数据块，查看对象名alter system dump datafile     633  block   390966;     根据生成trace的如下信息，可以发现出问题的在索引上，对象为   seg/obj: 0x1944ff Block header dump:  0x9e45f736 Object id on Block? Y  seg/obj: 0x1944ff  csc: 0xe41.e7d3dd9a  itc: 2  flg: E  typ: 2 - INDEX     brn: 0  bdba: 0x9e45f680 ver: 0x01 opc: 0     inc: 0  exflg: 0  Itl           Xid                  Uba         Flag  Lck        Scn/Fsc0x01   0x0053.006.003c9137  0xc804028d.f4da.01  CBU-    0  scn 0x0e2e.7a50997c0x02   0x0053.01a.003c633b  0xc843541a.f4db.0f  C-U-    0  scn 0x0e41.e6e06a6eLeaf block dump===============header address 140709705595492=0x7ff98804ba64kdxcolev 0KDXCOLEV Flags = - - -kdxcolok 0kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Ykdxconco 2kdxcosdc 1kdxconro 137kdxcofbo 310=0x136kdxcofeo 3924=0xf54kdxcoavs 3614kdxlespl 0kdxlende 0kdxlenxt 2755946911=0xa444699fkdxleprv 2760175590=0xa484efe6kdxledsz 10kdxlebksz 8032 row#0[4403] flag: ------, lock: 0, len=30, data:(10):  00 19 44 d8 2e 24 6a f9 00 2fcol 0; len 7; (7):  78 76 0c 01 01 01 01col 1; len 9; (9):  c8 0b 01 01 01 01 1d 32 2crow#1[4433] flag: ------, lock: 0, len=30, data:(10):  00 19 44 d8 37 e0 09 e9 00 6bcol 0; len 7; (7):  78 76 0c 01 01 01 01col 1; len 9; (9):  c8 0b 01 01 01 01 1d 32 2drow#2[4463] flag: ------, lock: 0, len=30, data:(10):  00 19 44 d8 38 5f c1 70 00 55   将十六进制的对象ID转换为十进制的  SYS@XXDB3 >select to_number('1944ff','xxxxxxxxxxxxxxxxxx') from dual; TO_NUMBER('1944ff','XXXXXXXXXXXXXXXXXX') ------------------------------------------                                 1656063 根据对象ID，查看对象名  SYS@XXDB3 >select a.OWNER,a.OBJECT_NAME,a.OBJECT_TYPE from dba_objects a where a.OBJECT_ID='1656063'; OWNER                OBJECT_NAME                    OBJECT_TYPE -------------------- ------------------------------ ------------------------------ TESTUSER             PK_A_USER_STOP                INDEX 根据索引找表名: OWNER                INDEX_NAME           TABLE_OWNER          TABLE_NAME -------------------- -------------------- -------------------- -------------------- TESTUSER             PK_A_USER_STOP      TESTUSER             A_USER_STOP     SYS@XXDB3 >select OBJ#,DATAOBJ#,OWNER#,NAME,NAMESPACE,SUBNAME,TYPE# from obj$  where obj#=1656063;       OBJ#   DATAOBJ#     OWNER# NAME                            NAMESPACE SUBNAME                             TYPE# ---------- ---------- ---------- ------------------------------ ---------- ------------------------------ ----------    1656063    1656063         89 PK_A_USER_STOP                         4                                         1 8 经过4天的等待，数据库总算回滚完相关事务，数据库也没有相关告警信息  SYS@XXDB3 >select sysdate from dual; SYSDATE ------------------ 22-NOV-21 SYS@XXDB3 >select ktuxeusn,ktuxeslt,ktuxesqn,ktuxesta,ktuxesiz from x$ktuxe where ktuxesta <> 'INACTIVE' and ktuxecfl like '%DEAD%' order by ktuxesiz ; no rows selected    经过查看在21日 5:25以后，数据库再未报任何告警。 Sun Nov 21 05:25:46 2021 Transaction recovery: lock conflict caught and ignored Sun Nov 21 05:25:46 2021 Thread 3 advanced to log sequence 702806 (LGWR switch)   Current log# 27 seq# 702806 mem# 0: +DATA_P/XXDB3 /onlinelog/group_27.507.1074248035   Current log# 27 seq# 702806 mem# 1: +DATA_P/XXDB3 /onlinelog/group_27.508.1074248039     9  原因分析   咨询相关业务人员，相关人员在执行表分区，将执行了2天的工作强制终止，才是导致此次事件的根本原因。   故在长时间运行的工作，强制终止，数据库进行大量回滚操作，有可能会产生未知的报错，还需谨慎。 10  第二种解决方法，不推荐使用。 根据Instance Terminates With ORA-07445 [ktundo] Errors From SMON Process (Doc ID 2736978.1) 文档， 可以通过设置10513事件，禁用SMON回滚会话，并重建相关undo表空间来解决。但设置此事件， 将会导致数据库所有会话都不能 回滚，有可能会导致数据方面的问题，故如非特别情况，不建议使用。