概述
最近因业务需要,需删除某张大表1600万数据,然后开了并行(开并行会锁表)删除,但在业务需要作业时却还没删除完,只能临时选择回滚,导致后面一段时间段系统频繁出现卡顿现象。
下面记录下分析过程。
1、查看告警日志
从告警日志可以发现Transaction recovery: lock conflict caught and ignored,这个问题实际上之前也分享过,只不过侧重的是怎么找出相关的对象,需要dump跟踪文件来进行分析,对于实际的意义可能不是很大,下面分享下另外两个sql,起码心里有底。
2、查看恢复时使用的回滚段
select b.name useg, b.inst# instid, b.status$ status, a.ktuxeusnxid_usn, a.ktuxeslt xid_slot, a.ktuxesqn xid_seq, a.ktuxesiz undoblocks,a.ktuxesta txstatusfrom x$ktuxe a, undo$ bwhere a.ktuxecfl like '%DEAD%'and a.ktuxeusn = b.us#;
这里可以看到总的UNDO块和undo对象。
3、查看恢复进度
对于我们更关心的是什么时候才回滚完,可以查询以下sql.
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;
这里只能选择等着慢慢恢复,看机器性能,我这边是1分钟1600多block,3个小时就差不多UNDO恢复正常了,告警也随之消失。
通过上面的案例,当大家碰到大事务回滚这种问题时,就可以知道怎么去看当前数据库回滚的情况了。更重要的是明白:不要随随便便回滚...
觉得有用的朋友多帮忙转发哦!后面会分享更多devops和DBA方面的内容,感兴趣的朋友可以关注下~