实例启动问题

本章节主要对达梦数据库实例启动常见问题进行分析和处理，以下提供达梦数据库实例启动常见问题的分析和解决思路供用户参考。除此之外，用户还可前往达梦技术社区参与更多问题讨论。

正文

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.ini 文件路径错误导致。

【问题解决】

检查数据库在启动时指定的 dm.ini 文件是否正确。

启动 DmAPService 服务失败

【问题解决】

Windows 安装 DM 数据库，在安装完成的最后一步报错：“启动 DmAPService 服务失败!"可以尝试以下方法解决：

报这个错没关系，先点击【确定】完成。启动服务的时候可以手动启动。
以管理员方式运行安装程序，同时检查授权 key 文件是否过期、操作系统的时间是否正确。
查看日志，详细查看日志目录 (D:\dmdbms\log) 下的相关日志文件，分析日志中的报错信息。

启动时数据库报 open files 连接超出资源限制

【问题描述】

数据库启动日志报错 open files 连接超出资源限制，具体截图如下：

报错信息

【问题解决】

该报错信息写入 dmdbms/log 里面的服务启动日志，可从可以发现是 open files 超出系统限制导致报错。有时按照标准修改了 /etc/security/limits.conf，资源赋值为 65536 也未必够，可以将值修改得更大即可解决。

使用 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 弹出图形化界面

执行 dmservice.sh

图形化界面使用方式

右键 DM 数据库实例服务点击【启动】即可启动数据库服务。

图形化启动数据库服务

DM 数据库如何前台启动

【问题解决】

进入 DM 安装目录下的 bin 目录，直接打开应用程序 dmserver 就可以启动 DM 数据库。或者先打开 Windows 命令提示符工具，在命令工具中执行命令进入 DM 服务器的目录，再执行 dmserver 的命令启动 DM 数据库。

##进入数据库安装目录下的bin目录
cd /home/dmdba/dmdbms/bin
##前台启动数据库
./dmserver /data/dmdata/DAMENG/dm.ini

详细步骤可以参考《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 服务查看器”如下图所示：

服务查看器

通过系统服务启动数据库

Windows 环境：

通过在【运行】输入 services.msc 打开【服务】，在服务中找到 DmService 开头的服务进行启动和关闭数据库，如下图所示：

服务查看器

Linux 环境：

Linux 使用系统服务启动和关闭数据库的方法前提是系统注册了数据库服务。关于注册数据库服务知识请参考《DM_Linux 服务脚本手册》，手册位于数据库安装路径 /dmdbms/doc/special 文件夹下。

DM6 版本启动数据库方法如下：(使用 root 用户)

查看 DM 数据库服务：\# chkconfig --list| grep DmService

查看数据库服务

启动数据库服务：\# service DmServiceDAMENG start

停止数据库服务：\# service DmServiceDAMENG stop

确认服务是否启动：\# ps -ef | grep dmserver

