DM8常见问题处理

DM8常见问题处理

实例启动问题
License 过期要怎么处理
DM 数据库启动后提示 product has expried。“License已经过期”，表明数据库授权已经到期，需要跟达梦相关人员沟通，完成替换授权工作，恢复服务正常启动。
启动时提示找不到 license
首先确认你是否有 license，所谓的 license 就是 DM 数据库的授权文件 dm.key，license 一般是通过销售渠道获取的，要么是申请的临时授权，要么是购买了正版数据库后获得的正式授权。
如果是从官方网站上下载的版本是没有 license 文件的，所以在启动过程中会提示 file dm.key not found, use default license!，这是正常的，不会影响我们正常使用数据库。
如果你已经有了 license 文件，且文件放入了指定目录，启动时还是提示 file dm.key not found, use default license!，那么请检查授权文件的是否有当前启动数据库的用户的读权限。
启动 DM 数据库报错：dmserver startup failed, code=-104[invalid int file]
启动 DM 数据库时，命令中确保 dm.ini 路径正确。
启动 DmAPService 服务失败
Windows 安装 DM 数据库，在安装完成的最后一步报错：启动 DmAPService 服务失败！可以尝试以下方法：
报这个错没关系，先点击【确定】完成。启动服务的时候可以手动启动。
以管理员方式运行安装程序，同时检查授权 key 文件是否过期、操作系统的时间是否正确。
查看日志，详细查看日志目录 (D:\dmdbms\log) 下的相关日志文件，分析日志中的报错信息。
启动时数据库报 open files 连接超出资源限制

该日志写入 dmdbms/log 里面的服务启动日志，可从里面看到是 open files 超出系统限制。有时候按照标准修改了 /etc/security/limits.conf，资源赋值为 65538 也未必够，可以将值修改得更大即可解决。
使用 root 用户进行以下操作：
#vi /etc/security/limits.conf
dmdba soft nofile 65538
dmdba hard nofile 65538
dmdba soft nproc 65538
dmdba hard nproc 65538
#vim /etc/security/limits.d/90-nproc.conf
* soft nproc 1024
root soft nproc unlimited
* nproc 16384
注意
90-nproc.conf 文件名可能会随着系统变化而不同。
Linux 环境下启动数据库的命令
Linux 环境下启动 DM 数据库：进入数据库安目录的 bin 目录下执行命令 service DmServiceDMSERVER start/stop/restart（启动/停止/重启）。
假设数据库安装目录在 /opt/dmdbms/bin 目录下，则命令启动方法如下：

假设数据库安装目录在 /opt/dmdbms/ 目录下，也可以通过图形化启动数据库，方法如下：
进入 /opt/dmdbms/tool/ 目录执行 ./dmservice.sh 弹出图形化界面

图形化界面使用方式
右键 DM 数据库实例服务点击【启动】即可启动数据库服务。

DM 数据库如何前台启动
进入 DM 安装目录下的 bin 目录，直接打开应用程序 dmserver 就可以启动 DM 数据库。或者先打开 Windows 命令提示符工具，在命令工具中执行命令进入 DM 服务器的目录，再执行 dmserver 的命令启动 DM 数据库。
详细步骤可以参考《DM 系统管理员手册》第八章节。手册位于数据库安装路径 /dmdbms/doc 文件夹下。
命令行方式启动参数方式：dmserver [ini_file_path] [-noconsole] [mount]
说明如下：
Dmserver 命令行启动参数可指定 dm.ini 文件的路径，非控制台方式启动及指定数据库是否以 Mount 状态启动。
Dmserver 启动时可不指定任何参数，默认使用当前目录下的 dm.ini 文件，如果当前目录不存在 dm.ini 文件，则无法启动。
Dmserver 启动时可以指定 -noconsole 参数。如果以此方式启动，则无法通过在控制台中输入服务器命令。
如何启动和关闭 DM 数据库
通过“DM 服务查看器”来启动数据库服务
Windows 或 Linux 都可以通过“DM 服务查看器”来启动数据库服务（Linux 前提是有图形界面），Linux 如果是图形界面安装的数据库，“DM 服务查看器”也在桌面的“达梦数据库”文件夹看下，如果使用的是命令行安装，需要在图形界面进入到 …/dmdbms/tool/ 执行 ./dmservice.sh 来运行，“DM 服务查看器”如下图所示：

