良的世界

案例：达梦数据库利用dmlcvt解析归档日志定位删除事务

shine — Fri, 07 Aug 2026 07:34:10 +0000

一、问题背景

客户反馈系统中某条数据丢失，需确认：

该条数据是否成功插入？
若已插入，数据是如何丢失的？

二、排查环境

数据库版本：8.1.3.62 Pack31

三、排查步骤

步骤1：使用dmlcvt解析归档日志

利用达梦dmlcvt工具解析指定时间范围内的归档日志文件，输出rec_info*.txt等文件，其中包含所有记录级操作信息。

dmlcvt F_TYPE=1 F_PATH=/归档目录 OP_TYPE=1 REC_DATA=1 OUT_PATH=/输出目录

步骤2：统计各表的操作次数，定位问题表

编写统计脚本analyze_rec.sh，从rec_info*.txt中提取所有UREC_INS（插入）和UREC_DEL（删除）操作，按tabid（表ID）聚合计数，并按数量从大到小排序。

脚本内容：

#!/bin/bash
# 用法: ./analyze_rec.sh rec_info*.txt
# 功能: 统计所有表的增删操作，按数量从大到小排序

awk '{
    match($0, /UREC_[A-Z]+:/);
    Operation = substr($0, RSTART, RLENGTH);
    match($0, /tabid:[0-9a-fA-Fx]+/);
    tabid = substr($0, RSTART, RLENGTH);
    if (Operation != "" && tabid != "") {
        print Operation, tabid;
    }
}' "$@" | sort | uniq -c | sort -rn

执行命令：

./analyze_rec.sh rec_info*.txt > res.log

输出示例（部分）：

排查发现：目标数据所在表tabid:0x47f()共有 4条删除记录，数量虽少，但极有可能包含丢失的那条数据。

步骤3：从rec_info文件中提取事务号

grep -aE "UREC_DEL.*tabid:0x47f()" rec_info*.txt > 0x47f.del

输出示例：

提取到4个事务号：

13681865115
13681901417
13684820518
13688504573

步骤4：关联SQL日志定位删除语句

用步骤3提取的事务号作为关键字，在SQL日志中搜索对应的日志

grep -aE "trxid:13681865115|trxid:13681901417|trxid:13684820518|trxid:13688504573" dmsql_*.log > deltrx.log

在SQL日志中定位到具体的DELETE语句，确认数据是被业务方的删除操作所删除。

四、结论

通过归档日志解析和SQL日志关联分析，得出以下结论：

数据是否插入成功？是（rec_info中存在对应UREC_INS记录）

数据如何丢失？被业务方执行的 DELETE语句删除（SQL日志中定位到具体语句）

五、经验总结

解析归档：dmlcvt解析归档日志
定位可疑表：SYSOBJECTS表查看ID，转化成十六进制
提取事务号：从rec_info中提取nrec_tid
定位SQL：用事务号搜索SQL日志

六、附录：关键命令速查

# 1. 统计各表操作次数
./analyze_rec.sh rec_info*.txt > res.log

# 2. 查找目标表的所有删除记录及事务号
grep -aE "UREC_DEL.*tabid:0x47f()" rec_info*.txt > 0x47f.del

# 3. 用事务号在SQL日志中定位删除语句
grep -aE "trxid:13681865115|trxid:13681901417|trxid:13684820518|trxid:13688504573" dmsql_*.log > deltrx.log

# 4. 确认数据曾插入成功
grep -aE "UREC_INS.*tabid:0x47f()" rec_info*.txt

# 5. 表ID转化成十六进制
SELECT 
    ID,
    UTL_RAW.CAST_FROM_INT(ID) AS HEX_ID
FROM SYSOBJECTS
WHERE NAME = 'TABNAME'
  AND SCHID = (SELECT ID FROM SYSOBJECTS WHERE TYPE$ = 'SCH' AND NAME = 'SCHNAME');

达梦数据库主备集群动态增加实时备库

shine — Thu, 16 Jul 2026 07:10:28 +0000

当需要进行系统扩容，希望系统运行不中断，或者影响运行的时间尽可能短时，可通过动态增加节点的方式进行。下面举例对实时主备进行动态增加节点。

在实时主备集群（192.168.182.142，192.168.182.143）的基础上，再增加一个备库（192.168.182.144）,详细步骤如下：

一、对主库进行联机备份

SQL> backup database full backupset '/dmbak/full/bakfile20260715';

二、传输备份文件到新备库

[dmdba@dmdb:/home/dmdba]$ scp -r /dmbak/full/bakfile20260715/ dmdba@192.168.182.144:/dmbak/full

三、还原恢复新备库

此处就不展示初始化新增备库的过程了，按照原主备集群的初始化参数进行初始化即可，初始化后可对比现集群中主库的dm.ini。保证新增备库配置参数与当前集群完全一致。

dmrman CTLSTMT="RESTORE DATABASE '/dmdata/SMS/dm.ini' FROM BACKUPSET '/dmbak/full/bakfile20260715'"

dmrman CTLSTMT="RECOVER DATABASE '/dmdata/SMS/dm.ini' FROM BACKUPSET '/dmbak/full/bakfile20260715'"

dmrman CTLSTMT="RECOVER DATABASE '/dmdata/SMS/dm.ini' UPDATE DB_MAGIC"

四、配置新备库

4.1 配置dm.ini

#实例名顺延即可，建议使用“组名_守护环境_序号”的命名方式，总长度不能超过 16
#由于我的环境原主备为SMS01和SMS02，所以此处配置为SMS03

INSTANCE_NAME = SMS03 
PORT_NUM = 5236 					#数据库实例监听端口 
DW_INACTIVE_INTERVAL = 60 				#接收守护进程消息超时时间 
ALTER_MODE_STATUS = 0 					#不允许手工方式修改实例模式/状态/OGUID 
ENABLE_OFFLINE_TS = 2 					#不允许备库 OFFLINE 表空间 
MAL_INI = 1 						#打开 MAL 系统 
ARCH_INI = 1 						#打开归档配置 
RLOG_SEND_APPLY_MON = 64 				#统计最近 64 次的日志重演信息

4.2 配置dmmal.ini

可以从当前集群的任一节点直接传输到新增节点，再添加上自己一项

[dmdba@dmdb:/home/dmdba]$ scp -r /dmdata/SMS/dmmal.ini dmdba@192.168.182.144:/dmdata/SMS/

此处展示文件全部内容，其中[MAL_INST3]部分为新增内容

[dmdba@dmdb:/dmdata/SMS]$ cat dmmal.ini 
MAL_CHECK_INTERVAL      = 5
MAL_CONN_FAIL_INTERVAL  = 5

[MAL_INST1]
  MAL_INST_NAME         = SMS01
  MAL_HOST              = 192.168.182.142
  MAL_PORT              = 5246
  MAL_INST_HOST         = 192.168.182.142
  MAL_INST_PORT         = 5236
  MAL_DW_PORT           = 5256
  MAL_INST_DW_PORT      = 5266

[MAL_INST2]
  MAL_INST_NAME         = SMS02
  MAL_HOST              = 192.168.182.143
  MAL_PORT              = 5246
  MAL_INST_HOST         = 192.168.182.143
  MAL_INST_PORT         = 5236
  MAL_DW_PORT           = 5256
  MAL_INST_DW_PORT      = 5266

[MAL_INST3]
  MAL_INST_NAME         = SMS03
  MAL_HOST              = 192.168.182.144
  MAL_PORT              = 5246
  MAL_INST_HOST         = 192.168.182.144
  MAL_INST_PORT         = 5236
  MAL_DW_PORT           = 5256
  MAL_INST_DW_PORT      = 5266

4.3 配置dmarch.ini

添加原始两节点实时归档（如已开启归档），否则还需要添加上本地归档

示例：

[ARCHIVE_REALTIME] 

ARCH_TYPE = REALTIME 			#实时归档类型 

ARCH_DEST = GRP1_RT_01			#实时归档目标实例名 

[ARCHIVE_REALTIME2] 

ARCH_TYPE = REALTIME 			#实时归档类型 

ARCH_DEST = GRP1_RT_02 			#实时归档目标实例名

文件内容（单个文件大小和归档上限根据原始环境配置）

[dmdba@dmdb:/dmdata/SMS]$ cat dmarch.ini 
[ARCHIVE_LOCAL]
ARCH_TYPE = LOCAL
ARCH_DEST = /dmarch
ARCH_FILE_SIZE = 1024
ARCH_SPACE_LIMIT = 3072

[ARCHIVE_REALTIME1]
ARCH_TYPE = REALTIME
ARCH_DEST = SMS01
ARCH_WAIT_APPLY = 0

[ARCHIVE_REALTIME2]
ARCH_TYPE = REALTIME
ARCH_DEST = SMS02
ARCH_WAIT_APPLY = 0

4.4 配置dmwatcher.ini

可以从当前集群的任一节点直接传输到新增节点，检查各项配置是否正确。配置为全局守护类型，使用自动切换模式，我修改了 INST_STARTUP_CMD 中启动服务名为新增节点服务名。

文件内容

