查看数据库是否有阻塞：
SELECT o.name, l.*
FROM v$lock l, sysobjects o
WHERE l.table_id = o.id AND blocked = 1;
trx_id值为29441，表示当前数据库中trx_id为29441的事务被其他会话阻塞。
查看当前数据库等待事务
SELECT * FROM V$TRXWAIT;
说明：
ID：被阻塞的事务ID
WAIT_FOR_ID：所等待的事务ID（即引起阻塞源的事务ID）
WAIT_TIME:当前等待时间
说明：表示事务ID为29441的事务被29440的事务所阻塞。
查看相关事务对应的session信息：
select SESS_ID,TRX_ID,USER_NAME,CREATE_TIME,SQL_TEXT from v$sessions where trx_id in (29441,29440);
但看到产生阻塞的事务ID（29440，对应的会话ID为140545288643688）的SQL_TEXT为select * from t where id=1;，这是一个查询语句，正常情况下查询语句是不会阻塞其他会话，同时也就了解到该SQL只是对应会话事务中执行的最后一条SQL，在该SQL之前应该执行了其它的DML操作。
查看一个事务中执行过的所有SQL：
select SQL_ID,SESS_ID,TRX_ID,TOP_SQL_TEXT,START_TIME from v$sql_history where trx_id=29440 order by START_TIME desc;
可以看到在会话（140545288643688）的事务（29440）中的所有执行SQL中，update t set name='az' where id=2;这个SQL语句才是引起阻塞（另一个会话29441）的源头。
确认会话（140545288643688）是否可以kill掉，如果确认可以kill的话，可以执行以下命令Kill掉相关的会话：
call sp_close_session(140545288643688)
把140545288643688 kill掉后，就可以解决阻塞的问题。
达梦数据库 - 新一代大型通用关系型数据库 | 达梦云适配中心
https://eco.dameng.com/
