【记录备用】达梦数据库相关故障及解决方法

达梦数据库相关故障及解决方法

本章节主要介绍达梦数据库故障处理常见问题，为用户提供故障处理常见问题的分析和解决思路。除此之外，用户还可前往**技术社区** 参与更多问题讨论。

最新资料查看：传送门

数据库表数据误删，如何恢复

首先确定是什么时候做的操作？数据库是否有备份？有备份的情况下数据可以恢复到任意时间点。如果没有备份一般是无法恢复的。

数据库系统必须保证即使发生故障，也可以保障数据的完整性和一致性。支持故障恢复的技术主要是日志，日志以一种安全的方式记录数据库系统变更的历史信息，一旦系统出现故障，数据库系统可以根据日志将系统恢复至故障发生前的某个时刻。数据库系统的日志分为两种类型：

- REDO 日志，在数据被修改后记录它的新值。
- UNDO 日志，在数据被修改前记录它的旧值。

另外，当服务器处于归档模式时，如果数据库发生故障，通过备份文件和归档日志可以恢复到指定时间点。具体方法可以参考《DM 备份与还原》手册（手册位于数据库安装路径 /dmdbms/doc/special 文件夹下）。

误删除 undo/redo 日志怎么办

分以下两种情况：

如果有备份文件

如果有备份文件，可以重新初始化一个新的数据库（初始化参数要和原库一样，比如页大小、大小写敏感、字符集等，这些可以在 DM 数据库安装路径，…/data/DAMENG 目录下以 dminit+日期时间.log 命名的文件中查询），然后将备份文件和归档日志文件拷贝到新的环境，然后再进行备份 + 归档的还原操作。

如果没有备份文件

如果没有备份，可以通过修改永久魔术值的方式来恢复，但是这种情况下有可能丢失数据。方法如下：

• 重新初始化一个新的数据库，（初始化参数要和原库一样，比如页大小、大小写敏感、字符集等，这些可以在 DM 数据库安装路径，…/data/DAMENG 目录下以 dminit+日期时间.log 命名的文件中查询）。
• 将步骤 (1) 中重新初始化的数据库中 DAMENG01.log、DAMENG02.log 文件拷贝到当前丢失 REDO 日志的库目录下。
• 使用 dmmdf 工具获取 SYSTEM.DBF 的 db_magic，并记录下来。

Copy[root@dmyanshi2 bin]# ./dmmdf /data/DAMENG/SYSTEM.DBF 1
1 db_magic=1394176795
2 next_trxid=34742179
Please input which parameter you want to change(1-2), q to quit: q

• 使用 dmmdf 工具设置 DAMENG01.log 文件的 db_magic，设置为步骤 (3) 中记录的值。

Copy[root@dmyanshi2 bin]# ./dmmdf /data/DAMENG/DAMENG01.log 2
1 sig = DMRLOG
2 ver = 7001
3 chksum = 0
4 dbversion = 0x70008
5 sta = 1
6 n_magic = 7
7 db_magic = 1411700695
8 clsn_fil = 0
9 cur_fil_id = 0
10 next_seq = 0
11 arch_seq = 0
12 len = 67108864
13 free = 4096
14 clsn = 0
15 clsn_off = 4096
16 arch_lsn = 0

You can only reset sta(5) or db_magic (7) or clsn (14).
Please input the num which one you want to change, q to quit: 7
Input the new value: 1394176795
1 sig = DMRLOG
2 ver = 7001
3 chksum = 0
4 dbversion = 0x70008
5 sta = 1
6 n_magic = 7
7 db_magic = 1394176795
8 clsn_fil = 0
9 cur_fil_id = 0
10 next_seq = 0
11 arch_seq = 0
12 len = 67108864
13 free = 4096
14 clsn = 0
15 clsn_off = 4096
16 arch_lsn = 0

Do you want to quit and save the change to file (y/n): y
Save to file success!

• 重新启动数据库即可。

表空间的数据文件被删除了，想删除表空间，如何解决

数据文件被删除，那这部分的数据是丢失的，数据库无法正常启动。处理方式是将控制文件转成文本文件，在控制文件中把对应表空间信息删除，再把文本文件转成控制文件，删除对应的数据文件，最后启动数据库即可。

具体操作如下：

• 将控制文件转换成文本文件

切换到数据安装路径如：/opt/dmdbms/bin/bin 执行 ./dmctlcvt help 可以查看到 dmctlcvt 工具的具体情况，如下图所示：

将 dm.ctl 文件转换成 dm.txt 文件，如下所示：

Copy./dmctlcvt TYPE=1 SRC=/opt/dmnew/data/DAMENG/dm.ctl DEST=/opt/dmnew/data/DAMENG/dmctl.txt

