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

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

这篇文章以一个单机 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 或安装时指定的位置。不能只靠记忆，现场可以先通过进程反推：

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 看：

systemctl status DmServiceDMSERVER.service --no-pager

这里重点看三项：

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

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

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。进程里一般会出现类似：

/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	运行日志目录	启动异常、服务报错、错误堆栈

常用只读检查：

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 会写入归档目录。应该关注归档目录和备份目录是否持续增加。

常用入口：

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. 数据库和实例状态

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. 表空间和数据文件

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. 联机日志和归档

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 和依赖关系查询都有明确目标。

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. 查当前用户和模式

SELECT USER;

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

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

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

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

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. 查表结构、索引和注释

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

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

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

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 关联。这样写比只按表名查更稳，因为它同时限定了模式名和对象名。

索引可以这样查：

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。

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

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. 查对象定义

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

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。

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. 启动失败

先看服务状态：

systemctl status DmServiceDMSERVER.service --no-pager

如果是 failed，继续看：

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

再确认进程和端口：

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

判断顺序：

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

2. 连接失败

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

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

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

3. 空间告警

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

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

进入库后再看：

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 有没有记录。数据库正常运行时也可能有锁。更直接的入口是等待关系：

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

再结合事务和会话：

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 环境为例。主机名为 dm，运行用户为 dmdba，安装目录为 /dmdbms，实例目录为 /dmdata/DAMENG，服务名为 DmServiceDMSERVER，监听端口为 15236。文中保留了几类现场构造的轻量错误，包括错误密码、错误端口、错误视图字段、错误启动路径、目录权限不足和服务停止后的连接失败；没有在单机环境中伪造集群故障。

1. 基础确认：先知道自己在哪个实例上

排查开始前先确认四类信息：实例入口、目录规划、最近变更和基础资源。部署流程里的“安装前准备”和“安装后检查”并不是形式化步骤，它们决定后面能不能快速判断问题落在哪一层。

这张图先确认了当前用户、主机名、工作目录，以及 /dmdbms、/dmdata、/dmarch、/dmbak、/dmcore 的属主和权限。后面遇到启动失败、备份写入失败、归档异常或 core 文件生成异常时，这些目录信息都可以直接复用。

排查时可以用几条基础命令补齐现场基线。先确认当前登录用户、主机和工作目录，避免在错误的机器或错误用户下操作：

whoami
hostname
pwd

再看服务、进程和端口，确认当前实例是否已经由服务拉起、是否有 dmserver 进程、监听端口是否符合现场记录：

systemctl status DmServiceDMSERVER.service
ps -ef | grep dmserver | grep -v grep
ss -lntp | grep 15236

实例入口和目录规划也要确认到文件系统层面。这里不用展开复杂参数，只先看 dm.ini 是否在预期实例目录下，以及几个规划目录是否存在、属主是否正常：

ls -l /dmdata/DAMENG/dm.ini
ls -ld /dmdbms /dmdata /dmarch /dmbak /dmcore

最后看基础资源，先判断是不是已经存在明显的磁盘或内存压力：

df -h /dmdbms /dmdata /dmarch /dmbak /dmcore
free -h

透明大页、RemoveIPC、MALLOC_ARENA_MAX、磁盘调度这类项目，部署流程里已经作为安装后检查项单独列出。排查前只要知道它们属于需要复核的系统项即可，真正怀疑系统配置问题时再回到部署流程逐项确认。

基础信息建议至少留存：

• 部署模式：单机、主备、读写分离、DSC。
• 实例入口：安装目录、实例目录、dm.ini、服务名、端口。
• 目录规划：数据目录、归档目录、备份目录、日志和 core 目录。
• 最近变更：参数修改、重启、导入数据、防火墙或安全策略调整。
• 基础资源：CPU、内存、磁盘、文件系统、归档和备份目录容量。

2. 服务类问题：状态只说明现象，日志才解释原因

服务启动失败、启动后退出、重启后未自启，第一入口是 systemd、进程和日志。正常状态下，systemctl status 能看到服务 active (running)，ps 能看到 dmserver 进程，配置文件指向 /dmdata/DAMENG/dm.ini。

systemctl status DmServiceDMSERVER.service --no-pager -l
ps -ef | grep dmserver | grep -v grep

如果服务状态异常，不能只停在 inactive 或 failed。需要继续看同一时间点的端口、连接和日志。下面这张图是主动停止实例后保留的现场证据，对应执行命令如下：

systemctl stop DmServiceDMSERVER.service
systemctl is-active DmServiceDMSERVER.service
systemctl status DmServiceDMSERVER.service --no-pager -l
ss -lntp | grep 15236
cd /dmdbms/bin
./disql SYSDBA/'"Dameng@1234"':15236
journalctl -u DmServiceDMSERVER.service -n 5 --no-pager
ls -ltr /dmdbms/log/DmServiceDMSERVER*.log
tail -n 80 /dmdbms/log/DmServiceDMSERVER*.log