通过系统服务启动数据库
Linux 环境：
Linux 使用系统服务启动和关闭数据库的方法前提是系统注册了数据库服务。关于注册数据库服务知识请参考《DM_Linux 服务脚本手册》，手册位于数据库安装路径 /dmdbms/doc/special 文件夹下。
启动数据库方法如下：(使用 root 用户)
查看 DM 数据库服务：# systemctl list-unit-files|grep DmService

启动数据库服务：# systemctl start DmServiceDAMENG.service
停止数据库服务：# systemctl stop DmServiceDAMENG.service
确认服务是否启动：# ps -ef | grep dmserver
通过命令启动
通过命令启动是数据前台启动的，一般在调试时才使用，是方便观察日志输出。
使用命令启动时务必使用 dmdba 用户启动，避免出现未知问题。
启动格式 dmserver path=dm.ini 的路径如下：
$ cd /home/dmdba/dmdbms/bin/
$ ./dmserver path=/home/dmdba/dmdbms/dmdata/DAMENG/dm.ini
当出现 SYSTEM IS READY 字样时说明数据库已正常启动。

DM 数据库启动报错：[DM64][buf4_default_pool_init]errot in buf4 pool init
内存参数配置过大，剩余内存不足，将数据库 dm.ini 文件里 buffer 和 max_buffer 改小一些。
数据库开机自启
如果是图形化的方式创建实例：图形化工具会自动创建开启自启服务，所以不需要再进行其他操作就可以让实例开机自启。
如果是命令行的方式创建实例：需要自己手动注册开机自启的服务，注册自启服务之后，可以实现开机自启。如果没有注册开机自启服务，则不会实现实例的开机自启功能。
启动/重启 DM 数据库失败
有以下可能原因：
启动失败：用户可能没有初始化，需要初始化数据库。可以参考达梦数据库安装及初始化
参考《DM 系统管理员手册》第7章-启动和关闭数据库，（手册位于数据库安装路径 /dmdbms/doc 文件夹下。）看是否启动方式错误。或者可以参考 Linux 平台达梦数据库启动与关闭
其他原因造成的启动/重启失败，可查看数据库安装路径下/log 文件夹中的日志，通过分析报错时间段内的错误信息，来定位具体导致的原因。也可以将相关日志发给DM技术服务人员进行分析定位。
建库实例/初始化实例参数设置
数据库实例初始化参数中有 4 个是无法修改的：（请在数据库安装前做好规划）
1.簇大小，簇是每次申请的页数，表存满了以后会一次性连续申请（参数设置）个页的空间。
2.页大小，影响每一行能存储的最大值，和查询效率。
3.字符集，影响所用的字符集后期是否支持对应的生僻字等。
4.大小写敏感，影响 SQL 编写，对小写对象是否需要添加双引号。

参数说明如下：
数据文件簇大小
数据文件使用的簇大小，即每次分配新段空间时的连续页数，可以为 16 页或 32 页，推荐使用 16 页。这个参数一般不用修改。
页大小 (page_size)
除去 Clob、Blob 等大字段外，数据库中一行记录的所有字段的实际长度的和不能超过页大小的一半。建议页大小设置为 16 KB，防止在后期进行数据迁移和开发过程中出现记录超长的问题；
字符集
字符集选项。取值：0 代表 GB18030，1 代表 UTF-8，2 代表韩文字符集 EUC-KR。默认为 0。可选参数。
字符串比较大小写敏感 (case_sensitive)
默认为大小写敏感的，根据具体情况进行设置。迁移实施中如果原始库为 Oracle 和 DB2 数据库的话需设置为大小写敏感，若为 SQL Server 和 MySQL 数据库则需设置为大小写不敏感，所以在数据库初始化库的过程中需要根据具体情况来选择。
注意事项
在开发环境和测试环境的页大小、字符串大小写敏感等初始化参数一定要保持一致，避免使用 .bak 文件进行还原的时候，因为初始化参数不一致导致无法还原的问题。
DM 数据库启动后提示 [License 已经过期]
DM 数据库遇到该报错表明数据库授权已经到期，需要跟 DM 数据库相关人员沟通，完成替换授权工作，恢复服务正常启动。
数据库实例初始化完毕，如何将大小写敏感改为不敏感
DM 数据库在初始化实例时有勾选大小写敏感选项。

