应该是锁冲突 还没有到死锁的那一步 如果有死锁会记录的
查一下 这个配置项 show parameters like ‘enable_sql_audit’;
那可能诊断信息 被刷掉了 后面再有锁冲突的问题 可以先通过下面的语句查询一下
select * from __all_virtual_processlist where retry_info like ‘%-6005%’ and total_time > 100 order by total_time limit 10\G;
如果下面的死锁没有记录 就说明不是死锁 只有锁冲突 因该是表锁造成的 锁冲突
select * from oceanbase.DBA_OB_DEADLOCK_EVENT_HISTORY;
业务前台反馈说,写不进去, 除了手工lock table,什么时候会上表锁呢? 这种info级别锁信息,也能说明前台业务出现了问题吗
你可以看看 这个文档 排查锁冲突 有可能是表锁（offline Alter table, Drop table, Drop Index, Truncate table） 也有可能不是表锁
https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000664387?back=kb
但从日志看,说明不了什么问题吗
从日志分析 来看确实是行锁造成的 日志信息 有这个
tx_id={txid:31338198604}, conflict_tx_id={txid:31338197922}
tx_id={txid:31338198758}, conflict_tx_id={txid:31338197922}
tx_id={txid:31338198768}, conflict_tx_id={txid:31338197922}
conflict_tx_id 展示的是持有行锁，一直提交不成功的 tx_id。
6005不是死锁吗?观测行锁通过什么什么代码
下面这两个语句可以查看锁冲突
select * from __all_virtual_processlist where retry_info like ‘%-6005%’ and total_time > 100 order by total_time limit 10\G;
SELECT * FROM oceanbase.GV$OB_PROCESSLIST WHERE STATE = ‘ACTIVE’ AND ID IN
(SELECT SESSION_ID FROM oceanbase.GV$OB_TRANSACTION_PARTICIPANTS WHERE TX_ID IN
(SELECT TRANS_ID FROM oceanbase.GV$OB_LOCKS WHERE BLOCK = 1));
这个可以查看死锁
select * from oceanbase.DBA_OB_DEADLOCK_EVENT_HISTORY;
查看表加锁的方式
select
/*+QUERY_TIMEOUT(3600000000) read_consistency(weak) */
b.TRANS_ID,
case
WHEN b.TYPE = ‘TM’ THEN ‘表锁’
WHEN b.TYPE = ‘TX’ THEN ‘事务锁’
WHEN b.TYPE = ‘TR’ THEN ‘行锁’
ELSE NULL
END
AS lock_type,
ID1,
LMODE,
CASE
WHEN BLOCK = 0 THEN ‘该事务持有锁’
WHEN BLOCK = 1 THEN ‘该事务被阻塞’
ELSE NULL
END
as BLOCK,
a.SVR_IP,
ID,
user,
command,
time,
total_time,
STATE,
info,
retry_cnt,
retry_info,
thread_id,
trace_id
from
gv$ob_processlist a,
GV$OB_LOCKS b,
oceanbase.CDB_ob_table_locations c
where
a.trans_id = b.trans_id
and c.table_name = ‘表名称’
and (
ID1 like concat(’%’ , c.table_id, ‘%’)
OR ID1 like concat(’%’ , c.tablet_id ,’%’)
);
好的,我先看看