[dmdba@dmdb:/dmdata/SMS]$ cat dmwatcher.ini 
[GRP1]
DW_TYPE = GLOBAL
DW_MODE = AUTO
DW_ERROR_TIME = 10
INST_RECOVER_TIME = 60
INST_ERROR_TIME = 10
INST_OGUID = 26180
INST_INI = /dmdata/SMS/dm.ini
INST_AUTO_RESTART = 1
INST_STARTUP_CMD = /home/dmdba/dmdbms/bin/DmServiceSMS03 start
RLOG_SEND_THRESHOLD = 0
RLOG_APPLY_THRESHOLD = 0

4.5 启动新增备库

以 Mount 方式启动备库

[dmdba@dmdb:/home/dmdba/dmdbms/bin]$ ./dmserver /dmdata/SMS/dm.ini
file dm.key not found, use default license!
version info: develop
DM Database Server 64 V8 03134284094-20240130-217076-20067 startup...
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
Database mode = 1, oguid = 26180
License will expire in 14 day(s) on 2026-07-29
file lsn: 43025
ndct db load finished, code:0
ndct second level fill fast pool finished
ndct third level fill fast pool finished
ndct second level fill fast pool finished
ndct third level fill fast pool finished
ndct fill fast pool finished
nsvr_startup end.
uthr_pipe_create, create pipe[read:19, write:20]
uthr_pipe_create, create pipe[read:21, write:22]
aud sys init success.
aud rt sys init success.
systables desc init success.
ndct_db_load_info finished, code:0.
SYSTEM IS READY.

然后另开窗口，配置 OGUID 和数据库模式（由于是利用主库的备份进行还原的所以需要修改为STANDBY）

[dmdba@dmdb:/home/dmdba]$ ds

服务器[LOCALHOST:5236]:处于主库配置状态
登录使用时间 : 4.273(ms)
disql V8
SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);
DMSQL 过程已成功完成
已用时间: 12.450(毫秒). 执行号:1.
SQL> SP_SET_OGUID(26180);
DMSQL 过程已成功完成
已用时间: 12.362(毫秒). 执行号:2.
SQL> ALTER DATABASE STANDBY;
操作已执行
已用时间: 12.647(毫秒). 执行号:0.
SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
DMSQL 过程已成功完成
已用时间: 9.635(毫秒). 执行号:5.
SQL> exit

修改后回到Mount启动的窗口Ctrl+C关闭即可。

4.6 动态添加MAL配置

需要分别连接原集群中每个实例单独执行，动态增加 MAL 中 SMS03 的相关配置信息。执行如下SQL：

SF_MAL_CONFIG(1,0);

SF_MAL_INST_ADD('MAL_INST3','SMS03','192.168.182.144',5246,'192.168.182.144',5236,5256,0,5266);

SF_MAL_CONFIG_APPLY();

SF_MAL_CONFIG(0,0);

#SF_MAL_INST_ADD中各个参数对应的就是写到dmmal.ini配置文件中的参数,如下
  MAL_HOST              = 192.168.182.144
  MAL_PORT              = 5246
  MAL_INST_HOST         = 192.168.182.144
  MAL_INST_PORT         = 5236
  MAL_DW_PORT           = 5256
  MAL_LINK_MAGIC        = 0
  MAL_INST_DW_PORT      = 5266

主库

[dmdba@dmdb:/dmdata/SMS]$ ds

服务器[LOCALHOST:5236]:处于主库打开状态
登录使用时间 : 4.305(ms)
disql V8
SQL> SF_MAL_CONFIG(1,0);
DMSQL 过程已成功完成
已用时间: 11.409(毫秒). 执行号:1201.
SQL> SF_MAL_INST_ADD('MAL_INST3','SMS03','192.168.182.144',5246,'192.168.182.144',5236,5256,0,5266);
DMSQL 过程已成功完成
已用时间: 1.258(毫秒). 执行号:1202.
SQL> SF_MAL_CONFIG_APPLY();
DMSQL 过程已成功完成
已用时间: 0.659(毫秒). 执行号:1203.
SQL> SF_MAL_CONFIG(0,0);
DMSQL 过程已成功完成
已用时间: 0.567(毫秒). 执行号:1204.
SQL> exit

备库

[dmdba@dmdb:/home/dmdba]$ ds

服务器[LOCALHOST:5236]:处于备库打开状态
登录使用时间 : 6.455(ms)
disql V8
SQL> SF_MAL_CONFIG(1,0);
DMSQL 过程已成功完成
已用时间: 0.685(毫秒). 执行号:401.
SQL> SF_MAL_INST_ADD('MAL_INST3','SMS03','192.168.182.144',5246,'192.168.182.144',5236,5256,0,5266);
DMSQL 过程已成功完成
已用时间: 0.968(毫秒). 执行号:402.
SQL> SF_MAL_CONFIG_APPLY();
DMSQL 过程已成功完成
已用时间: 0.753(毫秒). 执行号:403.
SQL> SF_MAL_CONFIG(0,0);
DMSQL 过程已成功完成
已用时间: 0.862(毫秒). 执行号:404.
SQL> exit

4.7 动态添加归档配置

动态添加归档配置步骤如下：

4.7.1 关闭原系统中所有实例的守护进程和监视器

动态添加归档要求数据库处于 MOUNT 状态，守护进程处于活动状态下不允许用户手动修改模式状态，因此需要先关闭守护进程，同时也是为了防止手动切换 MOUNT 状态后又被守护进程通知自动 Open，另外监视器配置也需要修改，因此在这里一并关闭。
关闭顺序为：

关闭监视器
关闭备库守护进程
关闭主库守护进程

1）关闭监视器

[dmdba@dmdb:/home/dmdba]$ DmMonitorServiceGRP1 stop
Stopping DmMonitorServiceGRP1:                             [ OK ]

2）关闭备库守护进程

[dmdba@dmdb:/home/dmdba]$ DmWatcherServiceSMS02 stop
Stopping DmWatcherServiceSMS02:                            [ OK ]

3）关闭主库守护进程

[dmdba@dmdb:/home/dmdba]$ DmWatcherServiceSMS01 stop
Stopping DmWatcherServiceSMS01:                            [ OK ]

4.7.2 手动修改原系统中所有实例为MOUNT状态

[必须先修改主库，再修改备库]，否则可能会引发主备数据同步失败导致主库挂起。

//临时修改 ALTER_MODE_STATUS，允许用户手动修改模式状态，动态添加完毕后需要再改回原值 

SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);

//临时关闭守护进程活动状态检测，允许用户手动修改模式状态，动态添加完毕后需要再改回原值 

SQL> SP_SET_PARA_VALUE(1, 'DW_INACTIVE_INTERVAL', 0);

//修改数据库为 MOUNT 状态 

SQL> ALTER DATABASE MOUNT;

4.7.3 动态添加归档节点

分别连接原系统中的所有实例，动态添加 dmarch.ini 中归档节点。[注意实例名]

SQL> ALTER DATABASE ADD ARCHIVELOG 'DEST= SMS03, TYPE= REALTIME';

4.7.4 手动修改原系统中所有实例为OPEN状态

[必须先修改备库，再修改主库]，否则可能会引发主备数据同步失败导致主库挂起。

//修改数据库为 OPEN 状态 

SQL> ALTER DATABASE OPEN FORCE;

//将 ALTER_MODE_STATUS 改回原值 

SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);

//将 DW_INACTIVE_INTERVAL 改回原值，本例中为 60 

SQL> SP_SET_PARA_VALUE(1, 'DW_INACTIVE_INTERVAL', 60);

4.7.2~4.7.4 步骤合并记录如下

[一定要注意顺序，先 MOUNT 主库，先 OPEN 备库]

主库

[dmdba@dmdb:/home/dmdba]$ ds

服务器[LOCALHOST:5236]:处于主库打开状态
登录使用时间 : 4.011(ms)
disql V8
SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);
DMSQL 过程已成功完成
已用时间: 11.017(毫秒). 执行号:1301.
SQL> SP_SET_PARA_VALUE(1, 'DW_INACTIVE_INTERVAL', 0);
DMSQL 过程已成功完成
已用时间: 11.529(毫秒). 执行号:1302.
SQL> ALTER DATABASE MOUNT;
操作已执行
已用时间: 5.370(毫秒). 执行号:0.
SQL> ALTER DATABASE ADD ARCHIVELOG 'DEST= SMS03, TYPE= REALTIME';
操作已执行
已用时间: 9.766(毫秒). 执行号:0.
SQL> ALTER DATABASE OPEN FORCE;
操作已执行
已用时间: 8.104(毫秒). 执行号:0.
SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
DMSQL 过程已成功完成
已用时间: 16.105(毫秒). 执行号:1303.
SQL> SP_SET_PARA_VALUE(1, 'DW_INACTIVE_INTERVAL', 60);
DMSQL 过程已成功完成
已用时间: 16.866(毫秒). 执行号:1304.
SQL> EXIT

备库

[dmdba@dmdb:/home/dmdba]$ ds