初始化完成后是无法修改大小写敏感的，只能删除该实例重新初始化，所以在初始化时一定要确认选择。
DM7 是以 Docker 镜像的方式启动的，通信中产生的告警信息，错误代码是：107 Transport endpoint 是否有影响
不影响，警告对应数据库告警信息如下：

初始化 SSL 环境失败

将 dm.ini 里面的 ENABLE_ENCRYPT 修改为 0 后，重启实例即可解决。
dminit 方式初始化实例出现的问题
请参考如下两种建议：
为了减少对操作系统的影响，用户不应该以 root 用户来安装和运行 DM。用户可以在安装之前为 DM 创建一个专用的操作系统用户，例如创建用户 dmdba 和组 dinstall，并将安装目录赋予用户组
chown -R dmdba:dinstall /xx
​针对 dminit 工具出现的创建文件夹失败问题排查过程如下：
排查该文件是否有相对应的用户权限，例如：可能使用 dmdba 用户进行操作，但是 dminit 文件为 root 用户所有，则是权限不够。
排查该文件是否有写入权限，例如：可能计划数据文件目录属者为 root 或其他用户，但是使用 dmdba 用户操作 dminit 则会没有写入数据文件的权限。
​以下是赋权命令：
​chmod 777 /opt/ --赋予 opt 目录所有权限
​chmod 777 /opt/ -R --赋予 opt 目录以及其子目录所有权限
​chown dmdba:dinstall /opt/ -R – 更改 dmdbms 目录以及其子目录用户和组为 dmdba:dinstall
​初始化命令缺少 PATH 参数导致，修改命令后正常
​执行 ./dminit path=目录 就可以指定目录了，根据项目需要更改其他初始化参数（如页大小，大小写敏感，日志大小等）。
​可以执行 ./dminit help 里面有相应的参数，可以进行参考。
远程关闭数据库
首先需要远程连接到目的端的数据库界面。
如果数据库实例是前台启动，需要关闭前台启动的界面，即在前台界面输入 exit，待最后出现 DM Database Server shutdown successfully 信息并且重新返回命令行模式即表示停止成功。

如果数据库实例是后台脚本启动，需要使用命令 cd 到安装数据库的 bin 目录下，执行脚本 ./服务名 stop，就可以关闭数据库了，例如，启停脚本为 dmserverd 则数据库停止命令为 ./dmserverd stop，待出现绿色 OK 则停止成功。
启动 DM 数据库报错 code=-104
启动 DM 数据库报错：dmserver startup failed, code=-104[invalid int file]
【解决方法】：
启动服务保证 dm.ini 路径正确。
比如：./opt/dmdbms/bin/dmserver /opt/dmdbms/data/DMDB/dm.ini–ini 路径指定错误。
Linux 中怎么删除实例
在 Windows 上可以用 DBCA 工具删除实例，Linux 无法用 DBCA 工具，删除实例方法如下
首先确认初始化实例的安装目录，直接 rm data 文件夹就行。请删除前确认是否可以删除。
启动数据库提示 system information invalid
system 表空间损坏，需要用备份来进行还原处理。
linux 系统下达梦数据库如何设置为开机自启动
方法一（推荐）:
cd /opt/dmdbms/script/root
./dm_service_installer.sh -t dmserver -p DMSERVER -i /dameng/data/DBTEST_DW/dm.ini
检查服务是否开机自启，服务名 DmServiceDMSERVER ，不同操作系统有不同检查方法。请根据当前操作系统自行检查。
方法二:
修改启动脚本，将 DM 启动脚 本DmServiceXXXXX 移到 /etc/init.d 下，chkconfig DmServiceXXXXX on 确认此数据库能以 dmdba 用户正常前台启动后（必须步骤），操作步骤如下：
1.
复制数据库实例服务脚本 dmserverd，命名为 DmInstanceServiceDAMENG 并修改，修改 path 值为 dm.ini 路径（必须），dm_home 设置为 dm 主程序安装路径（必须），svc_porg 设置为数据库实例名（可选推荐）。
2.

