DM8 目录结构与常用排查入口梳理

刚接触一个已经安装好的 DM8 环境时，不适合马上去做复杂操作。更稳妥的方式是先把三个问题弄清楚：

数据库软件装在哪里，各目录分别放什么。
数据库实例的数据文件、控制文件、日志文件、备份文件在哪里。
进入库以后，怎么查看对象、状态、空间和锁阻塞。

这篇文章以一个单机 DM8 环境为例，整理安装目录、物理结构、逻辑结构以及常用排查入口。重点不是把所有命令堆出来，而是形成一个判断顺序：先看目录和文件，再看实例状态，最后结合系统视图判断问题。

来源总览： 本文结合《DM8 系统管理员手册》中"物理存储结构""数据字典""动态性能视图"，以及《DM8 SQL 语言使用手册》《DM8 系统包使用手册》中系统过程、函数和 DBMS_METADATA 相关内容整理。文中的 Linux 服务状态、磁盘空间检查命令属于通用操作系统排查方法。

一、为什么先看目录和结构

数据库问题经常不是单点问题。比如连接不上库，可能是服务没起来，也可能是端口不对；表空间告警，可能是数据文件达到上限，也可能是文件系统已经没空间；会话卡住，可能是事务未提交，也可能是锁等待或客户端连接长期占用。

所以我把 DM8 的基础排查分成四层：

层次	关注点	作用
安装目录	`bin`、`drivers`、`tool`、`doc`、`log`、`script`	找工具、日志、驱动、服务脚本
数据目录	`dm.ini`、`dm.ctl`、`.DBF`、`.log`、归档和备份目录	找实例配置和物理文件
库内对象	用户、模式、表、索引、视图、过程、触发器	判断对象是否存在、属于谁、定义是什么
运行状态	库状态、参数、会话、锁、空间	判断故障排查方向

这样排查时不会一上来就改配置、重启服务或杀会话，而是先确认事实。

二、安装目录：先知道工具在哪里

来源： 本节目录作用基于 DM8 单机安装后的目录观察整理；dmserver、disql、dminit 等工具入口以实际安装目录为准。

DM 的安装目录常见于 /dmdbms、/opt/dmdbms 或安装时指定的位置。不能只靠记忆，现场可以先通过进程反推：

bash 复制代码

ps -ef | grep -i '[d]mserver'
readlink -f /proc/$(pgrep -n dmserver)/exe

第一条看 dmserver 是否存在，以及它使用的 dm.ini 路径；第二条通过进程可执行文件反推安装目录。

常见目录可以这样理解：

目录	内容	说明
`bin`	`dmserver`、`disql`、`dminit`	核心功能、实例启动入口
`drivers`	JDBC、ODBC、Python、Go、.NET 等驱动	应用侧建议使用与数据库版本、CPU 架构和语言环境匹配的驱动
`tool`	管理工具、迁移工具、监控工具、服务工具	图形工具、迁移和服务管理
`doc`	使用手册	确定参数、视图、函数含义
`log`	安装日志、服务日志、运行日志	启动、服务脚本、异常堆栈日志
`script`	服务注册、脚本模板	服务注册、启动脚本相关问题
`uninstall`	卸载入口	只记录位置，日常排查不应随便执行

服务状态一般从 systemd 看：

bash 复制代码

systemctl status DmServiceDMSERVER.service --no-pager

这里重点看三项：

Loaded：服务文件是否存在，是否设置为开机自启。
Active：服务当前是 active (running)、inactive 还是 failed。
ExecStart：systemd 实际调用哪个启动脚本。

如果服务是 active (running)，通常说明 systemd 视角下实例已正常托管。若显示 failed，再继续看日志：

bash 复制代码

journalctl -u DmServiceDMSERVER.service -n 80 --no-pager
tail -n 100 /dmdbms/log/DmServiceDMSERVER*.log

journalctl 是 systemd 层面的日志，适合看启动脚本返回码；/dmdbms/log 下的服务日志更接近 DM 服务脚本自身的报错。两者结合起来看，比只盯着 systemctl status 更准确。

三、数据目录：先把物理文件对上

来源： 《DM8 系统管理员手册》"DM 物理存储结构"；实例目录中文件名称结合本次单机环境观察整理。

DM8 实例的核心入口是 dm.ini。进程里一般会出现类似：

bash 复制代码