服务器[LOCALHOST:5236]:处于备库打开状态
登录使用时间 : 4.151(ms)
disql V8
SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);
DMSQL 过程已成功完成
已用时间: 10.506(毫秒). 执行号:501.
SQL> SP_SET_PARA_VALUE(1, 'DW_INACTIVE_INTERVAL', 0);
DMSQL 过程已成功完成
已用时间: 11.206(毫秒). 执行号:502.
SQL> ALTER DATABASE MOUNT;
操作已执行
已用时间: 7.479(毫秒). 执行号:0.
SQL> ALTER DATABASE ADD ARCHIVELOG 'DEST= SMS03, TYPE= REALTIME';
操作已执行
已用时间: 2.995(毫秒). 执行号:0.
SQL> ALTER DATABASE OPEN FORCE;
操作已执行
已用时间: 8.887(毫秒). 执行号:0.
SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
DMSQL 过程已成功完成
已用时间: 10.956(毫秒). 执行号:503.
SQL> SP_SET_PARA_VALUE(1, 'DW_INACTIVE_INTERVAL', 60);
DMSQL 过程已成功完成
已用时间: 11.036(毫秒). 执行号:504.
SQL> EXIT

4.8 修改监视器配置文件

修改监视器配置文件 dmmonitor.ini 和 dmmonitor_noc.ini[所有节点]
添加上新增节点

MON_DW_IP = 192.168.182.144:5256

4.9 启动所有守护进程以及监视器

1）启动主库守护进程

[dmdba@dmdb:/dmdata/SMS]$ DmWatcherServiceSMS01 start
Starting DmWatcherServiceSMS01:                            [ OK ]

2）启动备库守护进程

[dmdba@dmdb:/home/dmdba]$ DmWatcherServiceSMS02 start
Starting DmWatcherServiceSMS02:                            [ OK ]

3）启动新增备库守护进程

#注册服务
[root@dmdb:/root/dmsoft/DMDB_INSTALL_SCRIPTS]# /home/dmdba/dmdbms/script/root/dm_service_installer.sh -t dmwatcher -p SMS03 -watcher_ini /dmdata/SMS/dmwatcher.ini
Created symlink /etc/systemd/system/multi-user.target.wants/DmWatcherServiceSMS03.service → /usr/lib/systemd/system/DmWatcherServiceSMS03.service.
创建服务(DmWatcherServiceSMS03)完成
#启动服务
[root@dmdb:/root/dmsoft/DMDB_INSTALL_SCRIPTS]# su - dmdba
[dmdba@dmdb:/home/dmdba]$ DmWatcherServiceSMS03 start
Starting DmWatcherServiceSMS03:                            [ OK ]

4）启动监视器[任一备库启动]

先启动前台监视器查看集群状态

[dmdba@dmdb:/dmdata/SMS]$ dmmonitor /dmdata/SMS/dmmonitor_noc.ini

示例：

[dmdba@dmdb:/dmdata/SMS]$ dmmonitor dmmonitor_noc.ini 
[monitor]         2026-07-15 17:07:30: DMMONITOR[4.0] V8
[monitor]         2026-07-15 17:07:30: DMMONITOR[4.0] IS READY.

[monitor]         2026-07-15 17:07:31: 
#--------------------------------------------------------------------------------#
GET MONITOR CONNECT INFO FROM DMWATCHER(SMS03), THE FIRST LINE IS SELF INFO.

DW_CONN_TIME         MON_CONFIRM    MID            MON_IP                   MON_VERSION                                                     
2026-07-15 17:07:31  FALSE          1670925496     ::ffff:192.168.182.143   DMMONITOR[4.0] V8
                                              
#--------------------------------------------------------------------------------#

[monitor]         2026-07-15 17:07:31: 收到守护进程(SMS03)消息
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN            CLSN            
                  2026-07-15 17:07:31  OPEN           OK        SMS03            OPEN        STANDBY   NULL     2        43191           43191           

[monitor]         2026-07-15 17:07:31: 收到守护进程(SMS02)消息
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN            CLSN            
                  2026-07-15 17:07:31  OPEN           OK        SMS02            OPEN        STANDBY   NULL     2        43191           43191           

[monitor]         2026-07-15 17:07:31: 收到守护进程(SMS01)消息
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN            CLSN            
                  2026-07-15 17:07:31  OPEN           OK        SMS01            OPEN        PRIMARY   VALID    2        43191           43191           

show
2026-07-15 17:07:32 
#================================================================================#
GROUP            OGUID       MON_CONFIRM     MODE            MPP_FLAG  
GRP1             26180       FALSE           AUTO            FALSE     


<>
DW_IP            MAL_DW_PORT  WTIME                WTYPE     WCTLSTAT  WSTATUS        INAME            INST_OK   N_EP  N_OK  ISTATUS     IMODE     DSC_STATUS     RTYPE     RSTAT    
192.168.182.142  5256         2026-07-15 17:07:32  GLOBAL    VALID     OPEN           SMS01            OK        1     1     OPEN        PRIMARY   DSC_OPEN       REALTIME  VALID    

EP INFO:
INST_IP          INST_PORT  INST_OK   INAME            ISTATUS     IMODE     DSC_SEQNO  DSC_CTL_NODE RTYPE     RSTAT       FSEQ            FLSN            CSEQ            CLSN            DW_STAT_FLAG          
192.168.182.142  5236       OK        SMS01            OPEN        PRIMARY   0          0            REALTIME  VALID       5090            43191           5090            43191           NONE                  

<>
DW_IP            MAL_DW_PORT  WTIME                WTYPE     WCTLSTAT  WSTATUS        INAME            INST_OK   N_EP  N_OK  ISTATUS     IMODE     DSC_STATUS     RTYPE     RSTAT    
192.168.182.143  5256         2026-07-15 17:07:32  GLOBAL    VALID     OPEN           SMS02            OK        1     1     OPEN        STANDBY   DSC_OPEN       REALTIME  VALID    

EP INFO:
INST_IP          INST_PORT  INST_OK   INAME            ISTATUS     IMODE     DSC_SEQNO  DSC_CTL_NODE RTYPE     RSTAT       FSEQ            FLSN            CSEQ            CLSN            DW_STAT_FLAG          
192.168.182.143  5236       OK        SMS02            OPEN        STANDBY   0          0            REALTIME  VALID       5090            43191           5090            43191           NONE                  

DATABASE(SMS02) APPLY INFO FROM (SMS01), REDOS_PARALLEL_NUM (4), WAIT_APPLY[FALSE]:
DSC_SEQNO[0], (RSEQ, SSEQ, KSEQ)[5090, 5090, 5090], (RLSN, SLSN, KLSN)[43191, 43191, 43191], N_TSK[0], TSK_MEM_USE[0] 
REDO_LSN_ARR: (43191, 43191, 43191, 43191)


<>
DW_IP            MAL_DW_PORT  WTIME                WTYPE     WCTLSTAT  WSTATUS        INAME            INST_OK   N_EP  N_OK  ISTATUS     IMODE     DSC_STATUS     RTYPE     RSTAT    
192.168.182.144  5256         2026-07-15 17:07:32  GLOBAL    VALID     OPEN           SMS03            OK        1     1     OPEN        STANDBY   DSC_OPEN       REALTIME  VALID    

EP INFO:
INST_IP          INST_PORT  INST_OK   INAME            ISTATUS     IMODE     DSC_SEQNO  DSC_CTL_NODE RTYPE     RSTAT       FSEQ            FLSN            CSEQ            CLSN            DW_STAT_FLAG          
192.168.182.144  5236       OK        SMS03            OPEN        STANDBY   0          0            REALTIME  VALID       5090            43191           5090            43191           NONE                  

DATABASE(SMS03) APPLY INFO FROM (SMS01), REDOS_PARALLEL_NUM (4), WAIT_APPLY[FALSE]:
DSC_SEQNO[0], (RSEQ, SSEQ, KSEQ)[5090, 5090, 5090], (RLSN, SLSN, KLSN)[43191, 43191, 43191], N_TSK[0], TSK_MEM_USE[0] 
REDO_LSN_ARR: (43191, 43191, 43191, 43191)


#================================================================================#

show global info
2026-07-15 17:07:37 
#================================================================================#
GROUP            OGUID       MON_CONFIRM     MODE            MPP_FLAG  
GRP1             26180       FALSE           AUTO            FALSE     


<>
DW_IP            MAL_DW_PORT  WTIME                WTYPE     WCTLSTAT  WSTATUS        INAME            INST_OK   N_EP  N_OK  ISTATUS     IMODE     DSC_STATUS     RTYPE     RSTAT    
192.168.182.142  5256         2026-07-15 17:07:37  GLOBAL    VALID     OPEN           SMS01            OK        1     1     OPEN        PRIMARY   DSC_OPEN       REALTIME  VALID    

DW_IP            MAL_DW_PORT  WTIME                WTYPE     WCTLSTAT  WSTATUS        INAME            INST_OK   N_EP  N_OK  ISTATUS     IMODE     DSC_STATUS     RTYPE     RSTAT    
192.168.182.143  5256         2026-07-15 17:07:37  GLOBAL    VALID     OPEN           SMS02            OK        1     1     OPEN        STANDBY   DSC_OPEN       REALTIME  VALID    