将脚本 DmInstanceServiceDAMENG 复制到 /etc/rc.d/init.d 目录下。
3.
cp/opt/dmdbms/bin/DmInstanceServiceDAMENG /etc/rc.d/init.d/DmInstanceServiceDAMENG
赋予服务脚本 DmInstanceServiceDAMENG 可执行权限。
chmod 777 /etc/rc.d/init.d/DmInstanceServiceDAMENG
4.注册 DM 实例服务并配置开机自动启动。
chkconfig –add DmInstanceServiceDAMENG
chkconfig DmInstanceServiceDAMENG on
chkconfig –list DmInstanceServiceDAMENG
5.后台启动达梦数据库实例服务，查看服务状态，关闭实例服务。
service DmInstanceServiceDAMENG start
service DmInstanceServiceDAMENG status
service DmInstanceServiceDAMENG stop

达梦数据库 Create SOCKET connection failure.错误分析
在使用 disql 连接达梦数据库的时候可能会遇到如下错误：
[dmdba@dm ~]$ disql SYSDBA/SYSDBA
[-70028]:Create SOCKET connection failure.
disql V8
username:^C
[dmdba@dm ~]$
这里通常有如下几种原因导致。
DM 进程没有启动
达梦数据库可以通过 dmserver 命令行直接启动，也可以注册成服务启动。
对于第一次使用 dminit 初始化的 DM 实例，直接用服务启动时，也会出现该问题。
对于 dminit 初始化的 DM 实例，在第一次启动时，需要使用 dmserver 命令启动。
此时如果查看 DM 的日志，会显示如下信息：
[root@dm log]# tail -100 DmServicedave.log
file dm.key not found, use default license!
version info: develop
Use normal os_malloc instead of HugeTLB
Use normal os_malloc instead of HugeTLB
DM Database Server x64 V8 startup…
Database mode = 0, oguid = 0
License will expire on 2020-09-16
Database first startup failed, reinitialize database please!
[root@dm log]#
手工启动：
[dmdba@dm bin]$ ./dmserver ‘/dm/dmdbms/data/dave/dm.ini’
file dm.key not found, use default license!
version info: develop
Use normal os_malloc instead of HugeTLB
Use normal os_malloc instead of HugeTLB
DM Database Server x64 V8 startup…
Database mode = 0, oguid = 0
License will expire on 2020-09-16
file lsn: 0
ndct db load finished
ndct fill fast pool finished
iid page’s trxid[1002]
NEXT TRX ID = 1003
pseg_collect_items, collect 0 active_trxs, 0 cmt_trxs, 0 pre_cmt_trxs, 0 active_pages, 0 cmt_pages, 0 pre_cmt_pages
pseg_process_collect_items end, 0 active trx, 0 active pages, 0 committed trx, 0 committed pages
total 0 active crash trx, pseg_crash_trx_rollback begin …
pseg_crash_trx_rollback end
purg2_crash_cmt_trx end, total 0 page purged
set EP[0]'s pseg state to inactive
pseg recv finished
nsvr_startup end.
aud sys init success.
aud rt sys init success.
trx: 2004 purged 1 pages
trx: 2023 purged 1 pages
trx: 2024 purged 1 pages
trx: 2025 purged 1 pages
trx: 2026 purged 1 pages
trx: 2037 purged 1 pages
trx: 2157 purged 1 pages
trx: 2177 purged 1 pages
trx: 2178 purged 1 pages
trx: 2179 purged 1 pages
trx: 2180 purged 1 pages
trx: 2181 purged 1 pages
trx: 2182 purged 1 pages
trx: 2184 purged 1 pages
trx: 2186 purged 1 pages
trx: 2189 purged 1 pages
trx: 2195 purged 1 pages
trx: 2205 purged 1 pages
trx: 3072 purged 1 pages
trx: 3073 purged 1 pages
trx: 3074 purged 1 pages
trx: 3075 purged 1 pages
trx: 3087 purged 1 pages
trx: 3089 purged 1 pages
trx: 3090 purged 1 pages
trx: 3091 purged 1 pages
trx: 3096 purged 21 pages
trx: 3123 purged 1 pages
trx: 3124 purged 1 pages
trx: 3125 purged 1 pages
trx: 3126 purged 1 pages
trx: 3132 purged 1 pages
trx: 3134 purged 1 pages
trx: 3136 purged 1 pages
trx: 3141 purged 1 pages
trx: 3146 purged 1 pages
trx: 3151 purged 1 pages
trx: 3153 purged 1 pages
trx: 3156 purged 1 pages
trx: 3158 purged 1 pages
trx: 3170 purged 1 pages
trx: 3172 purged 1 pages
trx: 3174 purged 1 pages
trx: 3179 purged 1 pages
trx: 3182 purged 1 pages
trx: 3185 purged 1 pages
trx: 3188 purged 1 pages
trx: 3197 purged 1 pages
trx: 3198 purged 1 pages
trx: 3347 purged 1 pages
trx: 3349 purged 7 pages
trx: 3358 purged 1 pages
systables desc init success.
ndct_db_load_info success.
nsvr_process_before_open begin.
nsvr_process_before_open success.
total 0 active crash trx, pseg_crash_trx_rollback begin …
pseg_crash_trx_rollback end
SYSTEM IS READY.
之后就可以用服务启动了。
DMAP 服务异常
DMAP 是达梦数据库辅助插件服务。在 DM 实例运行时依赖该服务。 关于服务类型参考达梦数据库服务说明，在创建 DM 实例会自动创建 DMAP 的服务，一般正常重启即可。
[root@dm log]# systemctl start DmAPService.service
但如果之前就已经异常，此时如果重启失败，可以先删除 DM_HOME/bin 目录下的 DM_PIPE* 文件，再重启。
[dmdba@dm bin]$ pwd
/dm/dmdbms/bin
[dmdba@dm bin]$ ll DM_PIPE*
prwx------. 1 dmdba dmdba 0 Oct 29 13:52 DM_PIPE_DMAP_LSNR_RD
prwx------. 1 dmdba dmdba 0 Oct 29 13:52 DM_PIPE_DMAP_LSNR_WR
[dmdba@dm bin]$
这些管道文件在重启 DMAP 后会自动创建。

