core文件及分析

在工作中如果遇到数据库宕机，根据已知日志无法定位出具体原因可以分析core文件。

快速安装gdb

sudo yum -y install gdb

如果数据库服务异常中断可按照以下步骤排查：

①查询数据库日志，排查错误。

②查询机器重启记录，看是否被重启。(last reboot)

③在达梦数据库bin目录下查看core文件分析(关于core文件以下有介绍)。

检查core文件是否打开：ulimit -a

阻止core文件生成：ulimit -c 0

临时打开core 产生 ulimit -c  unlimited

永久打开 core 文件产生  

vi  /etc/security/limit.conf

最后追加

*  soft core unlimited 

测试使用core文件

①使用ps -ef|grep dmserver查出dmserver的进程。

通过kill -11杀掉该进程，在达梦安装bin目录下会产生core文件。

②在bin目录下输入 gdb -c core.4941用gdb分析core文件，可以看到进程4941的达梦服务是被信号11终止的。

③输入bt，显示当前的函数调用栈的所有信息

④gdb常用命令：

where   --查看程序出问题的地方

break <行数>   --在该行设立断点

info break   --显示断点信息

run   --运行GdbDebug

pwd   --显示当前所在目录

backtrace   --打印当前的函数调用栈的所有信息

1. 手动生成core文件

[dmdba@localhost bin]$ cd /opt/dmdbms/bin

[dmdba@localhost bin]$ ps ax|grep dmserver

122928 /opt/dmdbms/bin/dmserver /opt/dmdbms/data/DAMENG/dm.ini -noconsole

[dmdba@localhost bin]$ gdb dmserver

···

(gdb) attach 122928

        ···

(gdb) generate-core-file

        Saved corefile core.122928

(gdb) detach

        Detaching from program: /opt/dmdbms/bin/dmserver, process 122928

(gdb) quit

 

2. gdb分析core文件

[dmdba@localhost bin]$ cd /opt/dmdbms/bin

[dmdba@localhost bin]$ gdb dmserver core.122928

···

(gdb) bt

        ···

(gdb) THREAD APPLY ALL BT

        一直往下翻页查找到thread的最小一个值的lwp号

(gdb) quit

Quit

(gdb) thread

[Current thread is 1 (Thread 0xfff4c1e7f1e0 (LWP 13608))]

(gdb)

这种比较好用 最小lwp为13608

注意：如果不是本机的bin，core文件拷出来分析的话，必须要相同版本的bin，数据库版本相同，服务器cpu和操作系统也要一样！

 

3. dmrdc分析core文件

[dmdba@localhost bin]$ cd /opt/dmdbms/bin

[dmdba@localhost bin]$ ./dmrdc sfile=/data/core.6874 DFILE=/data/core6874.sql

然后会在bin目录下生成core_tmp.122928，该文件中存储着所有正在执行的SQL，可以根据core中最小的lwp号，来确定是哪条SQL卡住了。

4.core不全

如果有办法复现的话，比如执行某个sql报错，或者应用执行某个模块报错，可以gdb启动实施

gdb 启 DM

      gdb dmserver

       r   /xxx/xxx/xxx/dm.ini