Core 文件可以理解为进程异常退出时保存下来的“现场”。日志记录故障前发生了什么Core 保存故障发生时线程停在哪里GDB 用来查看调用栈dmrdc则可以尝试从达梦 Core 中提取活动 SQL。本文所有达梦实验都只适用于测试环境。kill -11 dmserver_pid会中断数据库服务不要在生产库随意执行。一、先确认 Core 能不能生成Core 能否生成主要看三个条件当前用户是否允许生成 Core、Core 文件写到哪里、目标目录是否有权限和空间。ulimit-ccat/proc/sys/kernel/core_pattern本次环境中ulimit -c为unlimitedCore 文件路径规则为/dmbak/dmcore/core-%e-%t-%p-%u.core其中%e是进程名%t是时间戳%p是 PID%u是用户 UID。因此后面生成的 Core 不会在当前目录而是在/dmbak/dmcore下。二、实验一空指针触发 SIGSEGV先用一个普通 C 程序制造空指针异常#includestdio.hvoidlevel3(void){int*pointerNULL;*pointer100;}voidlevel2(void){level3();}voidlevel1(void){level2();}intmain(void){printf(program will crash\n);level1();return0;}编译时加上-g这样 GDB 才能显示函数名和源码行号gcc-g-O0null_test.c-onull_test ./null_test程序输出program will crash后出现“段错误核心已转储”说明程序访问非法内存并生成了 Core。根据core_pattern实际文件为/dmbak/dmcore/core-null_test-1784399982-20585-1001.core用 GDB 打开时要传入程序文件和 Core 文件的绝对路径gdb ./null_test /dmbak/dmcore/core-null_test-1784399982-20585-1001.coreGDB 里最关键的是这几行Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000040114a in level3 () at null_test.c:6 6 *pointer 100;SIGSEGV表示非法内存访问null_test.c:6直接定位到*pointer 100;。继续执行bt可以看到完整调用链#0 level3 () at null_test.c:6 #1 level2 () at null_test.c:11 #2 level1 () at null_test.c:16 #3 main () at null_test.c:22调用栈从下往上读就是main - level1 - level2 - level3从上往下看则能看到程序最终在哪里崩溃。三、实验二abort 触发 SIGABRT第二个实验观察另一种退出方式程序自己主动中止。#includestdlib.hvoidstop_program(void){abort();}intmain(void){stop_program();return0;}编译运行后用对应 Core 打开gcc-g-O0abort_test.c-oabort_test ./abort_test gdb ./abort_test /dmbak/dmcore/core-abort_test-1784402270-21600-1001.core这次 GDB 显示的是Program terminated with signal SIGABRT, Aborted. #0 raise () from /usr/lib64/libc.so.6 #1 abort () from /usr/lib64/libc.so.6 #2 stop_program () at abort_test.c:5 #3 main () at abort_test.c:10SIGABRT和SIGSEGV不同。前者通常表示程序主动中止后者更多是非法内存访问。这里调用链是main - stop_program - abort - raise说明abort()内部通过raise()触发了SIGABRT。这个实验对分析数据库 Core 很有帮助如果堆栈中看到abort、raise或类似halt的函数不应简单理解成“这里崩了”而要回到数据库日志里找主动中止前的错误原因。halt可以理解为程序认为继续运行不安全时主动停下来。四、实验三手动触发 dmserver Core前两个实验解决的是“怎么看信号和调用栈”。接下来回到达梦数据库本身目标是练习一条完整链路构造活动 SQL - kill dmserver 生成 Core - GDB 导出全线程堆栈 - dmrdc 提取 SQL - 用 LWP 线程号关联 SQL 和堆栈这里的重点不是证明某条 SQL 会导致达梦崩溃。Core 的直接原因是人为执行kill -11SQL 只是为了让 Core 现场里有可观察的活动会话。1. 构造锁等待现场单纯执行大 SQL 不一定够慢。本次环境里千万级插入几十毫秒就结束了所以改用锁等待来稳定保留活动 SQL。会话 A 持有行锁不提交DROPTABLEIFEXISTST_CORE_LOCK;CREATETABLET_CORE_LOCK(IDINTPRIMARYKEY,C1INT);INSERTINTOT_CORE_LOCKVALUES(1,100);COMMIT;UPDATET_CORE_LOCKSETC1C1WHEREID1;会话 B 执行同一行的更新UPDATET_CORE_LOCKSETC1C11WHEREID1;会话 B 会一直等待会话 A 释放锁。此时另开终端查询dmserverps-ef|grepdmserver|grep-vgrep本次查到的进程号是22976dmdba 22976 1 0 04:04 ? 00:00:04 /dmdbms/bin/dmserver path/dmdata/DAMENG/dm.ini -noconsole2. 生成 dmserver Core确认是测试环境后执行kill-1122976ll /dmbak/dmcore/目录中生成了新的服务端 Corecore-dmserver-1784405790-22976-1001.core3. 用 GDB 导出线程堆栈gdb /dmdbms/bin/dmserver /dmbak/dmcore/core-dmserver-1784405790-22976-1001.core进入 GDB 后导出线程set pagination off set logging file /dmbak/dmcore/core_22976_stack.txt set logging on info threads thread apply all bt set logging off quit图中能看到大量 LWP 线程。很多线程停在pthread_cond_wait、pthread_cond_timedwait这在数据库服务端里很常见通常表示线程正在等待任务或事件。本次更值得关注的是后面和 SQL 对应的线程。堆栈文件中可以看到Thread 106 (LWP 23555): #0 pthread_cond_timedwait () #1 os_event2_wait_timeout_low () #2 trx4_waiting_timeout () #3 trx4_waiting_interval () #4 trx4_waiting () #5 nupd2_exec_clu_update_check_rec_visible () #9 nupd2_exec_update () #17 uthr_db_main_for_sess ()trx4_waiting表示事务等待nupd2_exec_update表示正在执行更新。这和我们构造的锁等待现场对应上了。4. 用 dmrdc 提取 SQLcd/dmdbms/bin ./dmrdcsfile/dmbak/dmcore/core-dmserver-1784405790-22976-1001.coreAnalysing: 当前偏移/文件总大小是扫描进度不是报错。未指定dfile时dmrdc在同目录生成了默认输出文件cat/dmbak/dmcore/core-dmserver-1784405790-22976-1001_tmp.core输出中有两条 SQL!#%*^$[23555]:UPDATE T_CORE_LOCK SET C1 C1 1 WHERE ID 1; !#%*^$[23384]:UPDATE T_CORE_LOCK SET C1 C1 WHERE ID 1;方括号里的数字就是线程号。23555对应会话 B 中被锁阻塞的更新23384对应会话 A 中持锁未提交的更新。再回到 GDB 堆栈里找LWP 23555就能把“SQL 文本”和“线程状态”关联起来。这一步是整个实验最有价值的地方dmrdc告诉我们现场有哪些 SQLGDB 告诉我们这些线程当时停在哪里。两者结合才能把 Core 从一堆地址和线程变成能理解的故障现场。五、排查时重点收集什么真实遇到达梦实例异常退出时建议至少保留这些材料Core 文件和对应版本的dmserver数据库版本、补丁号、安装目录dmserver运行日志、dmsql日志操作系统日志例如/var/log/messages、dmesgGDB 导出的全线程堆栈dmrdc输出文件故障时间、故障前业务操作、是否能复现。Core 分析不能只看一个点。SIGSEGV、SIGABRT、线程堆栈、SQL 文本都只是线索最终还要和日志、业务时间线、复现结果一起判断。几个材料和工具的定位可以这样区分材料或工具主要回答的问题注意点数据库日志故障前发生了什么先按故障时间过滤再看错误号、线程号和业务操作Core 文件进程异常时停在哪里需要和崩溃时同版本的dmserver一起分析GDB每个线程的调用栈是什么重点导出bt、info threads、thread apply all btdmrdcCore 中能否提取到活动 SQLSQL 是现场线索不等于最终根因六、总结通过这三个实验可以形成一个比较清晰的认识Core 保存的是进程异常时的现场GDB 负责把现场里的线程和调用栈展示出来dmrdc可以从达梦 Core 中提取活动 SQLSQL 出现在 Core 里只说明它和现场有关不等于它就是根因人为kill -11生成的 Core适合学习分析流程不适合直接推导数据库缺陷。数据库日志告诉我们故障前发生了什么Core 告诉我们故障时停在哪里。把日志、GDB 堆栈和dmrdc输出放在一起看才是达梦 Core 分析比较稳妥的方式。
Core 文件可以理解为进程异常退出时保存下来的“现场”。日志记录故障前发生了什么Core 保存故障发生时线程停在哪里GDB 用来查看调用栈dmrdc则可以尝试从达梦 Core 中提取活动 SQL。本文所有达梦实验都只适用于测试环境。kill -11 dmserver_pid会中断数据库服务不要在生产库随意执行。一、先确认 Core 能不能生成Core 能否生成主要看三个条件当前用户是否允许生成 Core、Core 文件写到哪里、目标目录是否有权限和空间。ulimit-ccat/proc/sys/kernel/core_pattern本次环境中ulimit -c为unlimitedCore 文件路径规则为/dmbak/dmcore/core-%e-%t-%p-%u.core其中%e是进程名%t是时间戳%p是 PID%u是用户 UID。因此后面生成的 Core 不会在当前目录而是在/dmbak/dmcore下。二、实验一空指针触发 SIGSEGV先用一个普通 C 程序制造空指针异常#includestdio.hvoidlevel3(void){int*pointerNULL;*pointer100;}voidlevel2(void){level3();}voidlevel1(void){level2();}intmain(void){printf(program will crash\n);level1();return0;}编译时加上-g这样 GDB 才能显示函数名和源码行号gcc-g-O0null_test.c-onull_test ./null_test程序输出program will crash后出现“段错误核心已转储”说明程序访问非法内存并生成了 Core。根据core_pattern实际文件为/dmbak/dmcore/core-null_test-1784399982-20585-1001.core用 GDB 打开时要传入程序文件和 Core 文件的绝对路径gdb ./null_test /dmbak/dmcore/core-null_test-1784399982-20585-1001.coreGDB 里最关键的是这几行Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000040114a in level3 () at null_test.c:6 6 *pointer 100;SIGSEGV表示非法内存访问null_test.c:6直接定位到*pointer 100;。继续执行bt可以看到完整调用链#0 level3 () at null_test.c:6 #1 level2 () at null_test.c:11 #2 level1 () at null_test.c:16 #3 main () at null_test.c:22调用栈从下往上读就是main - level1 - level2 - level3从上往下看则能看到程序最终在哪里崩溃。三、实验二abort 触发 SIGABRT第二个实验观察另一种退出方式程序自己主动中止。#includestdlib.hvoidstop_program(void){abort();}intmain(void){stop_program();return0;}编译运行后用对应 Core 打开gcc-g-O0abort_test.c-oabort_test ./abort_test gdb ./abort_test /dmbak/dmcore/core-abort_test-1784402270-21600-1001.core这次 GDB 显示的是Program terminated with signal SIGABRT, Aborted. #0 raise () from /usr/lib64/libc.so.6 #1 abort () from /usr/lib64/libc.so.6 #2 stop_program () at abort_test.c:5 #3 main () at abort_test.c:10SIGABRT和SIGSEGV不同。前者通常表示程序主动中止后者更多是非法内存访问。这里调用链是main - stop_program - abort - raise说明abort()内部通过raise()触发了SIGABRT。这个实验对分析数据库 Core 很有帮助如果堆栈中看到abort、raise或类似halt的函数不应简单理解成“这里崩了”而要回到数据库日志里找主动中止前的错误原因。halt可以理解为程序认为继续运行不安全时主动停下来。四、实验三手动触发 dmserver Core前两个实验解决的是“怎么看信号和调用栈”。接下来回到达梦数据库本身目标是练习一条完整链路构造活动 SQL - kill dmserver 生成 Core - GDB 导出全线程堆栈 - dmrdc 提取 SQL - 用 LWP 线程号关联 SQL 和堆栈这里的重点不是证明某条 SQL 会导致达梦崩溃。Core 的直接原因是人为执行kill -11SQL 只是为了让 Core 现场里有可观察的活动会话。1. 构造锁等待现场单纯执行大 SQL 不一定够慢。本次环境里千万级插入几十毫秒就结束了所以改用锁等待来稳定保留活动 SQL。会话 A 持有行锁不提交DROPTABLEIFEXISTST_CORE_LOCK;CREATETABLET_CORE_LOCK(IDINTPRIMARYKEY,C1INT);INSERTINTOT_CORE_LOCKVALUES(1,100);COMMIT;UPDATET_CORE_LOCKSETC1C1WHEREID1;会话 B 执行同一行的更新UPDATET_CORE_LOCKSETC1C11WHEREID1;会话 B 会一直等待会话 A 释放锁。此时另开终端查询dmserverps-ef|grepdmserver|grep-vgrep本次查到的进程号是22976dmdba 22976 1 0 04:04 ? 00:00:04 /dmdbms/bin/dmserver path/dmdata/DAMENG/dm.ini -noconsole2. 生成 dmserver Core确认是测试环境后执行kill-1122976ll /dmbak/dmcore/目录中生成了新的服务端 Corecore-dmserver-1784405790-22976-1001.core3. 用 GDB 导出线程堆栈gdb /dmdbms/bin/dmserver /dmbak/dmcore/core-dmserver-1784405790-22976-1001.core进入 GDB 后导出线程set pagination off set logging file /dmbak/dmcore/core_22976_stack.txt set logging on info threads thread apply all bt set logging off quit图中能看到大量 LWP 线程。很多线程停在pthread_cond_wait、pthread_cond_timedwait这在数据库服务端里很常见通常表示线程正在等待任务或事件。本次更值得关注的是后面和 SQL 对应的线程。堆栈文件中可以看到Thread 106 (LWP 23555): #0 pthread_cond_timedwait () #1 os_event2_wait_timeout_low () #2 trx4_waiting_timeout () #3 trx4_waiting_interval () #4 trx4_waiting () #5 nupd2_exec_clu_update_check_rec_visible () #9 nupd2_exec_update () #17 uthr_db_main_for_sess ()trx4_waiting表示事务等待nupd2_exec_update表示正在执行更新。这和我们构造的锁等待现场对应上了。4. 用 dmrdc 提取 SQLcd/dmdbms/bin ./dmrdcsfile/dmbak/dmcore/core-dmserver-1784405790-22976-1001.coreAnalysing: 当前偏移/文件总大小是扫描进度不是报错。未指定dfile时dmrdc在同目录生成了默认输出文件cat/dmbak/dmcore/core-dmserver-1784405790-22976-1001_tmp.core输出中有两条 SQL!#%*^$[23555]:UPDATE T_CORE_LOCK SET C1 C1 1 WHERE ID 1; !#%*^$[23384]:UPDATE T_CORE_LOCK SET C1 C1 WHERE ID 1;方括号里的数字就是线程号。23555对应会话 B 中被锁阻塞的更新23384对应会话 A 中持锁未提交的更新。再回到 GDB 堆栈里找LWP 23555就能把“SQL 文本”和“线程状态”关联起来。这一步是整个实验最有价值的地方dmrdc告诉我们现场有哪些 SQLGDB 告诉我们这些线程当时停在哪里。两者结合才能把 Core 从一堆地址和线程变成能理解的故障现场。五、排查时重点收集什么真实遇到达梦实例异常退出时建议至少保留这些材料Core 文件和对应版本的dmserver数据库版本、补丁号、安装目录dmserver运行日志、dmsql日志操作系统日志例如/var/log/messages、dmesgGDB 导出的全线程堆栈dmrdc输出文件故障时间、故障前业务操作、是否能复现。Core 分析不能只看一个点。SIGSEGV、SIGABRT、线程堆栈、SQL 文本都只是线索最终还要和日志、业务时间线、复现结果一起判断。几个材料和工具的定位可以这样区分材料或工具主要回答的问题注意点数据库日志故障前发生了什么先按故障时间过滤再看错误号、线程号和业务操作Core 文件进程异常时停在哪里需要和崩溃时同版本的dmserver一起分析GDB每个线程的调用栈是什么重点导出bt、info threads、thread apply all btdmrdcCore 中能否提取到活动 SQLSQL 是现场线索不等于最终根因六、总结通过这三个实验可以形成一个比较清晰的认识Core 保存的是进程异常时的现场GDB 负责把现场里的线程和调用栈展示出来dmrdc可以从达梦 Core 中提取活动 SQLSQL 出现在 Core 里只说明它和现场有关不等于它就是根因人为kill -11生成的 Core适合学习分析流程不适合直接推导数据库缺陷。数据库日志告诉我们故障前发生了什么Core 告诉我们故障时停在哪里。把日志、GDB 堆栈和dmrdc输出放在一起看才是达梦 Core 分析比较稳妥的方式。
)