故障处理
数据库表数据误删，如何恢复
首先确定是什么时候做的操作？数据库是否有备份？有备份的情况下数据可以恢复到任意时间点。如果没有备份一般是无法恢复的。
数据库系统必须保证即使发生故障，也可以保障数据的完整性和一致性。支持故障恢复的技术主要是日志，日志以一种安全的方式记录数据库系统变更的历史信息，一旦系统出现故障，数据库系统可以根据日志将系统恢复至故障发生前的某个时刻。数据库系统的日志分为两种类型：
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，并记录下来。
[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 工具的具体情况，如下图所示：

将 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。
【解决方法】：
可访问达梦云适配中心下载试用，下载最新版数据库，安装的时候选择驱动，将现在的出现问题的驱动换成最新的驱动。
打开管理工具报错：Locking is not possible in the directory

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

控制文件 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 损坏的一个报错信息；
日志：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 日志损坏
dd if=dminit20210203144245.log of=TEST01.log

查看初始化日志，观察初始化参数，重新初始化一个新的实例并前台启动一次
./dminit path=/home/dmdba/data/dmdbms port_num=5237 db_name=TEST
./dmserver /home/dmdba/data/dmdbms/TEST/dm.ini
查看故障库的 db_magic 值和 pemnt_magic 值
./dmmdf type=1 file=/home/dmdba/data/TEST/SYSTEM.DBF

备注：db_magic：数据库魔数；pemnt_magic：数据库永久魔数
修改新库的 db_magic 值和 pemnt_magic 值并保存
./dmmdf type=2 file=/home/dmdba/data/dmdbms/TEST/TEST01.log

将修改后的 redo 挪到故障库下，尝试启动数据库
故障库：mv TEST01.log TEST01.log_old
新库：cp TEST01.log /home/dmdba/data/TEST/

此时已经启动起来的数据库仍然存在隐患，应立即完成数据的迁移工作，防止再次发生宕机事故。
迁移方式采用 DTS 或逻辑导出导入。
在新的库上需要和故障库创建相同的用户及密码，并为每个用户指定表空间，分配数据文件。
–在已暂时启动的故障库
–查询用户名，用户默认表空间，表空间所在路径
select username,DEFAULT_TABLESPACE,profile from dba_users;

数据库页损坏
1.如果数据库仍可以启动
实例正常启停一次，然后执行下列语句：
./dmdbchk path=/home/dmdba/data/TEST/dm.ini
bin 目录下会生成一个 dbchk_err.txt，可能会记录有一些索引或者表错误，可以重建再做 dmdbchk 。
1.如果实例不能启动
关闭 IGNORE_FILE_SYS_CHECK 参数
备注
IGNORE_FILE_SYS_CHECK 参数说明：
默认 0，检查文件系统。1，不检查文件系统。
磁盘问题导致故障
【问题描述】：
os_file_flush error!handle:3,code:30,desc:Read-only file system/error 请联系存储厂商进行处理。
磁盘空间不足导致故障：日志报错 out of space
日志报错：
tablespace 7 fail to extend.Please check disk space or extend attribbute of data files.
tablespace 6 fail to extend.Please check disk space or extend attribbute of data files.
ARCH_DEST[/opt/dmdbms/data/DAMENG/arch] will be out of space.

【问题解答】：
1.首先：df -h 查看空间。
定时删除备份有没有执行？–如果没删，可以删除。
归档上限有没有设置？–如果没设置，可以设置归档上线。
1.如果定时删除备份已执行，并且归档上线已经设置合适值，此时需要争取加大磁盘空间。
使用 Manager 管理工具的时候，出现卡顿的情况
应用出现卡顿一般是由于阻塞造成。但是 Manager 管理工具如果产生阻塞的事务，一般只是报错锁超时，或者当前窗口执行的语句一直在执行状态。
Manager 管理工具出现卡顿的情况，常见于两种场景：
1.打开管理工具的机器的内存或 CPU 资源不足;
2.旧版本客户端在执行耗时很长的 SQL 或执行耗时很长的操作时，可能会存在卡顿的情况。

高可靠常见问题
Data Watch
数据守护启动和关闭顺序
启动数据库举例：
启动数据库
以 Mount 方式分别启动主、备数据库：./dmserver /DM/data/DAMENG/dm.ini mount。
修改数据库模式
登录主数据库修改数据库模式为：PRIMARY。
alter database primary;
登录备数据库修改数据库模式为：STANDBY。
alter database standby;
启动守护进程
启动主机 DM1 上的守护进程：./DmWatcherServiceGRP1_RT_01 start。
启动备机 DM2 上的守护进程：./DmWatcherServiceGRP1_RT_02 start。
启动监视机 DM_W 上的监视器：./dmmonitor /home/dmdba/dmdbms/data/DAMENG/dmmonitor.ini。
关闭数据库举例：
退出 DM 数据守护
退出监视器
关闭备机的守护进程
关闭主机的守护进程
关闭主机实例
关闭备机实例
dmmonitor 进入监视器查看各个节点状态
【问题描述】：
/dmmonitor 监视器作为服务已经开机启动情况下，如何进入监视器查看各个节点状态。
数据守护后台启动监视器后，怎么进入。
读写分离集群部署了两套，确认第二套集群启动确认监视器时报错只能启动一个。
【解决方法】：
确认监视器只能配置一个，配一个新的非确认监视器。
主备集群魔数不一样，如何解决
【问题详情】：
集群搭好了，但是两边的魔数不一样，主库写进去的备库查询不到，查看监控日志是归档出错了/配置主备，两个库安装以及怎么确保魔数一致？
【问题解答】：
不同版本的 DM 主备库数据准备的方式不一样。
需要参考安装目录下的 doc 目录下–“DM 数据守护与读写分离集群V”– 7.1 数据准备章节。
以前的版本主备数据准备是可以用数据文件拷贝以及备份还原方式的。最新的版本是必须先通过备份还原方式同步各数据库的数据。