达梦用简单的SQL查找阻塞语句

模拟阻塞的产生

创建个表

CREATE TABLE "SYSDBA"."test"("c1" CHAR(10));

另外打开四个窗口，每个分别执行，都不要提交

窗口1：

update "test" set "c1"=1; --会话1

为了模拟生产的混合会话，窗口一再执行

select * from "SYSDBA"."test";

 

窗口2

update "test" set "c1"=4; --会话2

窗口3

update "test" set "c1"=6; --会话3

窗口4：

select * from v$trxwait;

会看到会话174747被174728阻塞了，174748又被174747阻塞了，就是会话1阻塞了会话2，会话2阻塞了会话3

 

执行

select sf_get_session_sql(sess_id),* from gv$sessions where trx_id=174728; 
select sf_get_session_sql(sess_id),* from gv$sessions where trx_id=174747;

174728是这个select * from "SYSDBA"."test";

174747是update "test" set "c1"=4;

 

因为会话一是混合事务，所以看到的是被select阻塞了，实际是被update "test" set "c1"=1; 阻塞了

查找发现174728发现是混合事务

select * from v$lock where trx_id=174728;

如果需要更详细的SQL，需要查询V$SQL_HISTORY ，v$sessions 视图查询，可以看到是前面一个update没提交导致了阻塞，

--查询混合事务包含的SQL

select listagg2(top_sql_text||char(10))

 from  V$SQL_HISTORY sh,v$sessions block_sess

 where sh.TRX_ID=block_sess.trx_id and sh.sess_id=block_sess.sess_id

 and sh.TRX_ID=174728;

看到是被混合事务中的update "test" set "c1"=1;阻塞了

 

注意：由于V$SQL_HISTORY只能保留10000条历史记录， 如存在长时间未提交事务或者系统业务负载高，可能查不到结果或者结果不全

 

也可以从慢SQL抓取的日志中获取

cat dmsql_DMSERVER_20230110_145721.log | grep “trxid:69667”

 

 处理方案：

杀掉导致阻塞的会话就可以了

select * from v$sessions where SQL_TEXT like '%test%' AND STATE='IDLE';

 sp_close_session(158834760);

如果不知道杀哪个，把IDLE的会话杀完也可以

begin
for rec in
(
select * from v$sessions where STATE='IDLE'
)
loop
sp_close_session(rec.sess_id);
end loop;
end;

 

最后发现窗口2也执行成功了

窗口3还在执行中，被窗口2的会话阻塞了

 

 

达梦DML语句是默认不提交的，需要自己手动提交

如果需要自动提交，需要设置下