DW_IP            MAL_DW_PORT  WTIME                WTYPE     WCTLSTAT  WSTATUS        INAME            INST_OK   N_EP  N_OK  ISTATUS     IMODE     DSC_STATUS     RTYPE     RSTAT    
192.168.182.144  5256         2026-07-15 17:07:37  GLOBAL    VALID     OPEN           SMS03            OK        1     1     OPEN        STANDBY   DSC_OPEN       REALTIME  VALID    


#================================================================================#

choose switchover
Can choose one of the following instances to do switchover:
1: SMS02
2: SMS03

通过监视器可以看到新节点144，并且状态正常，通过choose switchover可以看到两备库节点，说明集群状态没有问题

确认集群状态正常后，启动监视器后台服务

[dmdba@dmdb:/home/dmdba]$ DmMonitorServiceGRP1 start
Starting DmMonitorServiceGRP1:                             [ OK ]

遗留问题，多出来的参数配置有没有什么影响？

dmmal.ini

[dmdba@dmdb:/dmdata/SMS]$ cat dmmal.ini 
#DaMeng Database Mail Configuration file
#this is comments
MAL_CHECK_INTERVAL     = 5
MAL_COMBIN_BUF_SIZE    = 0
MAL_SEND_THRESHOLD = 2048
MAL_CONN_FAIL_INTERVAL = 5
MAL_LOGIN_TIMEOUT      = 15
MAL_BUF_SIZE           = 100
MAL_SYS_BUF_SIZE       = 0
MAL_VPOOL_SIZE         = 128
MAL_COMPRESS_LEVEL     = 0
MAL_TEMP_PATH          = 

[MAL_INST1]
    MAL_INST_NAME    = SMS01
    MAL_HOST         = 192.168.182.142
    MAL_PORT         = 5246
    MAL_INST_HOST    = 192.168.182.142
    MAL_INST_PORT    = 5236
    MAL_DW_PORT      = 5256
    MAL_LINK_MAGIC   = 0
    MAL_INST_DW_PORT = 5266

[MAL_INST2]
    MAL_INST_NAME    = SMS02
    MAL_HOST         = 192.168.182.143
    MAL_PORT         = 5246
    MAL_INST_HOST    = 192.168.182.143
    MAL_INST_PORT    = 5236
    MAL_DW_PORT      = 5256
    MAL_LINK_MAGIC   = 0
    MAL_INST_DW_PORT = 5266

[MAL_INST3]
    MAL_INST_NAME    = SMS03
    MAL_HOST         = 192.168.182.144
    MAL_PORT         = 5246
    MAL_INST_HOST    = 192.168.182.144
    MAL_INST_PORT    = 5236
    MAL_DW_PORT      = 5256
    MAL_LINK_MAGIC   = 0
    MAL_INST_DW_PORT = 5266

dmarch.ini

[dmdba@dmdb:/dmdata/SMS]$ cat dmarch.ini 
#DaMeng Database Archive Configuration file
#this is comments

	ARCH_WAIT_APPLY      = 0        

[ARCHIVE_LOCAL]
	ARCH_TYPE            = LOCAL        
	ARCH_DEST            = /dmarch        
	ARCH_FILE_SIZE       = 1024        
	ARCH_SPACE_LIMIT     = 3072        
	ARCH_FLUSH_BUF_SIZE  = 0        
	ARCH_HANG_FLAG       = 1        

[ARCHIVE_REALTIME1]
	ARCH_TYPE            = REALTIME        
	ARCH_DEST            = SMS02        

	WAIT_APPLY           = 0        
	ARCH_FAILOVER        = 0        

[ARCHIVE_REALTIME2]
	ARCH_TYPE            = REALTIME        
	ARCH_DEST            = SMS03        

	WAIT_APPLY           = 0        
	ARCH_FAILOVER        = 0

达梦数据库SQL报错之远程操作符执行失败

shine — Thu, 18 Jun 2026 05:58:54 +0000

一、问题描述

1.1 现象概述

在达梦数据库环境中，执行两条结构相似但写法不同的SQL查询语句，出现截然不同的执行结果：

SQL1（子查询方式）：执行成功，返回1条结果集。
SQL2（LEFT JOIN方式）：执行失败，报错信息为：

-7158: 远程操作符失败,错误详情[ORA-00942: table or view does not exist]，如图

但在执行如下等价SQL的时候却没有报错

1.2 执行环境

版本：8.1.3.62 Pack31

涉及链接：@wind(数据库链接/DBLINK)

本地表：ibrpa.IB_URBAN_INVESTMENT_COMPANIES

远程表：wind.COMPINTRODUCTION @wind

1.3 SQL语句详情

SQL1（执行成功）：

SELECT 
    ci.COMP_ID,
    ci.COMP_NAME,
    ci.PROVINCE,
    ci.CITY,
    ci.COMP_PROPERTY,
    ci.REGCAPITAL,
    ci.SOCIAL_CREDIT_CODE,
    CASE 
        WHEN EXISTS (
            SELECT 1 
            FROM ibrpa.IB_URBAN_INVESTMENT_COMPANIES uic 
            WHERE uic.UNIFIED_SOCIAL_CREDIT_CODE = ci.SOCIAL_CREDIT_CODE
        ) THEN '是'
        ELSE '否'
    END AS IS_URBAN_INVESTMENT
FROM 
    wind.COMPINTRODUCTION @wind ci
WHERE 
    ci.COMP_ID = '1HMD2829D5';

SQL2（执行失败）：

SELECT 
    ci.COMP_ID,
    ci.COMP_NAME,
    ci.PROVINCE,
    ci.CITY,
    ci.COMP_PROPERTY,
    ci.REGCAPITAL,
    ci.SOCIAL_CREDIT_CODE
FROM
    wind.COMPINTRODUCTION @wind ci
    LEFT JOIN ibrpa.IB_URBAN_INVESTMENT_COMPANIES uic ON uic.UNIFIED_SOCIAL_CREDIT_CODE = ci.SOCIAL_CREDIT_CODE
WHERE
    ci.COMP_ID = '1HMD2829D5';

二、问题分析

2.1 根本原因分析

两条SQL的核心差异在于跨库关联的实现方式：

根本原因：达梦数据库的DBLINK优化器在处理LEFT JOIN时，为提升性能，尝试将整个查询下推到远程数据库（wind库）执行。但远程库并不存在本地表ibrpa.IB_URBAN_INVESTMENT_COMPANIES，因此触发ORA-00942错误（表或视图不存在）。

2.2 参数`DBLINK_OPT_FLAG`分析

DBLINK_OPT_FLAG是达梦数据库控制DBLINK优化策略的核心参数，其值采用位标志方式组合。

当前参数值：509

509的二进制分解：

509 = 256 + 128 + 64 + 32 + 16 + 8 + 4 + 1

核心问题位：导致SQL2报错的关键组合是位4（新局部优化）和位256（计划生成阶段连接变量优化）的协同作用。当这两个特性同时启用时，优化器会将LEFT JOIN整体推送到远程执行，从而引发报错。

三、解决方案

3.1 方案一：使用HINT调整DBLINK_OPT_FLAG（推荐）

达梦数据库支持通过优化器提示（HINT）在单条SQL语句中动态设置DBLINK_OPT_FLAG，而无需修改全局或会话参数。这种方式影响范围最小、最为精准。

SELECT /*+ DBLINK_OPT_FLAG(4) */
    ci.COMP_ID,
    ci.COMP_NAME,
    ci.PROVINCE,
    ci.CITY,
    ci.COMP_PROPERTY,
    ci.REGCAPITAL,
    ci.SOCIAL_CREDIT_CODE
FROM
    wind.COMPINTRODUCTION @wind ci
    LEFT JOIN ibrpa.IB_URBAN_INVESTMENT_COMPANIES uic 
        ON uic.UNIFIED_SOCIAL_CREDIT_CODE = ci.SOCIAL_CREDIT_CODE
WHERE
    ci.COMP_ID = '1HMD2829D5';

经实际验证，推荐优先使用 4，其效果优于 0 或 1。

3.2 方案二：改写SQL（稳妥）

如无法使用HINT或HINT无效，可通过改写SQL从根本上规避问题。

使用WITH CTE物化本地数据

WITH LOCAL_DATA AS (
    SELECT UNIFIED_SOCIAL_CREDIT_CODE 
    FROM ibrpa.IB_URBAN_INVESTMENT_COMPANIES
)
SELECT 
    ci.COMP_ID,
    ci.COMP_NAME,
    ci.PROVINCE,
    ci.CITY,
    ci.COMP_PROPERTY,
    ci.REGCAPITAL,
    ci.SOCIAL_CREDIT_CODE,
    CASE 
        WHEN ld.UNIFIED_SOCIAL_CREDIT_CODE IS NOT NULL THEN '是'
        ELSE '否'
    END AS IS_URBAN_INVESTMENT
FROM
    wind.COMPINTRODUCTION @wind ci
    LEFT JOIN LOCAL_DATA ld 
        ON ld.UNIFIED_SOCIAL_CREDIT_CODE = ci.SOCIAL_CREDIT_CODE
WHERE
    ci.COMP_ID = '1HMD2829D5';

方案原理：CTE LOCAL_DATA 在本地（ibrpa库）独立执行，将本地表数据提取到临时结果集。主查询中的LEFT JOIN关联的是本地临时结果集，而非直接跨库关联远程表。优化器不再将整个查询下推到远程库，从而避免报错。

