【干货攻略】查询语句卡顿问题分析

达梦E学 2025-01-24

184

引言

查询一张表一直返回不了结果，会话被卡住？这个现象到底是什么原因引起，这里为大家揭开谜底。

在某项目上遇到这个问题：查询一张表的 sql 语句一直卡住，无法返回结果，这张表的表结构也无法查看，同时所有涉及到这张表的会话全部卡住。可以说，关于这张表的所有操作都陷入了瘫痪的境地。而这张表是一张非常重要的表，很多业务都需要访问这张表，造成了很多业务都卡在这个地方。

本章内容已在如下环境上测试：

①数据库版本：达梦DM8。

相关关键字：统计信息。

——正文——

问题排查

1.在ip地址末尾为29的数据库上面执行

select * from"XXX_V30"."XXX_FWFP";

查询出不了结果：

2.针对这种情况，判断可能存在阻塞，于是立即用查询阻塞的 sql 语句进行排查：

SELECT
VTW.ID AS TRX_ID,
VS.SESS_ID,
VS.SQL_TEXT,
VS.APPNAME,
VS.CLNT_IP
FROM
V$TRXWAIT VTW
LEFT JOIN V$TRX VT ON (VTW.ID = VT.ID)
LEFT JOIN V$SESSIONS VS ON (VT.SESS_ID = VS.SESS_ID);

发现系统存在阻塞情况，这里忘记了截图，于是顺着阻塞会话往下分析。

3.查询当前与该表相关联的会话，从会话中可以看到：有个会话正在给这张表添加列：

/***Manager***//***Manager***/alter table "XXX_V30"."XXX_FWFP" add column("YLS_XH"INTEGER);

添加列的操作是会阻塞查询，可以解释第1步的现象，那么又是什么操作阻塞了添加列的操作呢？继续排查。

4.通过以下命令打印当前会话线程（添加字段的会话线程，线程号3922425来源于 v$sessions 的 THRD_ID 字段）的堆栈。

pstack 3922425 > home/dmdba/dmdbms/log/pstack3922425.log

堆栈信息如下：

从堆栈的信息可以知道：

第一，从“dpi_link_get_tv”字样分析可能卡在 dblink 阶段。

第二，该问题的发生和 XXX_XX_XXX_DICOM 对象有关。

从 XXX_XX_XXX_DICOM 分析：

XXX_XX_XXX_DICOM 是一个视图，而里面确实包含了主角对象"XXX_V30"."XXX_FWFP"的访问。这就说明了这个视图的访问也卡在无法访问""XXX_V30"."XXX_FWFP"这个地方，和堆栈里面所看到的信息是契合的。

5.会话分析

（1）对当前数据库会话进行分析：

select SQL_TEXT,
STATE,
CLNT_IP,
CLNT_HOST,
CLNT_TYPE,
APPNAME,
MSG_STATUS
from gv$sessions
where STATE = 'ACTIVE'
and SQL_TEXT is null;

可以看出这里存在SQL_TEXT为NULL的5个活动会话，这些会话来源于另外一台ip地址末尾为36的数据库服务器，既然前面的排查分析结果可能和dblink有关。经过这里的分析，dblink发起会话的服务器极大可能来源于 36。

（2）对36的数据库会话进行分析36上面会话情况：

select SQL_TEXT, 
STATE, 
CLNT_IP, 
CLNT_HOST, 
CLNT_TYPE, 
APPNAME, 
MSG_STATUS 
from gv$sessions 
where STATE = 'ACTIVE' and SQL_TEXT like '%V30_XXX%';