/dmdbms/bin/dmserver path=/dmdata/DAMENG/dm.ini

看到这个路径后，就能定位实例目录 /dmdata/DAMENG。数据目录里的文件可以按下面理解：

文件或目录	作用	排查价值
`dm.ini`	实例参数文件	端口、实例名、控制文件路径、归档开关
`dm.ctl`	控制文件	数据文件、日志文件等关键元信息
`SYSTEM.DBF`	系统表空间数据文件	系统对象和数据字典
`MAIN.DBF`	默认用户表空间数据文件	普通业务对象常见位置
`ROLL.DBF`	回滚表空间数据文件	事务回滚相关
`TEMP.DBF`	临时表空间数据文件	排序、临时结果、临时对象
`DAMENG01.log`、`DAMENG02.log`	联机重做日志	实例恢复、事务 redo
`dmarch.ini`	归档配置文件	归档路径、归档类型、归档空间限制
`bak` 或 `backup`	备份目录	备份文件占用、可恢复性
`log`	运行日志目录	启动异常、服务报错、错误堆栈

常用只读检查：

bash 复制代码

ls -lh /dmdata/DAMENG
grep -nE '^(INSTANCE_NAME|PORT_NUM|CTL_PATH|SYSTEM_PATH|ARCH_INI|MAL_INI|MPP_INI|COMPATIBLE_MODE)' /dmdata/DAMENG/dm.ini

这里不需要把 dm.ini 全部打开，先看关键项就够了：

INSTANCE_NAME：实例名。
PORT_NUM：监听端口。
CTL_PATH：控制文件路径。
SYSTEM_PATH：实例系统路径。
ARCH_INI：是否启用归档配置。
MAL_INI、MPP_INI：是否涉及数据守护、集群或 MPP 配置。
COMPATIBLE_MODE：兼容模式，影响部分 SQL 行为。

空间占用怎么看

文件系统空间不能只看"还有多少 G"，还要看使用率和增长趋势。下面是一个日常经验区间，不能替代容量规划，但可以作为排查时的第一判断：

说明： 下面的空间使用率区间是日常运维经验判断，不是 DM 官方固定阈值。生产环境仍应结合业务增长速度、备份策略和磁盘容量规划来定。

使用率	判断	建议
`< 70%`	比较健康	正常观察
`70% - 85%`	需要关注	看增长趋势，确认归档和备份策略
`85% - 90%`	有风险	开始准备清理或扩容
`90% - 95%`	高风险	优先查归档、备份、数据文件增长
`> 95%`	紧急	可能影响数据库写入、归档和服务稳定性

数据库服务器上，归档和备份目录经常是空间增长的重点。联机重做日志是循环使用并且覆盖的文件；开启归档后，历史 redo 会写入归档目录。应该关注归档目录和备份目录是否持续增加。

常用入口：

bash 复制代码