四、问题总结

问题本质：达梦数据库DBLINK优化器在特定参数组合（位4+位256）下，错误地将跨库LEFT JOIN查询下推到远程数据库执行，导致远程库访问本地表失败。
最佳实践：
- 使用 /*+ DBLINK_OPT_FLAG(4) */ HINT是解决此问题的首选方式，已验证可行且性能优于0和1。
- 该HINT精准关闭了引发错误的优化位，同时保留了新局部优化能力，达到最佳平衡。
兜底方案：如需完全不依赖系统参数，可采用WITH CTE方式改写SQL，同样能稳定解决问题。

达梦数据库的审计功能

shine — Wed, 20 May 2026 06:04:33 +0000

在日常数据库运维中，有时候我们需要追溯到某个数据变更的来源：是谁在什么时间、从哪个客户端执行了什么操作？在没有审计的情况下，这类问题往往难以回答。达梦数据库内置了一套灵活且完善的审计子系统，本文将从设计理念出发，结合实例演示，带你全面掌握达梦审计的使用方法。

一、审计的价值

数据库审计的核心价值体现在三个层面：

合规要求：诸多行业法规明确要求对核心业务数据库开启审计，如涉及薪资、财务等敏感数据的场景；
安全监控：通过审计记录发现异常的数据库访问行为和潜在入侵；
事件追溯：当数据被误删或恶意篡改时，能够快速定位责任人及操作细节。

注意：审计功能会消耗数据库服务器资源，对性能有一定影响，需根据现场实际情况制定合理的审计规则，避免过度审计。

二、审计的设计

DM8 的审计子系统采用了分层设计思想，将审计功能划分为三个关键层级：系统级、语句级和对象级。这种分层设计实现了审计粒度的灵活控制，同时大幅降低了审计功能对数据库性能的影响。

其核心设计原则包括：

最小权限原则：审计功能由独立的 SYSAUDITOR 账户管理，与常规 DBA 权限分离；
实时性与完整性平衡：通过刷盘策略确保审计记录不丢失；
性能优化设计：采用内存缓冲机制减少 I/O 开销；
安全存储保障：审计文件加密和空间管理策略防止审计记录被篡改。

三、三权分立与审计员的角色

达梦数据库采用“三权分立”的安全机制，系统内置三类管理员账户，各司其职、互相制约：

数据库管理员：SYSDBA，系统运维、备份恢复、用户创建
数据库安全员：SYSSSO，安全策略制定、权限分配
数据库审计员：SYSAUDITOR，审计配置、审计记录分析

只有数据库审计员才能进行审计操作，数据库管理员和安全员均不能参与审计活动。这一设计有效避免了权限集中于一人所带来的风险，保证了系统的安全性。

四、审计开关

在达梦系统中，审计功能默认关闭，需要由审计员显式开启。审计开关由系统过程 SP_SET_ENABLE_AUDIT 控制，执行后立即生效。

参数取值：

0：关闭审计（缺省值）
1：打开普通审计
2：打开普通审计和实时审计

开启审计（需使用 SYSAUDITOR 用户登录）：

-- DM8 开启普通审计
SP_SET_ENABLE_AUDIT(1);

-- 查询审计开关当前状态
SELECT * FROM V$DM_INI WHERE PARA_NAME='ENABLE_AUDIT';

当参数值设为 2 时，还将开启实时审计功能。实时审计能够对当前用户的操作进行实时分析，匹配预设的侵害检测规则，确定侵害等级并采取相应的响应措施。

五、三层审计体系详解

5.1 系统级审计：自动生效的全局监控

系统级审计记录的是数据库的启动关闭、版本升级、审计空间不足告警等系统事件。此级别的审计无法也无需由用户设置，只要审计开关打开，就会自动生成对应的审计记录。

系统级审计的典型记录内容包括：

数据库系统启动关闭（区分正常退出后启动、异常退出后启动等）；
审计空间不足告警；
数据库版本升级；
主备之间 redo 日志传输故障及恢复。

5.2 语句级审计：按 SQL 类型精准捕获

语句级审计针对的是影响特定类型数据库对象的 SQL 语句组，是一种粗粒度的审计方式。例如，AUDIT TABLE 将审计 CREATE TABLE、ALTER TABLE 和 DROP TABLE 等所有表相关的操作。

设置语法：

SP_AUDIT_STMT(TYPE VARCHAR(30), USERNAME VARCHAR(128), WHENEVER VARCHAR(20))

参数说明：

TYPE：审计选项，如 TABLE、USER、CONNECT、UPDATE TABLE 等
USERNAME：用户名，NULL 表示不限制
WHENEVER：审计时机：ALL（全部）、SUCCESSFUL（成功时）、FAIL（失败时）

实用示例：

-- 1. 审计所有用户的登录行为（无论成功或失败）
SP_AUDIT_STMT('CONNECT', 'NULL', 'ALL');

-- 2. 审计所有表结构变更操作
SP_AUDIT_STMT('TABLE', 'NULL', 'ALL');

-- 3. 审计 USER2 用户的所有表修改和删除操作
SP_AUDIT_STMT('UPDATE TABLE', 'USER2', 'ALL');
SP_AUDIT_STMT('DELETE TABLE', 'USER2', 'ALL');

-- 4. 审计 SYSDBA 创建用户成功的操作
SP_AUDIT_STMT('USER', 'SYSDBA', 'SUCCESSFUL');

TYPE审计选项可查阅手册《DM8安全管理》或直接访问官网对应部分：DM8安全管理-语句级审计。

取消语句级审计（参数必须与设置时完全一致）：

SP_NOAUDIT_STMT('TABLE', 'NULL', 'ALL');

5.3 对象级审计：精细到表、视图乃至列级别

对象级审计是细粒度的审计方式，可以对某张具体表、某个视图甚至某一列上的特定操作进行审计。

设置语法：

SP_AUDIT_OBJECT(
    TYPE       VARCHAR(30),   -- 操作类型：INSERT、UPDATE、DELETE、SELECT、ALL 等
    USERNAME   VARCHAR(128),  -- 用户名，NULL 表示不限制
    SCHNAME    VARCHAR(128),  -- 模式名，空时置 'null'
    TVNAME     VARCHAR(128),  -- 表名/视图名/存储过程名，不能为空
    COLNAME    VARCHAR(128),  -- 列名（可选）
    WHENEVER   VARCHAR(20)    -- 审计时机
)

实用示例：

-- 1. 审计所有用户对 PERSON.ADDRESS 表的 INSERT 和 UPDATE 成功操作
SP_AUDIT_OBJECT('INSERT', 'SYSDBA', 'PERSON', 'ADDRESS', 'SUCCESSFUL');
SP_AUDIT_OBJECT('UPDATE', 'SYSDBA', 'PERSON', 'ADDRESS', 'SUCCESSFUL');

-- 2. 审计 DMTEST 模式下 TEST 表的所有 DML 操作
SP_AUDIT_OBJECT('ALL', 'NULL', 'DMTEST', 'TEST', 'ALL');

-- 3. 审计对特定表 T1 的删除操作
SP_AUDIT_OBJECT('DELETE', 'NULL', 'TEST', 'T1', 'SUCCESSFUL');

取消对象级审计（参数必须与设置时完全一致）：

SP_NOAUDIT_OBJECT('INSERT', 'SYSDBA', 'PERSON', 'ADDRESS', 'SUCCESSFUL');

审计配置的规则存储在数据字典表 SYSAUDITOR.SYSAUDIT 中，可通过以下语句查看当前所有审计设置：

SELECT * FROM SYSAUDITOR.SYSAUDIT;

六、审计记录的查看与分析

达梦提供了两种方式查看审计记录。

6.1 动态视图查询（推荐日常使用）

-- 查询所有审计记录
SELECT * FROM SYSAUDITOR.V$AUDITRECORDS;

-- 按用户和操作类型筛选
SELECT USERNAME, OPERATION, SQL_TEXT, OPTIME 
FROM SYSAUDITOR.V$AUDITRECORDS 
WHERE SCHNAME = 'TEST' AND OBJNAME = 'T1';

V$AUDITRECORDS 视图中记录了用户 ID、用户名、IP 地址、操作时间、SQL 文本等关键信息。

6.2 DM 审计分析工具（Analyzer）

达梦还提供了图形化的审计分析工具，位于安装目录的 tool 子目录下：

使用 SYSAUDITOR 用户登录后，双击“审计日志查看器”，选择审计日志文件即可进行筛选、排序等分析操作。

6.3 审计文件的存放位置

计文件默认存放在数据库的 SYSTEM_PATH 指定的路径下（即数据库所在路径）。也可以通过配置 AUD_PATH 参数将其指定到独立的存储磁盘上，以避免与数据文件抢占空间。

七、审计文件的空间管理

随着数据库运行，审计记录会不断增长，必须做好空间管理。达梦提供了几个关键的 INI 参数：

AUDIT_SPACE_LIMIT：审计文件总存储空间上限，缺省值8192，单位MB。
AUDIT_MAX_FILE_SIZE：单个审计文件大小上限，缺省值100，单位MB。