DM7 版本启动数据库方法如下：(使用 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 改小一些。

数据库开机自启

【问题解决】

如果是图形化的方式创建实例：图形化工具会自动创建开启自启服务，所以不需要再进行其他操作就可以让实例开机自启。
如果是命令行的方式创建实例：需要自己手动注册开机自启的服务，注册自启服务之后，可以实现开机自启。如果没有注册开机自启服务，则不会实现实例的开机自启功能。

启动/重启 DM 数据库失败

【问题解决】

有以下可能原因：

启动失败：用户可能没有初始化，需要初始化数据库。可以参考达梦数据库安装及初始化
参考《DM 系统管理员手册》第 7 章-启动和关闭数据库，（手册位于数据库安装路径 /dmdbms/doc 文件夹下。）看是否启动方式错误。或者可以参考 Linux 平台达梦数据库启动与关闭
其他原因造成的启动/重启失败，可查看数据库安装路径下/log 文件夹中的日志，通过分析报错时间段内的错误信息，来定位具体导致的原因。也可以将相关日志发给 DM 技术服务人员进行分析定位。

建库实例/初始化实例参数设置

【问题解决】

数据库实例初始化参数中有 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 数据库在初始化实例时有勾选大小写敏感选项。

初始化参数

初始化完成后是无法修改大小写敏感的，只能删除该实例重新初始化，所以在初始化时一定要确认选择。

初始化 SSL 环境失败

【问题解决】

将 dm.ini 里面的 ENABLE_ENCRYPT 修改为 0 后，重启实例即可解决。

更多 DM 数据库 SSL 相关问题请参照以下内容：

请详细参考：达梦数据库配置 SSL 认证加密

请详细参考：达梦数据库配置 SSL 认证加密登录测试以及问题处理

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 工具有疑问可以通过执行 ./dminit help 查看详细使用方法及参数说明，也可参考数据库安装目录下 doc 目录中《DM8_dminit 使用手册》。

远程关闭数据库

【问题解决】

首先需要远程连接到目的端的数据库界面。

如果数据库实例是前台启动，需要关闭前台启动的界面，即在前台界面输入 exit，待最后出现 DM Database Server shutdown successfully 信息并且重新返回命令行模式即表示停止成功。

停止成功信息

如果数据库实例是后台脚本启动，需要使用命令 cd 到安装数据库的 bin 目录下，执行脚本 ./服务名 stop，就可以关闭数据库了，例如，启停脚本为 dmserverd 则数据库停止命令为 ./dmserverd stop，待出现绿色 OK 则停止成功。

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 用户正常前台启动后（必须步骤），操作步骤如下：

复制数据库实例服务脚本 dmserverd，命名为 DmInstanceServiceDAMENG 并修改，修改 path 值为 dm.ini 路径（必须），dm_home 设置为 dm 主程序安装路径（必须），svc_porg 设置为数据库实例名（可选推荐）。
将脚本 DmInstanceServiceDAMENG 复制到 /etc/rc.d/init.d 目录下。

cp/opt/dmdbms/bin/DmInstanceServiceDAMENG  /etc/rc.d/init.d/DmInstanceServiceDAMENG

赋予服务脚本 DmInstanceServiceDAMENG 可执行权限。

chmod 777 /etc/rc.d/init.d/DmInstanceServiceDAMENG

chkconfig \--add DmInstanceServiceDAMENG
chkconfig DmInstanceServiceDAMENG on
chkconfig \--list DmInstanceServiceDAMENG

后台启动达梦数据库实例服务，查看服务状态，关闭实例服务。

service DmInstanceServiceDAMENG start
service DmInstanceServiceDAMENG status
service DmInstanceServiceDAMENG stop

服务启动报错：-112 证书过期

【问题解决】

因为数据库服务授权过期，可以联系达梦咨询热线 400 991 6599 转 1 号线申请授权 key 文件。

启动报错：Global parameter value of RT_TARGET is illegal, use min value

【问题描述】

之前服务是可以正常启动的，服务器异常断电后，再启动就启动不了：

服务启动失败

【问题解决】

实例启动失败的问题，需要客户提供数据库日志进行判断。报错显示：“RT_HEAP_TARGET is illegal,use min value”。RT_HEAP_TARGET 的含义是会话上用于动态对象存储的 RT_HEAP 最大可扩展到的大小。检查 dm.ini 文件中 RT_HEAP_TARGET 的设置值，将该值改小以尝试启动数据库。若仍旧无法启动，则需要通过数据库日志进行详细定位。

windows 无法启动 DmAPService 服务。错误 3：系统找不到指定的路径

【问题解决】

避免杀毒软件、安全卫士等防护软件误删 DmAPService 服务。可以用 DBCA 工具重新注册一下这个服务，再启动，也可以参考一下达梦数据库服务说明。

windows 系统初始化数据库实例后，服务查看器里是空白，没有任何服务

【问题解决】

查看当前操作系统是否有杀毒软件，需要将数据库加入到白名单，然后重新注册服务。

启动数据库报错:failed at step EXEC spawning…:No such file or directory

【问题描述】

数据库无法启动，报错截图如下：

服务启动失败

【问题解决】

该报错是因为启动数据库的服务被删除了，重新注册服务即可。可以参考：注册服务。

启用达梦服务报错 out of memory

【问题解决】

该问题一般是由于系统内存不足导致，可以通过调小 dm.ini 配置文件中 BUFFER 值来尝试启动数据库。

数据库日志报错：main_thread mem_malloc_ex2(1048640) out of memory

【问题描述】

数据库服务日志报错

ERROR database p0000001217 main_thread mem_malloc_ex2(1048640) out of memory!,fail to e memory OS

【问题分析】

一般对于此问题是由于数据库在安装过程中，安装前没有检查操作系统参数引起。

【问题解决】

将内核的内存分配参数 overcommit_memory 设置为 0 即可。具体方法如下：

1.查看内存分配参数 overcommit_memory 的值。

cat /proc/sys/vm/overcommit_memory

2.临时修改一个内核对内存分配的一种策略。

echo 0 > /proc/sys/vm/overcommit_memory

3.永久修改方法。

编辑 /etc/sysctl.conf ，修改 vm.overcommit_memory=0，然后执行 sysctl -p 使配置文件生效。

vi /etc/sysctl.conf
vm.overcommit_memory=0
Sysctl -p 
---是配置文件生效
cat /proc/sys/vm/overcommit_memory
--查看是否修改成功

vm.overcommit_memory 参数说明：

vm.overcommit_memory=0 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
vm.overcommit_memory=1 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
vm.overcommit_memory=2 表示内核允许分配超过所有物理内存和交换空间总和的内存。

移动数据文件后启动数据库报错：Server key decrypt failed

【问题描述】

移动数据文件后启动数据库报错，具体报错截图如下：

服务启动失败

【问题解决】

找到 dm_service.prikey 文件，和数据文件放在同一目录，然后重启数据库。

数据库启动报错：libgcc_s.so.1 must be installed for pthread_cancel to work

【问题描述】

DM 数据库无论后台服务脚本启动，还是前台启动都会报 libgcc_s.so.1 must be installed for pthread_cancel to work 的错误，前台报错如下：

[dmdba@DATABASE bin]$ ./dmserver /soft/dmdbms/data/DAMENG/dm.ini
file dm.key not found, use default license!
version info: develop
DM Database Server x64 V8 1-2-94-21.11.11-150650-10038-ENT  startup...
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
Database mode = 0, oguid = 0
License will expire on 2022-11-11
libgcc_s.so.1 must be installed for pthread_cancel to work
Floating point exception (core dumped)

【问题分析】

该报错可能由两种情况导致：

在达梦服务中部署了 oracle19c 时，安装 libnsl 组件就会出现该问题。

具体分析：在部署 oracle19c 时，执行./runInstaller，无论调用图形界面还是试用静默安装，都是报错，提示：

/soft/oracle/app/oracle/product/19.3.0/db_1/perl/bin/perl: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

该问题实际原因是缺失库文件导致，需要安装 libnsl 库文件。

是由于操作系统版本较老，而数据库版本较新，操作系统无法识别数据库安装目录下的 bin 目录下的 libxqilla.so、libproj.so 两个方言文件导致。

【问题解决】

第一种情况的解决办法：

可通过以下两种方式安装 oracle19c 需要的库文件：

方法一：通过软链接安装

[root@localhost lib64]# ls -lrt /usr/lib64 | grep libnsl
lrwxrwxrwx.  1 root root       15 Aug 12  2018 libnsl.so.2 -> libnsl.so.2.0.0
-rwxr-xr-x.  1 root root   116408 Aug 12  2018 libnsl.so.2.0.0
lrwxrwxrwx   1 root root       26 Jan 14 05:31 libnsl.so.1 -> /usr/lib64/libnsl.so.2.0.0

方法二：yum 直接安装。默认 linux 会有 libnsl.so 的动态库，如下：

--- 查看 Linux 中的 libnsl 库文件
[root@localhost lib64]# ls -lrt /usr/lib64 | grep libnsl
lrwxrwxrwx.  1 root root       15 Aug 12  2018 libnsl.so.2 -> libnsl.so.2.0.0
-rwxr-xr-x.  1 root root   116408 Aug 12  2018 libnsl.so.2.0.0

---yum 安装库文件
[root@localhost lib64]# yum install libnsl

---安装后会出来新的 libnsl 库文件
[root@localhost lib64]# ls -lrt /usr/lib64 | grep libnsl
lrwxrwxrwx.  1 root root       15 Aug 12  2018 libnsl.so.2 -> libnsl.so.2.0.0
-rwxr-xr-x.  1 root root   116408 Aug 12  2018 libnsl.so.2.0.0
lrwxrwxrwx   1 root root       14 Dec 14  2018 libnsl.so.1 -> libnsl-2.28.so
-rwxr-xr-x   1 root root   150544 Dec 14  2018 libnsl-2.28.so

两种方式都能解决 oracle 安装时出现的该报错。但是，此时如果达梦数据库服务重启，则达梦数据库会报错：libgcc_s.so.1 must be installed for pthread_cancel to work。解决方案如下：

1.将 libnsl.so.1 组件移动到其他路径，比如：/home/oracle
2.将 libnsl.so.1 组件路径写入到 oracle 的环境变量 LD_LIBRARY_PATH 中。

[root@localhost bin]# ln -s /usr/lib64/libnsl.so.2.0.0 /home/oracle/libnsl.so.1

此时 DM 和 oracle 共存。达梦数据库启动不会报 libgcc_s.so.1 must be installed for pthread_cancel to work 的错，oracle 调用 runInstaller 或 sqlplus 时也不会报 error while loading shared libraries: libnsl.so.1 的错误。

第二种情况解决办法：

更换数据库版本较低的版本进行安装。
删除数据库安装目录下的 bin 目录下的 libxqilla.so、libproj.so 方言文件。

使用脚本启动数据库出现[FAILED]，且无日志生成

【问题描述】

使用启动脚本启动数据库时，出现[FAILED]，服务端日志 dm_DMSERVER_20**.log 无日志记录，生成了文件 DmService_DMSERVER.log 文件，但是未记录任何内容。

【问题解决】

通过排查确认是由于无法切换到 dmdba 用户导致，通过以下命令查看用户信息：

cat /etc/passwd |grep dmdba

显示信息为：
dmdba:x:103:105::/home/dmdba/dm:/bin/false
确认是由于 dmdba 用户被禁止登录，需要修改系统配置，修改方法：

usermod -s /bin/bash dmdba

使用 DmAPService 脚本启动 dmap 服务报错：failed to get ps

【问题描述】

使用 DmAPService 脚本启动 dmap 服务报错，报错信息：“failed to get ps!”，但是使用./dmap 命令前台启动 dmap 正常。

报错截图

【问题分析】

根据报错信息以及 DmAPService 服务脚本内容可以定位到报错发生的可能原因，可以直接在 DmAPService 脚本中查找报错信息 “failed to get ps!”。原因可能为服务脚本需要使用操作系统 ps 命令去执行相关操作，但是未能成功获取到 ps 命令。导致未能成功获取到 ps 命令的可能原因是：

ps 命令不存在；
ps 命令的路径与服务脚本中的路径不同；
dmdba 用户无权限使用 ps 命令。

【问题解决】

检查操作系统 ps 命令；
（1）可以使用命令 whereis ps 查看 ps 的路径；

[root@localhost ~]# whereis ps
ps: /usr/bin/ps

（2）根据上面查到的 ps 命令路径，检查 DmAPService 服务脚本中是否有包含该路径；
DmAPService 服务脚本会去判断操作系统下/usr/ucb/ps、/usr/bin/ps、/bin/ps 是否存在，只要其中一个存在即可使用对应的 ps 命令。

（3）检查 ps 命令的权限，普通用户是否有权限执行；

[root@localhost ~]# ls -l /usr/bin/ps
-rwx------ 1 root root 137672  3月 15  2020 /usr/bin/ps

正常情况下，ps 命令权限应为 755，当前环境 ps 命令为 700，所以普通用户没有 ps 命令执行权限。

（4）使用 dmdba 用户执行 ps 命令。

[dmdba@localhost bin]$ ps -ef|grep dms
-bash: /usr/bin/ps: 权限不够                     -----提示权限不够

使用 root 用户修改 ps 命令权限为 755；

[root@localhost ~]# chmod 755 /usr/bin/ps
[root@localhost ~]# ls -l /usr/bin/ps
-rwxr-xr-x 1 root root 137672  3月 15  2020 /usr/bin/ps

重新使用 dmdba 用户执行 ps 命令以及 DmAPService 脚本，命令执行成功。

[dmdba@localhost bin]$ ps -ef|grep dmap
dmdba      74008   73545  0 18:19 pts/1    00:00:00 grep dmap
[dmdba@localhost bin]$ ./DmAPService start
Starting DmAPService:                                      [ OK ]
[dmdba@localhost bin]$ ps -ef|grep dmap
dmdba      74032       1  0 18:19 pts/1    00:00:00 /home/dmdba/dm46/bin/dmap
dmdba      74045   73545  0 18:19 pts/1    00:00:00 grep dmap

使用 systemctl 对数据库配置开机自启以及进程守护

【问题解决】

配置开机自启

---使用 root 用户进行执行脚本
cd /home/dmdba/dm/dmdbms/script/root/
./dm_service_installer.sh -s /home/dmdba/dm/dmdbms/bin/dmserverd

添加进程守护
编辑服务启动脚本/usr/lib/systemd/system/dmserverd.service
添加进程守护：将 type 类型修改成 forking，并设置 Restart=always，RestartSec=60。
配置完成后的文件内容如下：

cat /usr/lib/systemd/system/dmserverd.service
[Unit]
Description=Dameng Database Service(dmserverd).

[Service]
Type=forking
PIDFile=/home/dmdba/dm/dmdbms/bin/pids/dmserverd.pid
ExecStart=/home/dmdba/dm/dmdbms/bin/dmserverd start
ExecReload=/home/dmdba/dm/dmdbms/bin/dmserverd restart
ExecStop=/home/dmdba/dm/dmdbms/bin/dmserverd stop
PrivateTmp=true
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target

---修改完成后执行如下配置生效配置:
systemctl enable dmserverd.service
systemctl daemon-reload

测试进程守护

利用 kill 杀掉数据库主进程，查看数据库是否恢复
（1）查看数据库状态，kill 数据库进程

kill 数据库进程

（2）查看数据库状态，数据库进程恢复正常

查看数据库进程

使用启动脚本进行关闭数据库，查看数据库是否恢复
（1）使用 dmserverd 脚本停止数据库

停止数据库

（2）60s 后查看数据库进程，数据库恢复正常

查看数据库进程

数据库升级后，服务脚本无法正常启动服务

【问题描述】

达梦数据库通过更换 bin 包的方式升级后，注册服务脚本中的 DM_HOME 路径错误，导致服务脚本无法正常启动服务。

【问题分析】

在对数据库升级过程中，新版本的 ./DmInstall.bin 包在解压后，未指定为之前的目录时，dmdbms/bin/service_template 中的各文件中 DM_HOME 初始值为 "_REPLACE_SELF_DM_HOME" ，此时若通过 dm_service_installer.sh 生成服务脚本，新生成的服务脚本 DM_HOME 将取到 service_template 目录中模板脚本的 "_REPLACE_SELF_DM_HOME" 值，会出现服务无法启动的问题。

【问题解决】

更换 bin 升级数据库版本后，首先替换掉 dmdbms/bin/service_template 目录下模板脚本的 DM_HOME 值为当前正确的 DM_HOME，再通过 dm_service_installer.sh 注册服务脚本；
通过 dm_service_installer.sh 注册服务脚本后，将生成的服务脚本中的 DM_HOME 替换为正确的路径。

数据库启动报错：(code=exited, status=203/EXEC)，服务启动失败。

【问题描述】

openEuler 部署达梦数据库完成后，启动服务失败，报错：“(code=exited, status=203/EXEC)”。

【问题分析】

操作系统日志提示：

systemd 执行 xxx 程序权限拒绝：

systemd[5646]: xxxservice: Failed to locate executable /root/server/xxx/xxx:Permission denied

SELinux 阻止 xxx 程序访问 xxx 文件：

setroubleshoot[5649]: SELinux is preventing (xxx)file xxx. For complete SELinux messages run:from execute access on thesealert -l XXXXX

通过分析日志信息推测该报错可能是由于 openEuler 的 SELinux 与防火墙 firewall 未关闭导致。

【问题解决】

关闭防火墙

关闭防火墙服务 systemctl stop firewalld.service
关闭防火墙开机自启 systemctl disable firewalld.service

关闭 SELinux

编辑配置文件 vim /etc/selinux/config ， 将 SELINUX=enforcing 改为 SELINUX=disabled
重启生效 shutdown -r now

openEuler 的 SELinux 与防火墙 firewall 关闭后，数据服务随机器重启自动启动。

实例服务开机自启超时

【问题描述】

完成数据库服务注册后，系统重启，数据库服务无法自启，查看服务状态出现错误信息：DmServiceDMSERVER.service start operation timed out.Terminating ，显示服务启动超时被系统终止。

如下图所示：

数据库服务可以在 bin 目录下进行启动。

【问题解决】

延长系统等待服务启停时间，在 /etc/systemd/system.conf 文件中将参数 DefaultTimeoutStartSec 与 DefaultTimeoutStopSec 都修改为 90s ，系统重启测试数据库服务可以正常开机自启。

vim /etc/systemd/system.conf

DM 服务开机自启失败

【问题描述】

DM 数据库注册了数据库后台服务，重启服务器后，磁盘也已经自动挂载，但是 DM 数据库后台服务没有自动拉起。检查数据库实例日志并没有发现任何异常报错，同时也查看了 bin 目录下该服务名注册的 dm.ini 路径正常，通过手动拉起可以正常启动数据库服务。

【问题分析】

该问题可能是由于磁盘自动挂载耗时过长导致服务器重启后，DM 数据库服务无法自动拉起数据库服务。

排查方法：通过 dmesg 命令查看服务器开机信息。

首先确认数据库 dm.ini 存放路径及所在磁盘。

通过 dmesg|grep sda 查看该磁盘挂载信息。

这里仅作为排查示例，该磁盘自动挂载总耗时 4.91S 正常耗时。

【问题解决】

如果是由于磁盘自动挂载耗时过长导致服务器重启，可通过在 /etc/rc.local 文件中添加 sleep 命令使 DM 数据库后台服务的命令延迟一段时间（该时间需大于磁盘挂载所需时间）再启动数据库服务。

找到 rc.local 文件并授予 777 权限。

按实际情况修改等待时间。

建议
DM 数据库后台服务无法拉起的时候，通过排查数据库实例日志等信息无发现异常信息，同时手动启动后台服务可以正常拉起时，不妨可以利用 dmesg|grep -i sda 命令进行查看磁盘挂载时间，如果磁盘存在较大延时的情况下，可以通过在 /etc/rc.local 文件中添加 sleep 命令让 DM 数据库后台服务的命令延迟一段时间（该时间需大于磁盘挂载所需时间）再启动数据库服务。

守护进程启动报错：“please change root or root to execute the service script,otherwise my be failed!”

【问题描述】

注册守护进程服务后，通过服务方式启动守护进程失败报错："please change root or root to execute the service script,otherwise my be failed!"，如下图一所示：

【问题分析】

通过分析服务文件 DmWatcherServiceDZQZDB2 发现其中的 DM_HOME 配置错误。

【问题解决】

可以参考如下两种解决方法进行处理：

方法一：删除该服务，重新注册。

通过命令 ./dm_service_uninstaller.sh -n DmWatcherServiceDZQZDB2，删除服务，重新注册服务后使用 dmdba 用户启动服务。

方法二：检查修改守护进程服务配置文件。

检查服务文件 DmWatcherServiceDZQZDB2 中的 DM_HOME 配置，是否与 dmdba 用户环境变量中 DM_HOME 一致。如果不一致，将服务文件中 DM_HOME 改成与用户环境变量中 DM_HOME 一致，再启动守护进程服务。