达梦数据库自杀问题，达梦数据库异常宕机，达梦数据自动关闭

参考原文1
参考原文2

异常中止类问题

Dmserver 进程运行过程中异常中止，进程在进程管理器中无法找到，一般可能由以下几种情况引起。

数据库主动自杀 (halt)

数据库实例在运行过程中会实时进行一些检查，比如授权过期信息、文件完整性信息、内存是否污染信息、数据页校验信息等。
这种情况下导致的进程中止，**我们需要检查数据库运行日志，搜索 halt 相关的内容 **，在 halt 内容附近会记录 halt 的详细原因，比如授权过期、文件不完整、内存被污染等。
虽然有一些 halt 可以通过简单处理后（比如授权过期）立即恢复服务，但有一些也是我们需要非常留意的，特别是内存校验失败、数据文件校验失败相关的信息，这种一般也是一些语句在操作时出现内存泄露或者写溢出等导致，我们需要结合数据库异常时生成的 core 文件进行分析，才能最终确认问题的症结。
这种情况下，我们可以通过以下方法解决：

需要数据库的运行日志来确认 halt 原因。
需要 core 文件的堆栈来确认发生异常时相关线程的函数调用顺序。
需要 dmrdc 对 core 文件分析的结果，如果异常发生在 SQL 执行线程上，dmrdc 工具有很大的概率将导致异常的语句挖掘出来。

数据库自身缺陷导致程序异常

这类问题一般比较严重，在数据库运行日志中大多数时候没有任何异常苗头就突然中断，数据库进程同时也会中止，仅在操作系统日志中会留下痕迹，如果数据库进程发生异常中止，并且在数据库运行日志中没有 halt 相关的信息，我们需要检查一下操作系统日志（一般是在 /var/log/message 中，需要 root 权限查看）中是否有 dm 的相关信息，可以通过关键字 dm 搜索*，或者通过数据库运行日志来确认异常前的数据库实例进程号来进行搜索，看操作系统日志中有没有记录相关的信息，如果是数据库自身问题导致的异常，一般会在操作系统日志的相关记录中有 segfault 、page fault 之类的信息。
这种情况下，我们可以通过以下方法解决：

需要操作系统日志的相关片段、数据库运行日志、gdb 查看 core 文件的堆栈信息、dmrdc 读取 core 文件的输出信息等。
通过 gdb 查看到的异常线程 LWP 号（gdb 打开 core 文件后输入 info thread 查看到的最后一个 LWP）可以在 dmrdc 的输出中找到对应的语句
需要确认一下语句是否为常用语句，如果不常使用，或者业务上能确认是新功能引入，可以暂时先通过关闭对应功能恢复服务，将收集的信息反馈给服务中心进行处理。

操作系统将数据库进程杀死

最常见的是 OOM KILL，这种情况在操作系统运行日志中可以明显的搜索到 oom 相关信息，并且 OOM 导致的进程异常是没有 core 文件的，因为 OOM 后系统是发送的 SIGTERML 对数据库进程进行杀死，这种情况案发生后，一般需要对数据的内存相关参数以及操作系统 OOM 评分优先级等设置进行调整。
另外一种就是 杀毒软件或者安全软件，对数据库的某些线程进行污染，导致线程异常，进而导致数据库进程异常，这种异常在操作系统运行中表现为可以搜索到 DM 相关的信息中包含 tained 等内容，如果出现这种情况，需要检查一下环境中是否存在安全软件对 DM 的进程进行监控等动作。

连接异常类问题

大多数情况下，连接异常类问题都是由于配置不正确导致。
具体的表现：在任务管理器中查看 dmserver 进程能够看到正常的 CPU 活动信息，查看磁盘网络等活动也存在正常的波动，但是新建连接连接数据库会提示网络通讯异常。**
最常见的原因：

dm.ini 中限制了最大连接数（相关参数 MAX_SESSIONS），**数据库连接达到该值后会拒绝创建新连接**，**在数据库运行日志中会发现 reach max session limit 相关日志。
由于操作系统的用户资源限制引起，我们通过命令 cat /proc/dmserver 的 pid/limits 可以查看到当前数据库进程的一些资源限制，我们主要关注的是 Open files 这个限制，由于在 DM 中每一个会话都是一个线程，一个线程在 Linux 中需要一个独立的文件句柄去控制，如果该项限制太小，会导致创建线程失败，从而在外部显示为连接数据库失败，这种情况一般在数据库运行日志中会有 create thread failed 相关信息，并且检查进程 limits 会发现 Open files 限制的较小，通过 ls -l /proc/dmserver 的 pid/fd|grep -c 命令，查看数据库已经打开的句柄以及等于或者超过 limits 值，由于这些 limits 是在进程启动时生效的，不能动态修改，如果已经出现了这种现象，只能修改相关的配置（ulimit -n 65535 等命令），并且重启数据库进程。
少数情况下，连接异常问题是由于数据库自身的缺陷引起，如果出现连接异常，检查数据库配置以及操作系统配置没有发现异常，并且连接数据库时长期不成功也不返回报错，这种情况大概率时由于数据库自身的原因导致客户端连接过程中发生资源等待或者死锁，导致登录消息一直陷入在资源/临界区等待状态，如果有类似的现象，在可能的情况下，我们可以使用 gdb/pstack 工具对数据库进行一个堆栈快照供服务中心新进分析，从堆栈快照中来分析相关登录在等待哪些临界区或者资源，并确认是否是数据库 BUG 导致。

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】上，我们可以在测试环境中尝试重现宕机现象，如果能够重现则可以将此问题交由达梦技术工程师来处理。