当单个审计文件超过指定大小时，系统会自动创建新的审计文件，审计记录将写入新文件中。

7.1 空间满的处理策略

通过 AUDIT_FILE_FULL_MODE 参数配置空间不足时的处理策略：

1：审计文件创建失败，卡住
2：审计文件创建失败，不再审计
3：结合 1 和 2，先尝试删老审计文件，再创建审计文件，失败则不再审计

7.2 审计文件的清理

可使用系统过程手动清理过期的审计文件：

-- 删除 2025-01-01 之前的审计文件
SP_DROP_AUDIT_FILE('2025-01-01 00:00:00', 0);

-- 删除所有旧的审计文件（保留当前正在使用的）
SP_DROP_AUDIT_FILE(SYSDATE, 0);

TIME_STR：指定的时间字符串
TYPE：审计文件类型，0 表示删除普通审计文件，1 表示删除实时审计文件

注意：不要在操作系统层面直接删除审计文件，否则需重启数据库才能恢复审计功能。

八、审计刷盘策略：性能与安全的平衡

达梦提供了三种审计记录的刷盘模式，由动态参数 AUDIT_FLUSH_LEVEL 控制：

0：语句级刷盘，一条语句执行结束进行一次审计记录刷盘操作；
1：事务级刷盘，一个事务执行结束执行一次审计日志刷盘操作；
2：延迟刷盘，审计记录缓存满时（缓存大小固定为8MB）自动刷盘

对于高并发场景，建议设置为 1 或 2，在性能和安全之间取得平衡。

九、最佳实践与注意事项

按需审计，避免全开：只对核心业务表和敏感操作配置审计，避免审计日志过快膨胀影响数据库性能。
独立存储审计文件：建议通过 AUD_PATH 参数将审计文件存放到独立磁盘，既能保证写入性能，也能防止审计文件占用数据磁盘空间。
定期清理过期日志：结合系统过程 SP_DROP_AUDIT_FILE 或定时脚本，保留 30 天左右的审计记录即可，避免磁盘空间被撑满。
高安全场景开启实时审计：对于安全要求极高的环境（如金融核心系统），可以将审计开关设置为 2，同时开启实时审计的侵害检测功能。
严格区分管理角色：坚持使用 SYSAUDITOR 进行审计操作，SYSDBA 和 SYSSSO 不应参与审计活动，确保三权分立机制的有效性。
定期备份审计记录：审计记录本身也是重要的合规证据，建议纳入数据库备份策略中。

十、总结

达梦数据库的审计功能通过系统级、语句级、对象级三层架构，实现了从宏观系统事件到微观列级操作的全面审计覆盖。配合三权分立的安全机制和灵活的空间管理策略，能够满足各类合规场景下的审计需求。

在实际使用中，关键是要根据业务场景制定合理的审计策略：核心数据表开启对象级审计以精确追溯，敏感操作开启语句级审计以全面监控，系统事件则由系统级审计自动记录。审计功能虽是消耗资源的“成本中心”，但一旦发生安全事故或合规审查，审计记录的价值便无可替代——它是数据库安全的最后一道防线。

达梦数据库在同一服务器上配置多个 AP 服务

shine — Tue, 19 May 2026 05:28:05 +0000

一、问题背景

在实际环境中，我们有时需要在同一台服务器上运行两个不同版本的达梦数据库。这时会遇到一个常见问题：默认的 AP 服务（辅助进程）会占用 4236 端口，导致第二个 AP 服务无法启动，进而导致第二个数据库服务的定时备份作业报错：-134 执行码版本不匹配。解决思路很简单——为第二个数据库实例配置另一个的 AP 服务，并指定一个新的端口。下面是具体操作步骤。

二、问题解决

2.1 创建新的 dmap.ini 配置文件

在第二个数据库实例的数据目录下（例如 /data/dmdata/DAMENG/）新建 dmap.ini 文件，并设置一个未被占用的端口号，比如 4237。

# 文件路径：/data/dmdata/DAMENG/dmap.ini
AP_PORT = 4237

2.2 重新注册 AP 服务

使用达梦自带的脚本注册新的 AP 服务，并通过 -dmap_ini 参数明确指定刚才创建的配置文件。这样系统就会根据新端口来启动服务。

# 需要用 root 用户执行
/data/dmdbms/script/root/dm_service_installer.sh -t dmap -dmap_ini /data/dmdata/DAMENG/dmap.ini

2.3 修改数据库参数

登录到第二个数据库实例，执行以下 SQL 语句，将 EXTERNAL_AP_PORT 参数修改为刚才配置的端口 4237。这样数据库在需要进行备份等操作时，就会自动连接到新的 AP 服务。

SP_SET_PARA_VALUE(1, 'EXTERNAL_AP_PORT', 4237);

参数介绍：执行C外部函数或AP备份还原使用的AP的端口号，DMAP的监听端口，监听方配置此参数。

执行后参数立即生效，无需重启数据库。

三、验证与总结

完成上述三步后，第二个 AP 服务就会使用 4237 端口运行，与占用 4236 端口的第一个 AP 服务互不干扰。可以手动执行之前报错的定时作业验证是否可以成功备份。希望这篇小记能帮助遇到同样问题的朋友少走弯路。

达梦数据库中常用的系统视图

shine — Tue, 14 Apr 2026 07:11:36 +0000

提示：可根据名称在《DM8系统管理员手册》中查看视图的详细字段信息，或直接在官网查看：DM8系统管理员手册-附录

一、核心数据字典表

SYSOBJECTS：记录系统中所有对象的信息。

SYSTEXTS：存放字典对象的文本信息。使用时，系统内部临时解析的字典对象才会放入此处。

SYSCOLUMNS：记录系统中所有列定义的信息。

SYSCONS：记录系统中所有约束的信息。

SYSINDEXES：记录系统中所有索引定义信息。

SYSOBJINFOS：记录对象的依赖信息。

SYSUSERS：记录系统中用户信息。

二、Oracle兼容视图 (DBA_/ALL_/USER_)

DBA_SOURCE：查看所有存储对象（函数、存储过程、包等）的源代码。

DBA_OBJECTS：查看数据库中所有对象的详细信息。

DBA_TABLES：查看数据库中所有表（包括系统表）的详细信息。

DBA_TAB_COLUMNS：查看数据库中所有表的列信息。

DBA_CONSTRAINTS：查看数据库中所有表的约束信息。

DBA_INDEXES：查看数据库中所有索引的信息。

DBA_USERS：查看数据库中所有用户的信息。

DBA_TAB_PRIVS：查看授予用户的所有对象权限。

三、动态性能视图 (V$)

V$SESSIONS：查看当前数据库会话信息。

V$LOCK：查看当前锁信息，用于死锁分析与诊断。

V$DATABASE：查看数据库的基本信息和状态。

V$TABLESPACE：查看所有表空间的基本信息。

V$DATAFILE：查看数据文件信息。

V$DM_INI：查看数据库的系统配置参数。

V$RLOGFILE：查看联机重做日志文件信息。

四、用户/模式视图

ALL_USERS：查看所有用户（基本信息）。

五、鲜少使用

5.1 查询依赖关系

SELECT * FROM DBA_DEPENDENCIES WHERE REFERENCED_NAME = 'TABNAME';

5.2 查询库中的确定性函数

SELECT * FROM DBA_SOURCE 
WHERE TYPE = 'PROC' 
AND REGEXP_LIKE(TEXT, 'DETERMINISTIC', 'i') 
ORDER BY OWNER;

5.3 查询库中的HUGE表

（1）查询HUGE表空间

SELECT * FROM SYS."V$HUGE_TABLESPACE";

（2）达梦在创建每一个 HUGE 表时，都会自动创建一个同名的辅助表来管理它的数据。辅助表的命名规则是原表名$AUX，查询辅助表

SELECT * FROM SYSOBJECTS WHERE NAME LIKE '%$AUX';

（3）通过查找$AUX辅助表来定位所有HUGE主表

SELECT
    US.NAME AS 模式名,
    -- 核心逻辑：去掉末尾的$AUX，得到原始HUGE主表名
    SUBSTR(S.NAME, 1, LENGTH(S.NAME) - 4) AS HUGE主表名,
    S.NAME AS 辅助表名
FROM
    SYSOBJECTS S
JOIN
    SYSOBJECTS US ON S.SCHID = US.ID
WHERE
    S.SUBTYPE$ = 'UTAB'        -- 普通用户表
    AND S.NAME LIKE '%$AUX'    -- 过滤出AUX辅助表
    AND US.TYPE$ = 'SCH'       -- 关联模式信息
ORDER BY
    模式名, HUGE主表名;

如果一个 HUGE 表是分区表，其辅助表的名称会是“子表名$AUX”。对于这种情况，上述 SQL 可能无法直接还原出原始的主表名。

（4）查询分区HUGE表

SELECT DISTINCT
    PT.TABLE_OWNER,
    PT.TABLE_NAME,
    T.TABLESPACE_NAME
FROM DBA_TAB_PARTITIONS PT
LEFT JOIN DBA_TABLES T 
    ON PT.TABLE_OWNER = T.OWNER 
    AND PT.TABLE_NAME = T.TABLE_NAME
