前言:
近期处理了一起用户使用在线重定义dbms_redefinition增量同步操作引发TX行锁的问题，用户在使用dbms_redefinition.sync_interim_table进行数据增量同步时，在线重定义的原表SQL语句出现了TX行锁等待问题
后面经过分析，发现产生TX行锁问题的原因为在线重定义在完成增量同步之后，会对增量MLOG$_XXX日志进行删除，删除期间为锁定维护MLOG$的原表数据，同时由于原表进行的dml操作会记录到MLOG$_XXX增量日志，也需要维护MLOG$的原表数据，导致操作了MLOG$的同一行数据，出现TX行锁等待问题。
问题:
在Oracle11.2.0.4版本，执行dbms_redefinition.sync_interim_table进行数据增量同步时，产生TX行锁问题
BEGIN
dbms_redefinition.sync_interim_table(
uname => 'TEST',
orig_table => 'TEST_OLD',
int_table => 'TEST_NEW');
END;
/
原因:
产生TX行锁问题的原因为dbms_redefinition.sync_interim_table在线重定义在完成增量同步之后，会对增量MLOG$_TEST_OLD物化视图日志进行删除，删除期间为锁定维护MLOG$的原表数据，同时由于源表进行的dml操作会记录到MLOG$_TEST_OLD物化视图日志，也需要维护MLOG$的原表数据，导致多个会话操作了MLOG$的同一行数据，出现TX行锁等待问题
问题分析:
查询问题时间的TX锁堵塞情况,会话44被会话34所堵塞，堵塞的锁类型为TX行锁，级别为6，独占模式
会话的执行语句为begin p1;end; 存储过程里面的操作语句为insert into test.test_old values
set linesize 400
set pagesize 400
col sample_time for 40
col sql_text for a60
col event for a40
col program for a30
col sql_text for a20
col CURRENT_OBJECT for a20
col object_type for a15
SELECT
TO_CHAR(D.SAMPLE_TIME, 'YYYYMMDD HH24:MI:SS') SAMPLE_TIME,
D.SESSION_ID,
D.program,
D.current_row#,D.EVENT,
CHR(BITAND(P1, -16777216) / 16777215) ||
CHR(BITAND(P1, 16711680) / 65535) "Lock",
BITAND(P1, 65535) "Mode",
D.BLOCKING_SESSION,
b.sql_text
FROM DBA_HIST_ACTIVE_SESS_HISTORY D,dba_hist_sqltext b
WHERE D.SAMPLE_TIME between to_date('2022-11-12 21:30:00','yyyy-mm-dd hh24:mi:ss') and to_date('2022-11-12 22:30:00','yyyy-mm-dd hh24:mi:ss')
AND D.EVENT = 'enq: TX - row lock contention' and d.sql_id=b.sql_id(+)
order by D.BLOCKING_SESSION;查看会话34的执行语句为删除物化视图日志MLOG$_TEST_OLD：delete from "TEST"."MLOG$_TEST_OLD"
delete from "TEST"."MLOG$_TEST_OLD"
where rowid in ( select mas$.rowid from "TEST"."MLOG$_TEST_OLD" mas$, sys.snap_xcmt$ map$
where mas$.xid$$ map$.xid and map$.commit_scn <= :1 )被堵塞会话与堵塞会话涉及的两个表TEST_OLD与MLOG$_TEST_OLD，MLOG$_TEST_OLD为原表TEST_OLD的物化视图日志，TEST_OLD发生DML操作，会往MLOG$_TEST_OLD里面插入增量信息，但insert MLOG$_TEST_OLD与delete MLOG$_TEST_OLD应该是操作不同的行数据，存在行锁冲突的可能很小，发生行锁冲突的表应该是其他表，但由于数据库记录的信息有限，我们无法进一步去获取锁信息
我们需要重现当时的行锁问题，并记录当时的锁信息，才能进一步的确认原因，跟用户再次确认当时产生行锁的情况，确定当时只是执行在线重定义的增量同步dbms_redefinition.sync_interim_table之后就出现的TX行锁情况
在测试环境，我们对问题进行了重现，并使用10704对锁信息进行跟踪
--为了更好的追踪锁信息，我们对数据库开启了全局的10704跟踪，这样可以更快的跟踪锁和队列的使用情况
alter system set events '10704 trace name context forever, level 12';
alter system set events '10704 trace name context off';在会话A,我们执行了在线重定义的增量同步dbms_redefinition.sync_interim_table
BEGIN
dbms_redefinition.sync_interim_table(
uname => 'TEST',
orig_table => 'TEST_OLD',
int_table => 'TEST_NEW');
END;
/同时，在会话B，我们执行关于原表TEST_OLD的DML操作
exec p1;很快，在会话A的dbms_redefinition.sync_interim_table执行完成之后，我们观察到了会话B出现了TX锁等待，问题得到复现
接下来，分析10704跟踪的会话B的锁信息，可以看到在申请完表锁TM-0000028a-00000000-mode 3之后，申请行锁TX-00030016-000006da-mode 6出现了3分多钟的等待，从08:51:03到08:54:22申请才返回
继续分析会话A的锁信息，可以看到会话A在08:50:39申请了表锁TM-0000028a-00000000-mode 3以及行锁TX-00030016-000006da-mode 6，之后就再也没有释放
会话A直到08:54:22才分别释放了行锁TX,30016,6da以及表锁TM,28a,0
到这里，我们可以确认行锁的堵塞信息为会话A长期持有表TM,28a,0的行锁TX,30016,6da，导致会话B出现了等待，而发生锁的对象object_id(16进制)为0000028a，我们可以查到对象为表SYS.MLOG$，MLOG$为数据库字典物化视图的信息维护表，记录每个物化视图日志的信息
SQL> set linesize 400
SQL> r
1 select owner,object_name,object_type
2 from dba_objects
3* where object_id =to_number('28a','xxx')
OWNER OBJECT_NAME OBJECT_TYPE
-------------------- ---------------------------------------- -------------------
SYS MLOG$ TABLE接下来，我们还要分析会话A和会话B分别执行了哪些操作语句产生了TX行锁问题，这一步我们会开启10046来跟踪两个会话的SQL执行情况
--为了更好的追踪锁信息，我们对数据库开启了全局的10046跟踪，这样可以更好的跟踪sql的执行情况
alter system set events '10046 trace name context forever, level 12';
alter system set events '10046 trace name context off';分析会话A的sql执行情况
在开始清理"TEST"."MLOG$_TEST_OLD"之前，会执行一个for update的查询锁定操作，锁定表MLOG$的master='TEST_OLD' and mowner='TEST'这行数据
select log, sysdate, youngest, youngest+1/86400, oldest, oldest_pk, oldest_oid, oldest_new, oldest_seq, oscn, oscn_pk, oscn_oid, oscn_new, oscn_seq, flag, purge_job
from sys.mlog$ where master = :2 and mowner = :1 for update
PARSE #140104910940200:c=0,e=29,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,plh=1551139906,tim=1668303489973102
BINDS #140104910940200:
Bind#0
oacdty=01 mxl=32(08) mxlc=00 mal=00 scl=00 pre=00
oacflg=18 fl2=0001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f6cb7729328 bln=32 avl=08 flg=05
value="TEST_OLD"
Bind#1
oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00
oacflg=18 fl2=0001 frm=01 csi=852 siz=32 off=0
kxsbbbfp=7f6cb7729360 bln=32 avl=04 flg=05
value="TEST"
之后开始清理"TEST"."MLOG$_TEST_OLD"表数据
delete from "TEST"."MLOG$_TEST_OLD" where rowid in ( select mas$.rowid
from "TEST"."MLOG$_TEST_OLD" mas$, sys.snap_xcmt$ map$
where mas$.xid$$ = map$.xid and map$.commit_scn <= :1 )
清理完之后，再更新表MLOG$的master='TEST_OLD' and mowner='TEST'这行数据
update sys.mlog$
set oscn = :1, oscn_pk = :2, oscn_oid = :3, oscn_new = :4, oscn_seq = :5, last_purge_date = sysdate, last_purge_status = 0, rows_purged = :8, purge_job = :9
where master = :6 and mowner = :7
分析会话B的sql执行情况
执行对表TEST.TEST_OLD的插入
INSERT INTO TEST.TEST_OLD VALUES(TEST_SEQ.NEXTVAL,:B1 +1,'aaaaaaaaa','bbbbbbbbbbbbbbbb','cccccccccccccc')
将TEST_OLD的增量数据插入物化视图日志"TEST"."MLOG$_TEST_OLD"
INSERT /*+ IDX(0) */ INTO "TEST"."MLOG$_TEST_OLD" (dmltype$$,old_new$$,change_vector$$,xid$$,"ID") VALUES (:d,:o,:c,:x,:1)
更新表MLOG$的master='TEST_OLD' and mowner='TEST'这行数据
update sys.mlog$
set flag=flag+131072
where mowner=:1 and master=:2 and bitand(flag,131072)=0
结合锁信息以及执行的SQL绘制出当时行锁的堵塞情况
T1时刻，会话A执行了对于表MLOG$的for update操作，并一直持有TM,28a,0,TX,30016,6da锁
T2时刻，会话A开始执行删除MLOG$_TEST_OLD的操作delete MLOG$_TEST_OLD,会话B开始执行表TEST_OLD,MLOG$_TEST_OLD的插入操作
T3时刻，会话A继续执行删除MLOG$_TEST_OLD的操作，会话B在执行完表TEST_OLD,MLOG$_TEST_OLD的插入之后，需要更新MLOG$的信息，申请TM,28a,0,TX,30016,6da锁，由于会话A持有，会话B进入等待
T4时刻，会话A执行完成删除MLOG$_TEST_OLD的操作，更新MLOG$的信息，会话B继续等待TM,28a,0,TX,30016,6da锁
T5时刻，会话A释放TM,28a,0,TX,30016,6da锁，会话B获得TM,28a,0,TX,30016,6da锁
问题总结:
综上，执行在线重定义dbms_redefinition.sync_interim_table同步增量数据时，产生TX行锁问题的原因为dbms_redefinition.sync_interim_table在线重定义在完成增量同步之后，会对增量MLOG$_TEST_OLD物化视图日志进行删除，删除期间为锁定维护MLOG$的原表数据，同时由于源表进行的dml操作会记录到MLOG$_TEST_OLD物化视图日志，也需要维护MLOG$的原表数据，导致多个会话操作了MLOG$的同一行数据，出现TX行锁等待问题
问题建议:
1 TX锁的时间主要取决于清理MLOG$_XXXX物化视图日志的时长，所以要控制每次增量的数据，减少TX锁的锁定时间
2 在原表DML操作较为空闲的时间段进行增量数据的同步，并监控TX锁的情况，一旦发现大面积的TX锁堵塞，可以kill了清理MLOG$_XXXX物化视图日志的操作