[root@tzjk6 log]# tail -1000f dmhalt_TZJK_3385867_202605019_141119.dump
time: 2026-05-19 14:11:19.419
instance: TZJK
process_ID: 0003385867
sigterm_handler receive signal 11

<fatal thrd info>
thread_ID: 3386427
session: 0xffee102517e8
n_resource: 0
n_slock: 0
n_xlock: 0
enable_page_cache: 0
n_total_access: 0
recent_n_page: 0
recent_buf_ctls: 0xffede7ff9400
pages_n_fixed: 0xffede7ff9600
worker_type: N
local_time_zone: 480
uthr: 0xfffba3f2b1f0
lthd_cell: (nil)
pha: (nil)
<fatal session info>
sql: call TZJK.PROC_STG_STUDENT_INFO()
trx: 0xfffc8eecd960(trx_id: 51261242)
esess: null

这是实例服务异常宕机了啊，有几点建议，你考虑下：

一、如果是生产环境，建议尽快对数据库作全量备份，以避免因其他因素（尤其是分析问题原因过程中发生某些误操作）造成数据丢失。

二、参考上面 海嗨骇 提出方案，查找coredump文件，并通过gdb判断数据库内核错误位置

三、你前面说每小时都会宕机，那最好判断或查找 TZJK.PROC_STG_STUDENT_INFO 这个过程的调用位置，看是否存在定时调用，比如数据库定时任务或者操作系统有cron作业脚本什么的

四、如果条件允许，建议把前面的halt文件、coredump文件，加上 id_code 信息和存储过程脚本（注意去掉敏感内容）都贴上来，这样达梦的专家们在分析问题根因时参考资料能更全面些

1、先将存储过程call TZJK.PROC_STG_STUDENT_INFO()的业务停了；后续观察是否还会宕机；

以下两步建议协调本地技术老师，协助排查
2、排查数据库配置参数问题
准备测试环境，安装相同版本数据库还原存储过程sql相关表数据，执行sql（验证初始化环境dm.ini和生产环境dm.ini）是否会稳定触发宕机；
如果是参数问题，定位到引发宕机的数据库参数，调整触发异常参数后可以解决
3、排查版本问题
安装最新版本数据库还原存储过程sql相关表数据,执行sql验证是否会稳定触发宕机；
如果新版本不触发宕机，可以通过升级版本或者调整存储过程sql逻辑跳过来解决；