达梦core文件分析（学习笔记）

目录

1、core 文件生成

1.1 前置条件说明

1.2 关于 core 文件生成路径的说明

  1.3查看 core 文件的前置条件

2、查看 core 文件堆栈信息

2.1 使用gdb

2.2 使用达梦dmrdc

3、core 分析过程

3.1 服务端主动 core

3.2因未知异常原因导致的 core

4、测试案例

4.1测试环境

4.2生成core文件

4.3 core文件分析

---

1、core 文件生成

1.1 前置条件说明

        数据库作为系统基础软件，在运行过程中有可能会发生 core dump。 当数据库异常终止或崩溃时，将数据库进程此时使用的内存内容拷贝到磁盘文件中进行存储，以方便编程人员调试。

        注意，上述所说的“异常终止或崩溃”表示数据库可能遇到致命错误，无法按照预定程序逻辑继续执行下去，所以在进程彻底终止之前将其使用的内存区域转存到文件中,

        有时候可能需要手动生成 core 文件，记录下进程当前的内存信息，以便后续进行问题排查，此时可以通过 kill -11 pid 或者 kill –sigsegv pid 手动生成 core 文件。

1.2 关于 core 文件生成路径的说明

1）默认：core 文件默认的存储位置与对应的可执行程序在同一目录下

         core 文件默认的存储位置与对应的可执行程序在同一目录下，文件名是 core，达梦数据库相同。例如，达梦数据库程序目录为 /home/dmdba/dmdbms，则 core 文件生成的路径在 /home/dmdba/dmdbms/bin 下，core 文件名生成规则为 core.pid，其中 pid 表示数据库进程 id。

2）配置文件： /proc/sys/kernel/core_pattern

        也可以手动配置 core 文件的生成路径，需要修改配置文件 /proc/sys/kernel/core_pattern，例如修改生成 core 文件到 /tmp 目录，文件名为 core_pid：echo /tmp/core_%p > /proc/sys/kernel/core_pattern

3）使用sysctl配置

  配置到/etc/sysctl.conf或/usr/lib/sysctl.d/目录下

  例如：echo "kernel.core_pattern = /dm8/coredm/core-%e-%p-%s" >> /etc/sysctl.conf

 执行sysctl --system，使配置生效。

  1.3查看 core 文件的前置条件

1）数据库所在操作系统能够正常运行 gdb 工具。

        gdb 主要在 linux 系统下进行程序调试使用的。为了确保数据库发生 core dump 时能够正常进行分析和调试，应该确保数据库所在系统能够正常运行 gdb 工具，可以使用 gdb -version 进行验证，当出现 gdb 版本信息时表示当前系统能够正常使用 gdb 工具。

gdb -version

2）操作系统已打开生成 core 文件的开关。

        通过 ulimit -c 命令可以查看是否打开生成 core 文件的开关，但返回 0 时表示关闭，当返回数值或 unlimited 时表示已打开。需要注意的是，虽然 ulimit -c 设置具体的数值表示已打开生成 core 文件开关，但是强烈建议达梦数据库服务端设置 core size 设置为 unlimited。

打开生成 core 文件开关：在 /etc/security/limits.conf 应该配置如下内容：

*    soft   core    unlimited

*    hard   core    unlimited

2、查看 core 文件堆栈信息

        core 文件名生成规则为 core.pid，其中 pid 表示数据库进程 id。

        大多数情况下数据库发生 core dump 是因为异常 sql 执行导致，应该使用发生 core dump对应的 dmserver 版本进行 core 文件信息查看和分析，步骤如下：

2.1 使用gdb

使用 gdb 命令解析 core 文件。

gdb $DM_HOME/bin/dmserver core.31820

执行 bt 或 where 会显示对应的线程堆栈信息。

执行 thread apply all bt 可以显示所有线程的堆栈信息，获得 Thread 1 对应的线程号，即 LWP （light weight process，轻量级进程，可简单理解为子进程）号，具体方法如下：

set logging file <文件名>   #设置输出的文件名称

set logging on             #开始将调试信息将输出到指定文件

thread apply all bt        #打印所有线程栈信息

set logging off            #关闭到指定文件的输出

quit                       #结束gdb调试

2.2 使用达梦dmrdc

        使用达梦自带的 dmrdc 工具进行 core 文件分析，能够将数据库进程发生 core dump 时刻所有线程正在执行的 sql 语句分析出来。