df -h
du -sh /dmdata/DAMENG/* 2>/dev/null | sort -h

df -h 看文件系统整体是否紧张，du -sh 看具体是哪类文件或目录占空间。

四、物理结构：用视图验证文件是否被数据库识别

来源： 《DM8 系统管理员手册》附录"动态性能视图"，主要对应 V$DATABASE、V$INSTANCE、V$TABLESPACE、V$DATAFILE、V$RLOGFILE、V$DM_ARCH_INI、V$ARCH_FILE。

操作系统上看到文件，只说明文件存在；数据库是否正在使用这些文件，还要进库看动态视图。

1. 数据库和实例状态

sql 复制代码

SELECT NAME, STATUS$, ROLE$, ARCH_MODE, CREATE_TIME, LAST_STARTUP_TIME
FROM V$DATABASE;

SELECT NAME, INSTANCE_NAME, HOST_NAME, START_TIME, STATUS$, MODE$
FROM V$INSTANCE;

这两个视图用于回答两个问题：

V$DATABASE：数据库是什么状态，是否归档，角色是什么。
V$INSTANCE：当前实例是否正常打开，运行在哪台主机，什么时候启动。

常见判断：

字段	看什么
`STATUS$`	数据库是否 `OPEN`、`MOUNT` 或挂起
`ARCH_MODE`	是否归档
`ROLE$`	普通库、主库、备库等角色
`STATUS$ / MODE$`	实例运行状态和模式

2. 表空间和数据文件

sql 复制代码

SELECT ID, NAME, STATUS$, TOTAL_SIZE, USED_SIZE, FILE_NUM, EXTEND_FAILED_CNT
FROM V$TABLESPACE;

SELECT GROUP_ID, ID, PATH, TOTAL_SIZE, FREE_SIZE, PAGE_SIZE,
       AUTO_EXTEND, MAX_SIZE, NEXT_SIZE
FROM V$DATAFILE;

这里要注意单位。TOTAL_SIZE、USED_SIZE、FREE_SIZE 往往按页统计，需要结合 PAGE_SIZE 换算。

表空间也可以按经验区间判断：

使用率	判断
`< 70%`	通常比较宽松
`70% - 85%`	需要观察增长
`85% - 90%`	应考虑扩展空间
`> 90%`	需要重点关注自动扩展和文件系统剩余空间

但表空间不能只看使用率，还要结合数据文件扩展能力一起判断：

字段	含义	怎么判断
`AUTO_EXTEND`	数据文件是否允许自动扩展，常见取值 `1` 表示允许，`0` 表示不允许	如果表空间使用率较高但 `AUTO_EXTEND=0`，后续写入可能更容易触发空间不足
`MAX_SIZE`	数据文件允许扩展到的最大大小，在 `V$DATAFILE` 中单位通常为 MB	当前大小接近 `MAX_SIZE` 时，即使开启自动扩展，也可能继续扩不动
`NEXT_SIZE`	每次自动扩展的步长	步长过小会频繁扩展，步长过大则要确认文件系统是否承受得住
`EXTEND_FAILED_CNT`	表空间自动扩展失败次数	大于 0 表示曾经发生扩展失败，需要结合数据库日志和文件系统空间继续排查

因此，表空间告警时要同时看三层：表空间使用率、数据文件是否还能扩、底层文件系统是否还有空间。只看其中一层，容易误判。

3. 联机日志和归档

sql 复制代码

SELECT GROUP_ID, FILE_ID, PATH, RLOG_SIZE
FROM V$RLOGFILE;

SELECT ARCH_NAME, ARCH_TYPE, ARCH_DEST, ARCH_FILE_SIZE, ARCH_SPACE_LIMIT, ARCH_IS_VALID
FROM V$DM_ARCH_INI;

SELECT STATUS, LEN, FREE, ARCH_LSN, CLSN, ARCH_SEQ, NEXT_SEQ, CREATE_TIME, CLOSE_TIME, PATH
FROM V$ARCH_FILE
ORDER BY CREATE_TIME DESC;

V$RLOGFILE 用来确认联机重做日志路径和大小。比如初始化时设置 LOG_SIZE=2048，通常会看到单个日志文件约 2GB。

归档开启后，建议把配置和实际文件分开看：

V$DM_ARCH_INI 看归档配置是否生效，例如归档名称、归档类型、本地归档目录、单个归档文件大小、空间限制和是否有效。
V$ARCH_FILE 看实际已经生成的归档文件，例如文件路径、文件长度、写入偏移、创建时间、关闭时间，以及该归档覆盖的 LSN 或日志包序号范围。

几个字段可以重点关注：

字段	含义	排查价值
`STATUS`	归档日志状态	判断归档文件当前状态
`LEN`、`FREE`	文件长度和当前写入偏移，单位为字节	判断归档文件大小和写入进度
`ARCH_LSN`、`CLSN`	归档文件起始 LSN、已归档最大 LSN	判断归档覆盖的日志范围
`ARCH_SEQ`、`NEXT_SEQ`	归档文件起始包序号、已归档最大包序号	判断归档包序号是否连续
`CREATE_TIME`、`CLOSE_TIME`	文件创建和关闭时间	判断归档生成频率、是否持续生成
`PATH`	归档文件完整路径	定位归档目录，排查磁盘占用

如果归档目录持续增长，排查顺序通常是：先看 dmarch.ini 或 V$DM_ARCH_INI 中的归档路径和空间限制，再看 V$ARCH_FILE 中归档文件生成频率，最后回到操作系统用 du -sh 看归档目录实际占用。

五、逻辑结构：先准备对象，再查结构

来源： 《DM8 系统管理员手册》附录"数据字典"，主要对应 SYSOBJECTS、SYSCOLUMNS、SYSTABLECOMMENTS、SYSCOLUMNCOMMENTS、SYSDEPENDENCIES；《DM8 SQL 语言使用手册》中 SP_TABLEDEF；《DM8 系统包使用手册》中 DBMS_METADATA.GET_DDL。

DM 里查对象，不能只按对象名查。尤其是建库时启用了大小写敏感时，更要同时关注模式名和对象名。

为了让下面的查询都能返回结果，可以先在测试环境准备一组演示对象。这里创建一张表、一个索引、一个视图，并补充表和字段注释。执行后，后面的对象清单、表结构、注释、DDL 和依赖关系查询都有明确目标。

sql 复制代码

CREATE TABLE SYSDBA.T_DM8_DEMO_EMP (
  EMP_ID INT NOT NULL,
  EMP_NAME VARCHAR(50) NOT NULL,
  DEPT_NAME VARCHAR(50),
  SALARY DECIMAL(10, 2),
  CREATE_TIME DATETIME DEFAULT SYSDATE,
  CONSTRAINT PK_T_DM8_DEMO_EMP PRIMARY KEY (EMP_ID)
);

CREATE INDEX SYSDBA.IDX_T_DM8_DEMO_EMP_DEPT
ON SYSDBA.T_DM8_DEMO_EMP(DEPT_NAME);

COMMENT ON TABLE SYSDBA.T_DM8_DEMO_EMP IS 'DM8逻辑结构演示表';
COMMENT ON COLUMN SYSDBA.T_DM8_DEMO_EMP.EMP_ID IS '员工ID';
COMMENT ON COLUMN SYSDBA.T_DM8_DEMO_EMP.EMP_NAME IS '员工姓名';
COMMENT ON COLUMN SYSDBA.T_DM8_DEMO_EMP.DEPT_NAME IS '部门名称';

INSERT INTO SYSDBA.T_DM8_DEMO_EMP(EMP_ID, EMP_NAME, DEPT_NAME, SALARY)
VALUES(1, 'ZHANGSAN', 'DBA', 12000);

INSERT INTO SYSDBA.T_DM8_DEMO_EMP(EMP_ID, EMP_NAME, DEPT_NAME, SALARY)
VALUES(2, 'LISI', 'DEV', 9000);

CREATE VIEW SYSDBA.V_DM8_DEMO_EMP AS
SELECT EMP_ID, EMP_NAME, DEPT_NAME
FROM SYSDBA.T_DM8_DEMO_EMP
WHERE SALARY >= 10000;

COMMIT;

这组 SQL 会创建对象和写入两行演示数据，属于变更操作，不建议在生产库随意执行。实际学习时可以放在测试库，或把对象名替换成已有业务对象。

1. 查当前用户和模式

sql 复制代码

SELECT USER;

这一步先确认当前连接用户。后面示例统一使用 SYSDBA 模式，如果当前不是 SYSDBA，要把 SQL 里的模式名替换成实际模式名。

2. 查模式和对象是否存在

sql 复制代码

SELECT NAME, ID, TYPE$, SUBTYPE$
FROM SYS.SYSOBJECTS
WHERE TYPE$ = 'SCH'
ORDER BY NAME;

SYSOBJECTS 是系统对象入口。TYPE$='SCH' 表示查模式。查具体对象时，要同时限定模式和对象名，避免不同模式下同名对象造成误判：

sql 复制代码

SELECT S.NAME AS SCH_NAME,
       O.NAME AS OBJ_NAME,
       O.SUBTYPE$,
       O.VALID
FROM SYS.SYSOBJECTS O
JOIN SYS.SYSOBJECTS S ON O.SCHID = S.ID
WHERE S.NAME = 'SYSDBA'
  AND O.NAME IN ('T_DM8_DEMO_EMP', 'V_DM8_DEMO_EMP', 'IDX_T_DM8_DEMO_EMP_DEPT')
ORDER BY O.SUBTYPE$, O.NAME;

这里重点看：

SCH_NAME：对象属于哪个模式。
OBJ_NAME：对象名。
SUBTYPE$：对象类型，如用户表、视图、索引等。
VALID：对象是否有效。

如果没有返回行，优先检查三点：对象是否真的创建成功、模式名是否写对、对象名大小写是否一致。

3. 查表结构、索引和注释

查表结构可以先用系统过程，结果更直观：

sql 复制代码

CALL SP_TABLEDEF('SYSDBA', 'T_DM8_DEMO_EMP');

如果想看字段层面的系统表信息，可以查 SYSCOLUMNS：

sql 复制代码

SELECT C.NAME AS COL_NAME,
       C.COLID,
       C.TYPE$,
       C.LENGTH$,
       C.NULLABLE$
FROM SYS.SYSCOLUMNS C
JOIN SYS.SYSOBJECTS O ON C.ID = O.ID
JOIN SYS.SYSOBJECTS S ON O.SCHID = S.ID
WHERE S.NAME = 'SYSDBA'
  AND O.NAME = 'T_DM8_DEMO_EMP'
ORDER BY C.COLID;

这条 SQL 的核心逻辑是：SYSOBJECTS 记录对象，SYSCOLUMNS 记录字段；两者通过对象内部 ID 关联。这样写比只按表名查更稳，因为它同时限定了模式名和对象名。

索引可以这样查：

sql 复制代码

SELECT IDX_OBJ.NAME AS INDEX_NAME,
       TAB.NAME AS TABLE_NAME,
       IDX_OBJ.VALID
FROM SYS.SYSOBJECTS IDX_OBJ
JOIN SYS.SYSOBJECTS TAB ON IDX_OBJ.PID = TAB.ID
JOIN SYS.SYSOBJECTS SCH ON TAB.SCHID = SCH.ID
WHERE SCH.NAME = 'SYSDBA'
  AND TAB.NAME = 'T_DM8_DEMO_EMP'
  AND IDX_OBJ.SUBTYPE$ = 'INDEX'
ORDER BY IDX_OBJ.NAME;

这条 SQL 通过 PID 找到索引所属的表。一般能看到主键对应的索引，以及手工创建的 IDX_T_DM8_DEMO_EMP_DEPT。

字段注释和表注释可以看：

sql 复制代码

SELECT SCHNAME, TVNAME, COMMENT$
FROM SYS.SYSTABLECOMMENTS
WHERE SCHNAME = 'SYSDBA'
  AND TVNAME = 'T_DM8_DEMO_EMP';

SELECT SCHNAME, TVNAME, COLNAME, COMMENT$
FROM SYS.SYSCOLUMNCOMMENTS
WHERE SCHNAME = 'SYSDBA'
  AND TVNAME = 'T_DM8_DEMO_EMP'
ORDER BY COLNAME;

这些注释对理解陌生业务库很有帮助。没有查到记录，不代表表不存在，只代表没有维护注释。

4. 查对象定义

需要导出或对比定义时，可以用：

sql 复制代码

SELECT DBMS_METADATA.GET_DDL('TABLE', 'T_DM8_DEMO_EMP', 'SYSDBA');

DBMS_METADATA.GET_DDL 返回对象的 DDL 文本，适合做迁移对比、问题复现和留存证据。它比直接查系统表更接近"建表语句"的形式。

使用时注意两点：

查询其他用户对象定义需要相应权限。
大对象或复杂对象的 DDL 可能很长，排查时可以先确认是否能取到，再按需导出。

5. 查依赖关系

对象依赖用于判断"改一个对象会影响谁"。例如本例中，视图 V_DM8_DEMO_EMP 依赖表 T_DM8_DEMO_EMP。

sql 复制代码

SELECT SRC.NAME AS OBJ_NAME,
       D.TYPE$ AS OBJ_TYPE,
       REF_OBJ.NAME AS REF_OBJ_NAME,
       D.REFED_TYPE$,
       D.DEPEND_TYPE
FROM SYS.SYSDEPENDENCIES D
JOIN SYS.SYSOBJECTS SRC ON D.ID = SRC.ID
JOIN SYS.SYSOBJECTS REF_OBJ ON D.REFED_ID = REF_OBJ.ID
JOIN SYS.SYSOBJECTS SCH ON SRC.SCHID = SCH.ID
WHERE SCH.NAME = 'SYSDBA'
  AND SRC.NAME = 'V_DM8_DEMO_EMP';

这条 SQL 比只按 对象名 写子查询更稳，因为它限定了源对象所属模式，也避免同名对象导致子查询返回多行。这里不要用 REF 作为表别名，REF 在 DM 中容易触发语法解析冲突，改成 REF_OBJ 这类明确别名更稳。查询结果可以看到视图依赖了哪些对象，适合在修改表结构、删除对象、重建视图前评估影响面。

六、常用排查入口

来源： 服务状态和磁盘检查使用 Linux systemctl、journalctl、df、du、ss 等通用命令；数据库侧状态检查参考《DM8 系统管理员手册》附录"动态性能视图"，主要对应 V$TABLESPACE、V$DATAFILE、V$TRXWAIT、V$SESSIONS、V$TRX。

下面按问题类型整理，不追求命令多，而是强调先看哪里。

1. 启动失败

先看服务状态：

bash 复制代码

systemctl status DmServiceDMSERVER.service --no-pager

如果是 failed，继续看：

bash 复制代码

journalctl -u DmServiceDMSERVER.service -n 80 --no-pager
tail -n 100 /dmdbms/log/DmServiceDMSERVER*.log

再确认进程和端口：

bash 复制代码

ps -ef | grep -i '[d]mserver'
ss -lntp | grep 15236

判断顺序：

服务脚本有没有执行。
数据库进程有没有起来。
端口是否监听。
日志里是否提示参数、权限、端口或控制文件问题。

2. 连接失败

先看端口和参数是否一致：

bash 复制代码

ss -lntp | grep 15236
grep -n '^PORT_NUM' /dmdata/DAMENG/dm.ini

如果数据库端口是 15236，客户端还按默认 5236 连，就会失败。涉及客户端服务名时，再检查 dm_svc.conf。

3. 空间告警

先分清"文件系统满"还是"数据库对象满"：

bash 复制代码

df -h
du -sh /dmdata/DAMENG/* 2>/dev/null | sort -h

进入库后再看：

sql 复制代码

SELECT NAME, TOTAL_SIZE, USED_SIZE, FILE_NUM, EXTEND_FAILED_CNT
FROM V$TABLESPACE;

SELECT PATH, TOTAL_SIZE, FREE_SIZE, PAGE_SIZE, AUTO_EXTEND, MAX_SIZE, NEXT_SIZE
FROM V$DATAFILE;

优先关注：

文件系统是否超过 85% 或 90%。
归档、备份是否持续增长。
表空间是否接近上限。
自动扩展是否开启但底层文件系统已经不足。

4. 锁与阻塞

锁问题不要只看 V$LOCK 有没有记录。数据库正常运行时也可能有锁。更直接的入口是等待关系：

sql 复制代码

SELECT ID, WAIT_FOR_ID, WAIT_TIME, LOCK, WAIT_FOR_LOCK
FROM V$TRXWAIT
ORDER BY WAIT_TIME DESC;

再结合事务和会话：

sql 复制代码

SELECT S.SESS_ID,
       S.USER_NAME,
       S.CLNT_IP,
       S.STATE,
       S.SQL_TEXT,
       T.ID AS TRX_ID,
       T.STATUS,
       T.WAITING
FROM V$SESSIONS S
LEFT JOIN V$TRX T ON S.SESS_ID = T.SESS_ID
WHERE T.STATUS = 'LOCK WAIT' OR S.STATE = 'ACTIVE';

这条 SQL 的含义是：把会话和事务放在一起看，既能看到谁在执行 SQL，也能看到事务是否处于锁等待。生产环境里不要看到阻塞就直接杀会话，应先确认业务影响和事务来源。

七、总结

参考资料

《DM8 系统管理员手册》：物理存储结构、附录"数据字典"、附录"动态性能视图"。
《DM8 SQL 语言使用手册》：系统过程与函数，尤其是 SP_TABLEDEF。
《DM8 系统包使用手册》：DBMS_METADATA 包，尤其是 GET_DDL。
Linux 系统命令手册或系统帮助：systemctl、journalctl、df、du、ss。

梳理 DM8 已安装环境时，我觉得最重要的是把"位置"和"判断"对应起来：

启动失败，先看 systemd 状态、服务日志、dm.ini 和控制文件路径。
连接失败，先看进程、端口、PORT_NUM 和客户端连接配置。
空间问题，先看文件系统使用率，再看数据文件、归档和备份。
对象问题，先看模式和对象名，再看字段、索引、定义和依赖。
锁阻塞，先看 V$TRXWAIT 和会话来源，不要只看锁数量。

这套方法的价值在于减少盲目操作。先确认数据库软件在哪里、实例文件在哪里、库内对象在哪里，再根据现象选择对应的视图和日志入口，排查思路会清楚很多。