这组命令的含义分别是：systemctl stop 用来构造服务停止场景；is-active 快速看服务是否还在运行；systemctl status 看服务状态、启动命令和最近的 systemd 输出；ss 看 15236 端口是否还在监听；disql 从数据库客户端角度复测连接；journalctl -u 是查看该 systemd 服务的日志；ls/tail /dmdbms/log/DmServiceDMSERVER*.log 是查看 DM 服务脚本自身写出的日志。

执行后可以看到服务状态变成 inactive，15236 不再监听，disql 返回 [-70028]:创建SOCKET连接失败，journalctl 中能看到服务执行了停止动作并成功退出。若是启动失败而不是人工停止，还要继续看 /dmdbms/log/DmServiceDMSERVER*.log 里是否有路径、权限、端口或资源相关报错。

这个场景的判断链比较清楚：连接失败不是密码问题，也不是客户端 SQL 问题，而是服务已经停止，端口层没有监听。处理时应先恢复服务，再复查 systemctl status、ss -lntp | grep 15236 和本机 disql 连接；如果服务启动失败，再进入服务日志和实例日志继续定位。

服务类问题最容易漏掉启动路径。现场还构造了一次错误启动路径，把 dm.ini 指向不存在的文件：

cd /dmdbms/bin
./dmserver path=/dmdata/DAMENG/not_exist.ini

返回的核心报错是：

open ini file /dmdata/DAMENG/not_exist.ini failed!
nsvr_ini_file_read failed, [code: -140]

这类错误不代表数据库文件损坏，而是启动入口错了。排查时要回到服务文件和实例路径：

systemctl cat DmServiceDMSERVER.service
journalctl -u DmServiceDMSERVER.service -n 80 --no-pager
ls -l /dmdata/DAMENG/dm.ini
grep -n '^PORT_NUM' /dmdata/DAMENG/dm.ini

如果日志中出现 Permission denied，重点转向目录属主和执行权限；如果提示端口占用，重点转向 ss -lntp 和其他进程；如果提示内存或资源不足，再看系统资源和相关参数。服务排查不要直接改 dm.ini，先把日志里的第一条明确错误找出来。

3. 连接访问类问题：按层次缩小范围

“连不上”只是现象，不能直接等同于网络问题。连接访问类问题建议按四层判断：数据库服务层、系统端口层、网络策略层、客户端配置层。

先看端口监听，再做一次正确连接作为基线：

ss -lntp | grep 15236
cd /dmdbms/bin
./disql SYSDBA/'"Dameng@1234"':15236

基线能连通，说明本机客户端、数据库服务和 15236 端口是通的。之后再看不同错误的差异。

错误密码的构造方式是端口不变，只把密码写错：

./disql SYSDBA/'"WrongPass123"':15236

返回：

[-2501]:用户名或密码错误.
DISQL-10030: 连接恢复失败

同一端口下正确密码能连，错误密码返回认证失败，说明请求已经到达数据库认证层。处理方向是核对应用连接串、dm_svc.conf、账号状态、密码是否过期或被锁定，复测时仍然回到正确账号连接。

错误端口的构造方式是密码保持正确，把端口改成没有监听的 15237：

./disql SYSDBA/'"Dameng@1234"':15237

返回：

[-70028]:创建SOCKET连接失败.
DISQL-10036: 连接丢失

这时应回看监听结果：现场只有 15236，没有 15237。如果本机能连、远端不能连，就从应用服务器或客户端机器上继续测网络连通性：

nc -vz 192.168.166.248 15236
telnet 192.168.166.248 15236

服务端再看防火墙或安全策略是否放行数据库端口：

firewall-cmd --state
firewall-cmd --list-ports
iptables -S | grep 15236

如果使用服务名连接，则重点核对 dm_svc.conf 中服务名、地址和端口是否与实例规划一致。

4. 连接数和会话类问题：直接查参数和会话来源

连接数超限在应用系统里也常表现为“连接不上”，但它和端口错误不同。端口仍然监听，数据库也在运行，只是新会话申请被限制。常见原因包括应用连接池未释放、短连接过多、用户级会话限制过小，或者实例级 MAX_SESSIONS 已接近上限。

这类问题先查两个入口：实例级连接参数和当前会话来源。

SELECT PARA_NAME, PARA_VALUE
FROM V$DM_INI
WHERE PARA_NAME IN ('MAX_SESSIONS', 'MAX_SESSION_STATEMENT');

SELECT USER_NAME, CLNT_IP, COUNT(*) CNT
FROM V$SESSIONS
GROUP BY USER_NAME, CLNT_IP
ORDER BY CNT DESC;

截图里 MAX_SESSIONS 和 MAX_SESSION_STATEMENT 都是 10000，当前会话来源只有本机 SYSDBA 一条连接，说明这个现场当时没有连接数打满的问题。如果实际环境里同一查询返回大量来自某个应用 IP 或某个用户的连接，排查重点就应转向应用连接池、空闲连接释放和用户级连接限制。

