DM8达梦数据库故障处理常见问题

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

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

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

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

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

误删除 DAMENG01.log 怎么办

分以下两种情况：

如果有备份文件

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

如果没有备份文件

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

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

[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) 中记录的值。

[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 工具的具体情况，如下图所示：

dmctlcvt帮助信息

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

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

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

./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_SIZ 数值，这个参数是动态参数，修改后立即生效】。等有机会重启数据库服务时，再在重启数据库服务前，适当调大 HJ_BUF_SIZ 数值，同时也需要保持较高的 HJ_BUF_GLOBAL_SIZE/HJ_BUF_SIZ 的比值。

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

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

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

ZYJ 数据管理工具卡顿

在 ZYJ 系统运行一段时间之后，启动管理工具 (manager) 的时候，管理工具启动界面长时间处于卡顿状态，启动成功后，在管理工具界面上进行操作也存在卡顿的问题。

【解决方法】：

在 /opt/dmdbms/bin/tool/workspace/manager 目录下，查找以 .snapshot 结尾的文件，移动到其他的地方或者删除掉，再重新打开管理工具，最后取消自动保存设置即可，如下图所示：

取消自动保存

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。

【解决方法】：

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