WHERE T.TABLESPACE_NAME IN (SELECT NAME FROM V$HUGE_TABLESPACE)
ORDER BY PT.TABLE_OWNER, PT.TABLE_NAME;

达梦数据库服务器的磁盘I/O监控指南

shine — Thu, 09 Apr 2026 07:34:44 +0000

一、为什么要监控磁盘 I/O

磁盘 I/O 性能直接影响到达梦数据库的事务响应速度、日志写入效率以及整体吞吐量。监控磁盘 I/O 的目的包括：

保障数据库响应时间：达梦数据库在大量并发写入（如 redo log、数据页刷盘）时，I/O 延迟过大会导致事务等待，降低 TPS。
提前发现瓶颈：通过观察磁盘繁忙度（%util）和平均等待时间（await），可在性能问题影响用户之前进行干预。
容量规划：了解 I/O 增长趋势，决定何时升级存储（如从 HDD 换为 SSD）或拆分数据文件。
验证优化效果：修改达梦参数（如 BUFFER、CKPT_INTERVAL）或更换磁盘调度器后，通过 I/O 指标量化改进。

二、达梦数据库的 I/O 特征

在监控之前，需要了解达梦数据库产生磁盘 I/O 的主要场景：

I/O 类型	说明	典型特征
数据文件读写	查询时读取数据页，DML/DDL 时修改数据页并最终由检查点写回	随机读 + 随机写，读写比例不定
重做日志（redo log）	事务提交时顺序写入 redo 日志，保证持久性	顺序写，延迟敏感，写吞吐量较高
归档日志	日志切换后归档，通常为顺序写	顺序写，可能占用大量带宽
临时表空间	排序、哈希连接等操作使用临时表空间	多为读写混合，可能产生大量 I/O
备份与恢复	使用 dmrman 或 dexp 进行备份/导出	顺序读或写，占用高带宽

三、核心 I/O 指标解读

使用 iostat -x -d -m 1 可以获得以下关键指标。掌握这些指标是分析 I/O 性能的基础。

指标	含义	健康范围参考（针对达梦数据库）
r/s, w/s	每秒读/写请求次数（IOPS）	普通 SAS HDD 约 200~300，SSD 可达 5000+
rMB/s, wMB/s	每秒读/写数据量（吞吐量）	HDD 约 100~200 MB/s，SATA SSD ~500 MB/s
%util	磁盘繁忙度，表示 I/O 请求在时间上的占比。若持续 > 80%，说明磁盘可能成为瓶颈	达梦 OLTP 建议 < 70%；OLAP 可允许短期 100%
await	平均每次 I/O 请求的响应时间（毫秒）。对 redo log 写入尤其重要	SSD < 2ms，HDD < 10ms；> 20ms 需告警
avgrq-sz	平均请求大小（扇区数，512 字节/扇区）。达梦默认数据页大小通常为 8KB 或 16KB（对应 16~32 扇区）	数据库场景常见 16~64 扇区（8~32 KB）
aq-sz	平均队列深度。若持续 > 2 且 await 升高，说明 I/O 压力较大	一般 < 2，高并发时可接受 4~5

注意：%util 高不一定表示磁盘坏，也可能是高性能设备（如 NVMe SSD）在多队列下利用率高但延迟仍很低。需结合 await 判断。

四、识别设备映射

在使用 LVM（逻辑卷管理）时，iostat 会显示 dm-0、dm-1 等设备名。你需要知道这些设备对应哪些达梦相关的文件系统。

使用 lsblk 查看树形关系

--输出示例：
sda
└─sda3
   ├─klas-root (dm-0)  /
   ├─klas-swap  (dm-1) [SWAP]
   └─klas-backup(dm-2)

说明：

dm-0 → 根文件系统 /，若达梦软件安装在此，数据文件、redo log 也在此。
dm-1 → swap，监控其 I/O 可判断内存是否不足。
dm-2 → 备份卷，未挂载则无 I/O。

五、常用监控命令与工具

5.1 实时监控（推荐组合）

# 每 2 秒显示所有磁盘的扩展统计，以 MB 为单位
iostat -x -d -m 2

# 只关注达梦数据目录所在的磁盘（如 dm-0）
iostat -x -d -m dm-0 2

5.2 定位 I/O 来源进程

当发现磁盘繁忙时，使用以下工具找出是哪些进程产生了 I/O：

# 类似 top，按 I/O 排序
iotop -o

# 使用 pidstat 查看每个进程的 I/O 统计
pidstat -d 2

5.3 长期记录与告警

#!/bin/bash
# ============================================================
# 脚本名称: io_monitor.sh
# 脚本作者: shine
# 功能描述: 监控 Linux 主机 IO 情况并记录到日志（dmdba 用户版）
# 依赖工具: iostat (sysstat)
# 部署路径: /home/dmdba/io_monitor.sh
# 日志路径: /home/dmdba/io_logs/io_YYYYMMDD.log
# ============================================================

# ---------------------- 配置区域 ----------------------
LOG_DIR="/home/dmdba/io_logs"               # 日志存放目录（dmdba 可写）
LOG_FILE="${LOG_DIR}/io_$(date +%Y%m%d).log" # 按天分割日志
SAMPLE_COUNT=3                              # 采样次数
SAMPLE_INTERVAL=2                           # 采样间隔（秒）
# -----------------------------------------------------

# 检查 iostat 是否存在
if ! command -v iostat &>/dev/null; then
    echo "错误：iostat 命令未找到，请确保已安装 sysstat。" >&2
    exit 1
fi

# 创建日志目录（如果不存在）
mkdir -p "$LOG_DIR" || {
    echo "错误：无法创建日志目录 $LOG_DIR" >&2
    exit 1
}

# 记录开始标记及采样数据
{
    echo "==================== $(date '+%Y-%m-%d %H:%M:%S') ===================="
    echo "采样参数: 间隔=${SAMPLE_INTERVAL}秒, 次数=${SAMPLE_COUNT}"
    echo ""

    # 执行 iostat 采集
    # -x : 显示扩展统计信息（含 await、%util 等关键指标）
    # -d : 仅显示设备利用率报告
    # -t : 打印时间戳
    # -m : 吞吐量以 MB/s 为单位（便于阅读高速存储）
    iostat -x -d -t -m "$SAMPLE_INTERVAL" "$SAMPLE_COUNT"

    echo ""
} >> "$LOG_FILE" 2>&1

# 自动压缩 7 天前的原始日志（避免占用过多空间）
find "$LOG_DIR" -type f -name "io_*.log" -mtime +7 -exec gzip -f {} \;

# 自动删除 30 天前的压缩日志（彻底释放空间）
find "$LOG_DIR" -type f -name "io_*.log.gz" -mtime +30 -delete

将以上脚本加入 crontab，每5分钟记录一次，配合监控系统（如 Zabbix、Prometheus）设置告警：

await > 20（SSD 场景）
%util > 80 持续 5 分钟

六、总结

磁盘 I/O 是达梦数据库性能的关键因素之一。通过定期使用 iostat 等工具监控核心指标，结合 lsblk 明确设备映射，并掌握针对达梦特征的分析方法，可以快速定位 I/O 瓶颈，做出合理的优化决策。建议将 I/O 监控纳入日常运维巡检体系，并与达梦自身的动态性能视图（如 V$SQL_STAT、V$SESSION_STAT、V$LATCHES）配合使用，形成完整的性能分析闭环。

SQL优化之注入HINT

shine — Thu, 19 Mar 2026 09:25:54 +0000

一、说明

功能说明：为 SQL 注入 HINT 规则。SF_INJECT_HINT 方法创建的 HINT 规则无生效类别限制，如果需要为该 HINT 规则设置生效类别，可通过 SF_ALTER_HINT 过程修改实现。

参数说明：
sql_text：待注入 HINT 规则的 SQL 语句。SQL 语句必须是语法正确的增删改查语句。
hint_text：待注入的 HINT 规则，必须指定为非 NULL 值。
name：HINT 规则的名称，指定为 NULL 值时系统为其命名。
description：对 HINT 规则的详细描述。
validate：HINT 规则是否生效。TRUE 是；FALSE 否。
fuzzy：指定 SQL 的匹配规则为精准匹配或模糊匹配，该参数值不能为 NULL。
当该参数缺省时，表示使用定义 1 的语法，仅支持精准匹配。
该参数类型为 BOOLEAN 时，使用定义 2 或定义 3 的语法，值为 TRUE 时，为模糊匹配；
值为 FALSE 时，为精准匹配。
精准匹配时，待注入 HINT 规则的 SQL 语句必须为语法正确的 INSERT/DELETE/UPDATE/SELECT/MERGE INTO 语句（语句以 EXPLAIN/EXPLAIN FOR 开头时，去掉 EXPLAIN/EXPLAIN FOR 后的语句必须完全正确），精准匹配要求 SQL 语句完全匹配，不支持 SQL 语句中的子查询匹配；
模糊匹配时，待注入 HINT 规则的 SQL 语句应为非 NULL 值。
该参数类型为 INT 时，使用定义 4 或定义 5 的语法，值为 0 表示精确匹配，值为 1 表示模糊匹配，值为 2 表示通过 sql_text_id精确匹配。
fuzzy 取值为 2 时，参数 sql_text 应该输入长度为 13 的 sql_text_id 字段，如果 fuzzy 取值为 2 但参数 sql_text 依旧输入 SQL 语句，预期会报错。
need_clear：是否同步清空所有缓存的计划，该参数值不能为 NULL。
当该参数缺省时，表示使用定义 1、定义 2 或定义 4 的语法，此时默认不清空缓存计划。
指定该参数时，使用定义 3 和定义 5 的语法，值为 TRUE 时，清空缓存的计划；值为 FALSE 时，模糊匹配和通过 sql_text_id 匹配时，不清空缓存的计划，需要手动清除对应 SQL 的计划后，指定的 HINT 才能生效，精确匹配时，默认会删除受影响 SQL 的计划缓存。