MAX_SESSIONS 是实例允许同时连接的最大会话数，《DM8 系统管理员手册》中标注为静态参数。用户级限制可以通过 ALTER USER ... LIMIT SESSION_PER_USER ... 设置。参数是否要调大，要结合会话来源和应用连接池一起判断，不能只因为出现连接失败就直接改大连接数。

5. SQL、视图类问题：先确认入口是否写对

系统视图是排查入口，但字段要以现场版本为准。现场故意查询一个当前环境不支持的字段：

select name,status$,mode$ from v$database;

返回：

第1 行附近出现错误[-2111]:无效的列名[MODE$].

如果是为了修正这条 SQL，应该继续回到同一个视图，改查当前环境中真实存在的字段。例如：

select name,arch_mode,status$ from v$database;

截图里后面又查了 V$INSTANCE，它的作用是确认实例名和实例状态，不是用来证明 V$DATABASE 的字段存在。这个例子说明，资料里的 SQL 不能不加判断地套到现场。遇到 无效的列名，先查视图结构、版本和权限，再把 SQL 改成当前环境支持的字段；如果要确认实例是否打开，再转到 V$INSTANCE 这类实例状态视图。

6. 空间、备份和内存类问题：先看目录留存和资源水位

空间类问题不能只看表空间。备份目录、归档目录、根分区和内存水位都会影响数据库运行。巡检时可以先从文件系统入口判断风险，再决定是否进入库内视图继续查表空间、归档和备份任务。

备份目录重点看 /dmbak。先确认目录是否存在、属主是否正确、当前占用多大：

ls -ld /dmbak
du -sh /dmbak

再进入备份目录查看文件或备份集是否覆盖一个完整备份留存周期。例如保留 7 天备份，就要确认最近 7 天是否都有对应备份文件或备份集：

du -sh /dmbak/*

du -sh /dmbak/* 不只是看总大小，也要看同类备份文件大小是否相近。全量备份之间大小突然差很多，可能是备份范围变化、备份中断、清理脚本误删，或者业务数据量发生明显变化；增量备份持续变大，则要结合归档量、变更量和备份周期一起判断。

归档目录也要看空间水位。/dmarch 下有文件，说明这里曾经或正在承载归档文件；如果重新配置归档时报 [-523]:磁盘空间不足，优先检查文件系统剩余空间、归档上限和清理策略，而不是只看 SQL 是否执行成功。

df -h /dmdata /dmarch /dmbak /dmdbms
du -sh /dmarch /dmbak

系统内存也要纳入同一轮检查。可以用 free -h 先看整体内存和 swap 使用情况：

free -h

一般不建议让数据库服务器长期处在内存使用率过高的状态，可把 75% 作为一个提醒线。

7. 权限与目录类问题：从安装规范回到现场

权限类问题常见现象包括启动报 Permission denied、备份写不进去、归档生成失败、工具脚本无法执行。排查入口仍然是当前用户和目录属主。

现场用 dmdba 访问 /root 并创建文件，返回权限不足：

cd /root
touch /root/dm_permission_demo

这个例子可以类推到数据库目录：如果 /dmdata、/dmarch、/dmbak 的属主或权限被改乱，数据库运行用户就可能无法写数据文件、归档文件或备份集。处理时要按部署规范恢复目录归属和执行权限，同时避免在生产环境中为了省事给过大的权限。

8. 集群类问题：单机正常不代表集群正常

当前环境是单机实例，所以不伪造主备或读写分离故障。现场检查没有 dmwatcher、dmmonitor、dmap 进程，也没有在 /dmdata 下发现 dmmal.ini、dmwatcher.ini、dmmonitor.ini：

如果是在主备、读写分离或 DSC 环境，排查不能只看 dmserver 是否 OPEN。还要继续看：

• 守护和监视：dmwatcher、dmmonitor、Watcher 日志、监视器 show global info。
• MAL 和心跳：dmmal.ini、MAL 端口、心跳网络、节点间防火墙策略。
• 归档同步：dmarch.ini、V$DM_ARCH_INI、归档目的端、归档文件连续性。
• 客户端路由：dm_svc.conf、服务名、主备切换后的连接策略。

集群排查的核心是区分“实例能打开”和“集群链路正常”。单机里 dmserver 正常只能证明实例正常；集群里还要证明守护、监视、同步、网络和客户端路由都正常。

9. 部署后检查：把检查项变成排查依据

部署结束后的检查项，后面都会变成排查依据。至少应确认：

• dmserver、dmap 或相关服务是否注册并设置自启。
• 服务文件中的 dm.ini 路径、实例目录和端口是否与规划一致。
• 透明大页、RemoveIPC、MALLOC_ARENA_MAX、磁盘调度策略是否按规范处理。
• /dmdata、/dmarch、/dmbak 是否按规划分离，容量是否足够。
• 归档、备份任务、统计信息任务和必要的 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 和会话来源，不要只看锁数量。

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