./dmrdc sfile=$DM_HOME/bin/core.31820  dfile=$DM_HOME/bin/core_31820.txt

        在 core_31820.txt 中搜索记录的 号，对应的 sql 即为导致本次数据库进程发生 core dump 的 sql 语句。需要注意的是，该 sql 不一定为导致发生 core dump 的决定因素，与数据库中具体的数据记录、redo、undo、数据库缓存区等多种影响因素的具体状态有关，需要进一步进行验证。如果需要获取同一 session 和事务中之前 sql 语句的执行信息，可以根据日志中 sess 或 trxid 字段向上进行检索。

        补充：当由于配置不当未生成 core 文件时，或没有 gdb 无法分析 core 文件时，可以通过操作系统层日志去定位具体导致程序崩溃的相应进程号即号，根据此进程号可以在 dmsql 日志中查找相应 thrd: 执行的最后一条 sql 语句。

3、core 分析过程

3.1 服务端主动 core

        这一类 core dump 问题相对来说比较好定位问题，因为服务端主动 core 表示程序因某种资源不够或已知原因而发生的“自杀”行为，

        一般在达梦数据库运行日志或 core 堆栈中会出现 dm_sys_halt 的信息，这种情况下通过堆栈和日志信息便可以确定发生问题的原因。

3.2因未知异常原因导致的 core

        这一类 core dump 相对来说更加隐晦一些，因为这一类是服务端程序被迫发生的，例如内存访问越界、非法指针、堆栈溢出等问题，

        主要表现为达梦数据库运行日志检查点突然中断，没有任何信息，但这一类问题的原因往往是由某个 sql 语句引发的，只需要找到对应的 sql 语句即可。

        例如，对于如下 core 堆栈来说，可以看出，堆栈的当前帧为 dm_sys_halt_low() 表示是数据库服务端主动 core 的，一般对于主动 core 的问题

        在达梦运行日志中可以找到更为详细的提示信息，可以看到日志中打印的信息为“Redo log try flush over space”表示冲破日志环了。

        发生这样的情况，一般是数据库在执行一个大事务，而当前可用的 redo log 装不下这个事务的数据变化导致的，我们需要优先考虑减少 BDTA_SIZE 以及增大 RLOG_RESERVE_SIZE，之后才是增加 redo 日志或扩大 redo 日志来解决。

4、测试案例

4.1测试环境

操作系统版本：CentOS7.6

数据库版本：dm8_20240712

配置CORE文件路径，用root用户执行

echo "kernel.core_pattern = /dm8/coredm/core-%e-%p-%s" >> /etc/sysctl.conf

检查CORE文件开关

[dmdba@localhost ~]$ ulimit -c

unlimited

默认情况，core文件的配置是unlimited，如果需要配置可以修改/etc/security/limits.conf，例如：

dmdba    soft   core    unlimited

dmdba    hard   core    unlimited

4.2生成core文件

1）尝试用SQL生成core文件

SQL> select trunc(dbms_random.string(0,1000000000)) from dual;
select trunc(dbms_random.string(0,1000000000)) from dual;
[-6111]:Fail to cast string.
used time: 1.203(ms). Execute id is 0

查看core文件是否生成

[dmdba@localhost coredm]$ ll /dm8/coredm/
total 0

没有生成core文件，估计是目前的版本修复了。

2）用kill 生成core 文件

查看pid

ps -ef|grep dmdba
kill -11  25265
ll /dm8/coredm/

core文件名：core-dmserver-25265-8

4.3 core文件分析

1）用gdb分析

gdb  /dm8/dmdbms/bin/dmserver  /dm8/coredm/core-dmserver-25265-8

bt命令用于查看当前函数的调用堆栈信息

查看数据库日志

数据库被强制终止

2）使用达梦dmrdc工具

        达梦自带的 dmrdc 工具进行 core 文件分析，能够将数据库进程发生 core dump 时刻所有线程正在执行的 sql 语句分析出来。

/dm8/dmdbms/bin/dmrdc  sfile=/dm8/coredm/core-dmserver-25265-8  dfile=/dm8/coredm/rdc_25265-8.txt

cat /dm8/coredm/rdc_25265-8.txt

需要注意的是，上面的sql 是core dump发生时刻正在执行的sql，但不一定为导致发生 core dump 的决定因素，需要进一步进行验证。

本文结束！

2024.10.3

参考资料：https://eco.dameng.com/