返回值：执行成功返回名称，执行失败报错误信息。

二、使用

--模糊匹配
SF_INJECT_HINT('SQL语句', 'HINT', 'INJECT名称', '注释', TRUE, TRUE);

注入HINT后需要清空对应SQL的计划缓存

BEGIN
    FOR RS IN (SELECT * FROM V$CACHEPLN WHERE SQLSTR LIKE '%SQL语句%') LOOP
        EXECUTE IMMEDIATE 'SP_CLEAR_PLAN_CACHE(' || RS.CACHE_ITEM || ');';
    END LOOP;
END;

查询已经注入的HINT-系统视图

SELECT * FROM SYSINJECTHINT ORDER BY CRTDATE DESC;

禁用/启用注入的HINT

SF_ALTER_HINT('TEST_INJECT', 'STATUS', 'DISABLED');
SF_ALTER_HINT('TEST_INJECT', 'STATUS', 'ENABL ED');

删除注入的HINT

SF_DEINJECT_HINT('INJECT名称');

达梦数据库的重做日志

shine — Thu, 19 Mar 2026 09:24:27 +0000

一、概述

重做日志（即 REDO 日志）指在 DM 数据库中添加、删除、修改对象，或者改变数据，DM 都会按照特定的格式，将这些操作执行的结果写入到当前的重做日志文件中。重做日志文件默认以 log 为扩展名，可在初始化数据库时使用建库参数 RLOG_POSTFIX_NAME 指定重做日志文件的扩展名。每个 DM 数据库实例必须至少有 2 个重做日志文件，默认两个日志文件为 DAMENG01.log、DAMENG02.log，这两个文件循环使用。

重做日志文件因为是数据库正在使用的日志文件，因此被称为联机日志文件。

重做日志文件主要用于数据库的备份与恢复。理想情况下，数据库系统不会用到重做日志文件中的信息。然而现实世界总是充满了各种意外，比如电源故障、系统故障、介质故障，或者数据库实例进程被强制终止等，数据库缓冲区中的数据页会来不及写入数据文件。这样，在重启 DM 实例时，通过重做日志文件中的信息，就可以将数据库的状态恢复到发生意外时的状态。

重做日志文件对于数据库是至关重要的。它们用于存储数据库的事务日志，以便系统在出现系统故障和介质故障时能够进行故障恢复。在 DM 数据库运行过程中，任何修改数据库的操作都会产生重做日志，例如，当一条元组插入到一个表中的时候，插入的结果写入了重做日志，当删除一条元组时，删除该元组的事实也被写了进去，这样，当系统出现故障时，通过分析日志可以知道在故障发生前系统做了哪些动作，并可以重做这些动作使系统恢复到故障之前的状态。

二、管理重做日志文件

添加重做日志文件

在服务器打开状态下，可以添加新的重做日志文件。添加的数据文件大小最小为 4096*页大小，如页大小为 8K，则可添加的文件最小值为 4096*8k=32M。如添加重做大小为 128M 的重做日志文件DAMENG03.log。

ALTER DATABASE ADD LOGFILE '/data/dmdata/DAMENG/DAMENG03.log' size 128;

扩展重做日志文件

在服务器打开状态下，可以扩展已有的重做日志文件的大小。如扩展重做日志文件DAMENG03.log 到 256M。

ALTER DATABASE RESIZE LOGFILE '/data/dmdata/DAMENG/DAMENG03.log' to 256;

三、其他

在V$RLOG视图中监控FREE_SPACE/TOTAL_SPACE，如果空闲率低于20%就需要考虑扩容，低于1G可用一般是出现影响了。存储IO性能可以监控上看看应该有瓶颈了，还有业务层面也看看拆分大事务，间隔调度批量作业等，避免集中资源压力。扩REDO要选择在业务空闲时间进行。

SELECT FREE_SPACE*1.0/TOTAL_SPACE FROM V$RLOG;

V$LOG_HISTORY：服务器启动后，记录当前节点联机日志切换的历史信息。只记录最近 128 次切换记录。

该视图新增于2023年第二季度

以前的版本可以通过过滤日志得知重做日志的切换时间，如下：

cat 日志.log | grep 'rfil file switch'

达梦数据库授予其他用户下创建表的权限

shine — Thu, 19 Mar 2026 09:23:17 +0000

1、给用户授予在其他用户创建表或视图的权限。

1.修改参数
sp_set_para_value(1,'ENABLE_DDL_ANY_PRIV',1);
2.执行授权语句
例如：grant create ANY table to "用户名"
3.修改参数为原值
sp_set_para_value(1,'ENABLE_DDL_ANY_PRIV',0);

2、如何授予A用户对B用户下所有表的查询权限

1.设置 INI 参数 GRANT_SCHEMA=1，重启数据库生效。
sp_set_para_value(2,'GRANT_SCHEMA',1);
2.将模式 B 下所有对象的查询权限授予用户 A
GRANT SELECT ON SCHEMA B TO A;
3.将模式 B 下所有权限授予用户 A
GRANT ALL PRIVILEGES ON SCHEMA B TO A;

总结

GRANT ALL PRIVILEGES ON SCHEMA 语句授予的权限是对指定模式下现有对象的所有操作权限（如查询、插入、更新、删除等），但不包括 CREATE、ALTER、DROP 这类属于 DDL（数据定义语言）的操作权限。

也就是说“指定模式的下的所有权限”通过GRANT_SCHEMA无法完全实现，但如果不需要指定模式而是授予在其他用户下的创建权限可以通过ENABLE_DDL_ANY_PRIV和GRANT_SCHEMA共同实现。

良的世界

案例：达梦数据库利用dmlcvt解析归档日志定位删除事务

一、问题背景

二、排查环境

三、排查步骤

四、结论

五、经验总结

六、附录：关键命令速查

达梦数据库主备集群动态增加实时备库

一、对主库进行联机备份

二、传输备份文件到新备库

三、还原恢复新备库

四、配置新备库

4.1 配置dm.ini

4.2 配置dmmal.ini

4.3 配置dmarch.ini

4.4 配置dmwatcher.ini

4.5 启动新增备库

4.6 动态添加MAL配置

4.7 动态添加归档配置

4.7.1 关闭原系统中所有实例的守护进程和监视器

4.7.2 手动修改原系统中所有实例为MOUNT状态

4.7.3 动态添加归档节点

4.7.4 手动修改原系统中所有实例为OPEN状态

4.7.2~4.7.4 步骤合并记录如下

4.8 修改监视器配置文件

4.9 启动所有守护进程以及监视器

达梦数据库SQL报错之远程操作符执行失败

一、问题描述

1.1 现象概述

1.2 执行环境

1.3 SQL语句详情

二、问题分析

2.1 根本原因分析

2.2 参数DBLINK_OPT_FLAG分析

三、解决方案

3.1 方案一：使用HINT调整DBLINK_OPT_FLAG（推荐）

3.2 方案二：改写SQL（稳妥）

四、问题总结

达梦数据库的审计功能

一、审计的价值

二、审计的设计

三、三权分立与审计员的角色

四、审计开关

五、三层审计体系详解

5.1 系统级审计：自动生效的全局监控

5.2 语句级审计：按 SQL 类型精准捕获

5.3 对象级审计：精细到表、视图乃至列级别

六、审计记录的查看与分析

6.1 动态视图查询（推荐日常使用）

6.2 DM 审计分析工具（Analyzer）

6.3 审计文件的存放位置

七、审计文件的空间管理

7.1 空间满的处理策略

7.2 审计文件的清理

八、审计刷盘策略：性能与安全的平衡

九、最佳实践与注意事项

十、总结

达梦数据库在同一服务器上配置多个 AP 服务

一、问题背景

二、问题解决

2.1 创建新的 dmap.ini 配置文件

2.2 重新注册 AP 服务

2.3 修改数据库参数

三、验证与总结

达梦数据库中常用的系统视图

一、核心数据字典表

二、Oracle兼容视图 (DBA_/ALL_/USER_)

三、动态性能视图 (V$)

四、用户/模式视图

五、鲜少使用

5.1 查询依赖关系

5.2 查询库中的确定性函数

5.3 查询库中的HUGE表

达梦数据库服务器的磁盘I/O监控指南

一、为什么要监控磁盘 I/O

二、达梦数据库的 I/O 特征

三、核心 I/O 指标解读

四、识别设备映射

五、常用监控命令与工具

2.2 参数`DBLINK_OPT_FLAG`分析