• 删除掉 dmctl.txt 中被删除的数据库文件指定的路径。
• 将 dmctl.txt 生成 .dm.ctl 文件执行以下操作：

Copy./dmctlcvt TYPE=2 SRC=/opt/dmnew/data/DAMENG/dmctl.txt DEST=/opt/dmnew/data/DAMENG/dm.ctl

超出全局 hash join 空间

首先我们讲一个故事：

你是上帝视角【1】，你给了小明 100 个棒槌【2】，这个时候来了 10 个叫做小花的人，小花可以去仓库里拿面粉做包子，但是做一次包子，需要借用小明的棒槌，假如每一个小花借用 10 个棒槌，如果同时来了 11 个小花，前 10 个小花都能借到棒槌，第 11 个小花去找小明借棒槌的时候，小明就告诉她：超出我的棒槌个数了，小花做包子失败。这句话翻译一下就是：数据库服务器报错超出全局 hash join 空间，应用请求在数据库执行失败。

但是，每一个小花根据自己的工作量，需要的棒槌个数并不一定必须是 10 个。也就是说，只有来的小花把棒槌都借用完，小明才会报错。但是小明也不是一直会报错，只要有任何一个小花，事情做完了，把借用的棒槌还回来，小明就又可以支撑新的小花。

上面这个故事，对应两个参数，如下图所示：

（图片来源：《DM 系统管理员手册》dm.ini 的介绍，手册位于数据库安装路径 /dmdbms/doc 文件夹下。）

• 小明一共有多少个棒槌，由 HJ_BUF_GLOBAL_SIZE 设置，默认值是 500。
• 一个小花最多可以借多少个棒槌，由 HJ_BUF_SIZE 设置，默认值是 50。

还有一个参数控制小明一次给小花多少个棒槌（比如小明要给小花 10 个棒槌，可以是一次给 1 个给 10 次，也可以是一次给 5 个给两次，这两种代价是不一样的）。一次给多少个，取决于以下参数：

（图片来源：《DM 系统管理员手册》dm.ini 的介绍，手册位于数据库安装路径 /dmdbms/doc 文件夹下。）

好了，我们回到问题，如果遇到小明报错了怎么办呢？

• 解决方法一

很多情况下，小花实际上只需要 1 个棒槌、一分钟内就能把事情做完，结果她却用了 10 个棒槌，一天都没有把事情做完，占用的这 10 个棒槌也一直没有还给小明。

换句话说就是要优化语句，消除掉这些不聪明的小花。遇到这个问题的优先核心方法是：找出不聪明的小花，让她变聪明——找到慢语句，进行优化。

• 解决方法二

扩大小明的棒槌个数，增大 HJ_BUF_GLOBAL_SIZE 数值。

或者是减小单个小花可以借用的棒槌上限，改小 HJ_BUF_SIZ 数值。（有人会问，小花要 10 个棒槌，现在你给她设置成 5 个，她还能干活么？答案是可以，哪怕限制小花最多只能借用 1 个棒槌，她也可以干活，只是工作时间会久一点。同样的，也不是一次性给的越多越好，如果本身只需要 5 个，一次性给了 10 个，也没有意义，工作效率并不会提高。）

如果确认系统中预期的 SQL 均是符合预期的计划，效率均没有问题，确实需要高并发，就必须提高 HJ_BUF_GLOBAL_SIZE/HJ_BUF_SIZ 的比值。可以通过调大 HJ_BUF_GLOBAL_SIZE 数值或适当调小 HJ_BUF_SIZ 数值来解决，也可以通过同时调大这两个参数值并保持较高的 HJ_BUF_GLOBAL_SIZE/HJ_BUF_SIZ 的比值来解决。

注意

修改数据库参数的方式： Sp_set_para_value(1,’参数名字’,参数值);–当成 SQL 执行；对于动态参数，直接修改后，立即生效；如果是静态参数，如此修改，会报错：无法修改静态配置参数。 Sp_set_para_value(2,’参数名字’,参数值);–当成 SQL 执行；对于动态参数或者静态参数都可以用，修改后，需要重启数据库服务后才生效。

数据库表被 truncate 后能否找回数据

不能找回，truncate 删除表数据是不可逆的。只能看能否通过备份 + 归档日志的方式，将数据库还原到指定时间点的方式来找回该表的数据。

DM 数据库异常宕机原因排查

当数据库运行过程中发生异常宕机后，需要结合数据库运行日志联合分析原因。如果怀疑是因 SQL 导致的问题，可以通过 DM 提供的 dmrdc 命令行工具抓取到数据库宕机时服务器所有会话线程对应的 SQL 语句，使用格式为：./dmrdc sfile=src_file dfile=dest_file。

