第一天，我把Oracle那套存储过程改吧改吧，塞进disql里执行。disql报错："输入过长"。
行，拆成两个文件。能跑了，但维护起来太麻烦，改一个地方得改两个文件。
第二天，我对着达梦的官方文档，一个一个视图去对列名。这才发现，达梦的系统视图跟Oracle差异巨大——V$INSTANCE里没有STATUS列，人家叫STATUS$；没有SV_VERSION，叫SVR_VERSION；V$SQL_HISTORY里找不到EXEC_TIME，得用TIME_USED，单位还是微秒。折腾了一整天，改了五六轮，终于能跑通了。
第三天，我在脚本里加了几行提示信息，写的是PROMPT [备份] Transaction Info。结果disql弹出一个输入提示，要我输入"Transaction"的值。我这才知道，disql会把PROMPT后面的英文单词当成变量名来解析。
三天下来，我悟了：别整花活，老老实实用纯SQL。
于是有了下面这套脚本——12个独立SQL文件，每个10到38行，不建任何存储过程、函数、视图，对生产库零侵入。直接在disql里执行就行，跑完就出结果。
01. 实例基本信息 —01_instance.sql
-- 实例基本信息 (使用 V$INSTANCE 真实列名) SELECT INSTANCE_NAME, HOST_NAME, SVR_VERSION AS VERSION, DB_VERSION, TO_CHAR(START_TIME, 'YYYY-MM-DD HH24:MI:SS') AS START_TIME, STATUS$ AS STATUS, MODE$ AS MODE_TYPE, DSC_ROLE AS DSC_ROLE FROM V$INSTANCE;看什么：实例名、主机名、版本、启动时间、运行状态。
常见问题：STATUS$为空或者不是预期值，说明实例可能有问题。DSC_ROLE在单机环境通常是NULL，集群环境才会显示节点角色。
注意：DM8的列名带$后缀，跟Oracle不一样，别搞混。
02. 内存参数 —02_memory.sql
SELECT NAME AS PARAM_NAME, ROUND(VALUE/1024/1024, 2) AS VALUE_MB, CASE TYPE WHEN 1 THEN 'static' WHEN 2 THEN 'dynamic' ELSE 'other' END AS TYPE_DESC FROM V$PARAMETER WHERE NAME IN ('MAX_MEMORY','MEMORY_POOL','BUFFER', 'MAX_BUFFER_SIZE','BUFFER_POOLS') ORDER BY NAME;看什么：最大内存上限、内存池大小、缓冲区大小。
常见问题：MAX_MEMORY设得太小会导致数据库OOM；BUFFER显示为0.01MB通常意味着启用了动态缓冲区管理，这是正常现象；MEMORY_POOL过小会影响排序和哈希操作的性能。
03. 表空间使用率（⭐核心告警）—03_tablespace.sql
SELECT A.TABLESPACE_NAME, ROUND(A.TOTAL_SIZE*8192/1024/1024, 2) AS TOTAL_MB, ROUND(B.FREE_SIZE*8192/1024/1024, 2) AS FREE_MB, ROUND((A.TOTAL_SIZE-B.FREE_SIZE)*8192/1024/1024, 2) AS USED_MB, ROUND((A.TOTAL_SIZE-B.FREE_SIZE)*100.0/NULLIF(A.TOTAL_SIZE,0), 2) AS USED_PCT, C.STATUS, CASE WHEN (A.TOTAL_SIZE-B.FREE_SIZE)*100.0/NULLIF(A.TOTAL_SIZE,0) >= 85 THEN '!! WARN' ELSE 'OK' END AS FLAG FROM ( SELECT TABLESPACE_NAME, SUM(BYTES) TOTAL_SIZE FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME ) A, ( SELECT TABLESPACE_NAME, SUM(BYTES) FREE_SIZE FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME ) B, ( SELECT DISTINCT TABLESPACE_NAME, STATUS FROM DBA_DATA_FILES ) C WHERE A.TABLESPACE_NAME=B.TABLESPACE_NAME(+) AND A.TABLESPACE_NAME=C.TABLESPACE_NAME(+) ORDER BY USED_MB DESC;看什么：每个表空间的总大小、已用大小、使用率百分比，超过85%会标记!! WARN。
常见问题：MAIN表空间使用率接近100%时，数据库就无法写入新数据了，这是生产环境最高优先级的告警。达梦页大小默认8KB，所以计算时用*8192转成MB——如果你建库时指定了不同的页大小，这个值要相应调整。
04. 数据文件Top15 —04_datafile.sql
SELECT FILE_ID, TABLESPACE_NAME, FILE_NAME, ROUND(BYTES/1024/1024, 2) AS SIZE_MB, AUTOEXTENSIBLE, ROUND(MAXBYTES/1024/1024, 2) AS MAXSIZE_MB, STATUS FROM DBA_DATA_FILES ORDER BY BYTES DESC LIMIT 15;看什么：最大的15个数据文件，以及它们是否开启了自动扩展。
常见问题：AUTOEXTENSIBLE=NO且SIZE_MB快要到MAXSIZE_MB的文件，是最先可能出问题的。另外留意一下数据文件是不是分布在系统盘，生产环境应该放在专用数据盘上。
05. 会话统计与活跃会话 —05_session.sql
-- 会话汇总 SELECT COUNT(*) AS TOTAL_SESSIONS, COUNT(CASE WHEN STATE='ACTIVE' THEN 1 END) AS ACTIVE_SESSIONS, COUNT(CASE WHEN STATE!='ACTIVE' THEN 1 END) AS INACTIVE_SESSIONS, CASE WHEN COUNT(*) > 200 THEN '!! EXCEEDS THRESHOLD' ELSE 'OK' END AS FLAG FROM V$SESSIONS; -- Active Sessions TOP15 SELECT SESSID, USER_NAME, CLNT_IP AS CLIENT_IP, STATE, APPNAME, LEFT(SQL_TEXT,60) AS SQL_TEXT, LAST_RECV_TIME, ROUND((SYSDATE-LAST_RECV_TIME)*86400, 0) AS IDLE_SEC FROM V$SESSIONS WHERE STATE='ACTIVE' ORDER BY IDLE_SEC ASC LIMIT 15;看什么：会话总数（超过200会告警）、活跃/非活跃会话数量、当前正在执行的SQL。
常见问题：活跃会话突然飙升，通常意味着有锁等待或大量慢查询堆积。非活跃会话大量积压，说明应用连接池没有正确释放连接。CLNT_IP字段如果是IPv6格式（如::ffff:172.x.x.x），需要手动转换一下看真实IP。
06. 锁等待与长事务 —06_lock.sql
-- 6.1 锁等待数量 SELECT COUNT(*) AS LOCK_WAIT_COUNT FROM V$TRXWAIT; -- 6.2 锁等待详情 (V$TRXWAIT: ID=等待事务ID, WAIT_FOR_ID=阻塞事务ID) SELECT ID AS WAIT_TRX_ID, WAIT_FOR_ID AS HOLD_TRX_ID FROM V$TRXWAIT WHERE ROWNUM <= 20; -- 6.3 当前活跃事务 (V$TRX 真实列) SELECT ID AS TRX_ID, SESS_ID, STATUS AS TRX_STATUS, ISOLATION, READ_ONLY FROM V$TRX WHERE STATUS <> 'COMMIT' ORDER BY ID LIMIT 20;看什么：锁等待数量、谁在等谁、当前未提交的事务。
常见问题：LOCK_WAIT_COUNT > 0说明存在事务阻塞，需要立即排查。死锁信息不在视图里，得去dmserver.log搜DEADLOCK关键字。
注意：V$TRX的列名是ID（不是TRX_ID）、SESS_ID（不是SESSION_ID），这里跟Oracle完全不同。我特意把三个查询拆开写，不做JOIN，因为disql对复杂JOIN的解析容易出问题。