记一次 oracle 12.2 RAC : Transaction recovery: lock conflict caught and ignored

节点一 alert日志：

PDB(17):Transaction recovery: lock conflict caught and ignored

PDB(17):Transaction recovery: lock conflict caught and ignored

PDB(17):Transaction recovery: lock conflict caught and ignored

...

 

节点二： alert日志

PDB(17):minact-scn: useg scan erroring out with error e:12751

PDB(17):minact-scn: useg scan erroring out with error e:12751

PDB(17):minact-scn: useg scan erroring out with error e:12751

...

起因：

分区表 表级nologging，分批四千万数据并行插入，全表共6亿多数据，导致死锁，查询

select 'alter system kill session '||chr(39)||t2.sid||','||t2.serial#||chr(39)||';'
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;

alter system kill session '4843,29019';

...

全部是同一个会话，竟有3000多条记录，

后采用杀会话的方式没能释放，又用kill -9 杀掉进程。随后，alert日志出现以上告警。

 

然后各种查资料...网上有说要dump数据快，技术有限，还好是压力测试用的，等着慢慢恢复，停止此表数据的插入。

 1.查看恢复时使用的回滚段

select b.name useg, b.inst# instid, b.status$ status, a.ktuxeusn
xid_usn, a.ktuxeslt xid_slot, a.ktuxesqn xid_seq, a.ktuxesiz undoblocks,
a.ktuxesta txstatus
from x$ktuxe a, undo$ b
where a.ktuxecfl like '%DEAD%'
and a.ktuxeusn = b.us#;


USEG                   INSTID     STATUS    XID_USN   XID_SLOT    XID_SEQ UNDOBLOCKS TXSTATUS
------------------------------ ---------- ---------- ---------- ---------- ---------- ---------- ----------------
_SYSSMU30_2947991045$            1       3         30     10    50494     3572115 ACTIVE

2.查看恢复进度

select ktuxeusn USN, ktuxeslt Slot, ktuxesqn Seq, ktuxesta State, ktuxesiz Undo from x$ktuxe
   where ktuxesta <> 'INACTIVE'
   and ktuxecfl like '%DEAD%'
   order by ktuxesiz asc;

       USN     SLOT         SEQ STATE            UNDO
---------- ---------- ---------- ---------------- ----------
    30       10       50494 ACTIVE          2815649

等着慢慢恢复，一分钟约一万block的速度，6个小时3572115blocks。第二天观察UNDO恢复正常了，告警也随之消失。

转载于:https://www.cnblogs.com/oracle-ziyuhou/p/10241272.html