例如生成 core 文件为 core.19456，则应该执行：./dmrdc sfile=core.19456 dfile=core_19456.txt。

待分析完成后，我们可以根据生成的 core_19456.txt，查看到数据库服务器所有会话线程对应的 SQL 语句，其中 SQL 语句前面的中括号数值表示对应线程号，对应堆栈信息中的 LWP 号。我们可以使用 gdb 命令 配合 thread apply all bt 打印出所有线程堆栈，一般导致宕机的 SQL 在【Thread 1】上，我们可以在测试环境中尝试重现宕机现象，如果能够重现则可以将此问题交由达梦技术工程师来处理。

其他类型被强制转成科学计数法的格式

其他类型被强制转成科学计数法的格式 / 比如 100 变成 1E+2% / 10 变成 1。

【解决方法】：

可访问达梦云适配中心下载试用，下载最新版数据库，安装的时候选择驱动，将现在的出现问题的驱动换成最新的驱动。

打开管理工具报错：Locking is not possible in the directory

【问题解决】：

有如下两种解决方法：
方法 1：
可以尝试删除安装目录下的 .fileTableLock 文件 ，再次打开达梦管理工具时会自动生成一个这个 lock 文件。
举例：如下是安装目录，找到 tool 目录下对应的 fileTableLock 文件，删除后再启动管理工具。

方法 2：

打开位于…/tool 目录下的 manager 配置文件，manager.ini 添加参数 -Dosgi.locking=none，并保存生效。

控制文件 dm.ctl 被误删，启动报错：[code:-803]

【问题详情】：

Read ini error,name:CTL_PATH,value:xxxxxx
[invalid ini config value]
nsvr_ini_file_read failed,
[code:-803]

启动数据库报错如下：

【解决方法】：

1）通过 ctl_bak 找回，用最近的一个 dm_xxx.ctl 改名启动

2）详情参考：文件误删除或损坏

数据文件 MAIN.dbf 或者自创表空间被误删

【问题详情】：

【解决方法】：

详细解答请参考：文件误删除或损坏

数据文件 ROLL.dbf，SYSTEM.DBF 被删后无法启动报错

【问题详情】：

【解决方法】：

详细解答请参考：文件误删除或损坏

误删除 TEMP.DBF 怎么处理

TEMP.DBF 被删后，重启数据库会自动生成一个新的。

undo 日志损坏

【恢复方法】：

undo 损坏优先选择“备份 + 归档”恢复，从实例日志获取故障时间；无备份归档的情况下，可以选择跳过 ROLL.DBF 启动数据库临时启动数据库（危险操作，可能破坏事务的原子性）。修改 dm.ini 参数 PSEG_RECV 为 0 。

注意

PSEG_RECV 参数释意： 系统故障重启时，对活动事务和已提交事务的处理方式。 0：跳过回滚活动事务和 PURGE 已经提交事务的步骤。 1：回滚活动事务并 PURGE 已经提交事务； 2：延迟 PURGE 已提交事务，延迟回滚活动事务； 3：回滚活动事务，延迟 PURGE 已提交事务。

redo 日志损坏，报错[-723][-717]

【问题详情】：

举例：下面是断电后导致 redo 损坏的一个报错信息；

Copy日志：Read rfil ['/data/dmdbms/data/DAMENG/DAMENG02.log'] from offset[67042304] failed,code [-723]
前台：main rfil [/data/dmdbms/data/DAMENG/DAMENG01.log]'s grp collect 0 invalid recv_pwr record.

【恢复方法】：

若备份归档文件都存在：

redo 损坏优先选择“备份 + 归档”恢复，从实例日志获取故障时间；

无备份归档的情况下，可以选择替换 redo 日志临时启动数据库（危险操作，可能会丢失一部分数据），然后将数据迁移出来。

若无法使用备份归档恢复下，替换 redo 启动数据库步骤:

• 命令模拟 redo 日志损坏

Copydd if=dminit20210203144245.log of=TEST01.log

• 查看初始化日志，观察初始化参数，重新初始化一个新的实例并前台启动一次

Copy./dminit path=/home/dmdba/data/dmdbms port_num=5237 db_name=TEST
./dmserver /home/dmdba/data/dmdbms/TEST/dm.ini

• 查看故障库的 db_magic 值和 pemnt_magic 值

Copy./dmmdf type=1 file=/home/dmdba/data/TEST/SYSTEM.DBF

备注：db_magic：数据库魔数；pemnt_magic：数据库永久魔数

• 修改新库的 db_magic 值和 pemnt_magic 值