如何从core dump文件中提取call stack

今天的航班又取消了,没办法只能改了今天早一点的航班,因此今早吃完早饭就要赶往机场,早上醒的比较早,还够时间写一篇短一点的小文,就给大家介绍一个小技巧吧,前两天我用这玩意分析了一个自己公司实验室里的数据库问题。

DBA最怕遇到的问题是莫名其妙的core dump,遇到此类问题的时候往往会束手无策。我也经历过这个时期,遇到core dump除了开SR,就没有任何分析手段了。除非alert log火鹤其他trace文件里有什么蛛丝马迹。

不过core dump的时候,往往啥也没有,运气好的话能够从alert log里看到一些ora-7445,运气不好的话,啥也找不到。而要把几个GB的core dump文件上传到MOS上也十分痛苦,哪怕是传上去了,也可能那边分析不出什么来。时间长了,就只能学习一些相关的分析技巧,好在用debug还算熟练,刚刚工作那几年,帮助客户破解openvms上的操作系统,数据库等软件,对这玩意不陌生。

已经有一段时间没具体做过数据库运维的工作了,因为现在一线的工作都被弟兄们承担了。我只是猫在幕后一门心思做D-SMART,把这些年的经验梳理出来,供智能化运维工具使用。不过长时间不做具体的DBA工作,有时候还是有点手痒的。上周五晚上是平安夜,我一个人在南京,也没啥平安夜可过的,回家吃完饭,继续研究D-SMART的知识图谱。



如何从core dump文件中提取call stack

突然,微信智能助手收到了公司的一套11.2 RAC数据库的一个报警,文件系统的使用率存在问题。本来想让公司负责数据库运维的兄弟看一下,后来一想大家都在过平安夜,只有我自己没啥事,还不如自己来分析分析。



如何从core dump文件中提取call stack

通过DSMART发现确实u01目录已经100%了,到底是什么问题导致的呢。通过工具发现$ORACLE_HOME/dbs目录下产生了很多core dump。这种core dump本应该生成在 diag目录下的,可能是这个参数没设置,最后生成在dbs目录下了。从alert log,后台进程trace,CRS日志等方面没有找到任何异常,看样子只能分析core dump文件了。

分析core dump,最好的方法还是通过stackx工具,还有一个Oracle的内部工具dbtk,不过那个工具的11.2以后的版本好像很难找到。stackx是Oracle在十多年前开始提供的一个core dump分析工具,我以前也多次使用这个工具提取call stack。Stackx可以利用操作系统的debug工具从Oracle产生的core文件中提取call stack的堆栈。Oracle DBA都清楚call stack对于此类的故障分析是多么重要,如果我们找到了call stack,那么就更容易使用MOS去查找资料了。查了一下电脑上的stackx还是2008年下载的老版本,于是马上从官网下载了stackx的最新版本,2015年的V1.3。把工具拷贝到core dump所在目录,然后执行stackx <core>进行分析。



除了知道这个core dump是m000产生的,其他信息都没有获取到,因为core文件里没有执行文件的信息。我试着尝试了几个core文件,发现都是同样的输出,core文件也是ora_m000_orcl产生的。既然是m000产生的,那么先到MOS上查查CORE产生的资料吧,翻了半天,也没有找到问题类似的文章。于是只能找其他的方法了。

既然stackx解决不了问题,那么就只能手工debug了。实际上stackx就是调用OS里的debug工具来分析core文件,在Linux上可以使用gdb,也可以使用pstack。pstack的debug功能比较简单,不过用来分析core dump生成的原因比较快。从stackx pstack core.514159命令上我们可以看出m000是signal 6 ,abort方式退出的。

可能有些dba看到stackx没啥用就会放弃了。实际上也没必要,只要掌握一点点gdb的小技巧就可以搞定这个事情。要解决stackx无法分析core的方法只需要两步,首先使用file命令查看这个core是哪个image产生的,虽然我比较确定应该是oracle,不过检查一下肯定是没错的。

可能那个文件字太小了,我做个局部放大。可以明确的看出是db_112/bin/oracle。这正是我们安装11.2.0.4的RDBMS的地方。可能有朋友觉得有点奇怪,明明前面的目录是12.2的grid,为啥11.2.0.4的数据库会装载这个地方呢。这个GRID是前阵子刚刚从11.2.0.4升级到12.2的,之前这套GRID的ASM磁盘组里部署了一套10.2.0.5和一套11.2.0.4的RAC,最近需要搭建一个12.2的RAC环境做测试,公司的CEPH已经快用满了,于是只能和这两套RAC共用一个ASM ,于是只能把这套11.2.0.4的GRID升级为12.2。升级后的这个ASM磁盘组中承载了10g,11g,和19c三个数据库。

找到产生CORE的镜像,下一步就可以使用gdb 命令来分析这个CORE DUMP了。启动gdb之后,直接使用bt命令查看一下出问题时的堆栈信息。可以看出是dbkc_init/dbkc_init_bs_ctx上出现了问题。Abort前调用的skgdbgcra都是和集群有关的。M000出现类似问题很可能是和访问集群中的某些文件系统的权限有关。在Oracle升级过程中也经常会遇到一些类似的BUG。


在MOS上简单的搜索了一下,和这个堆栈有关的资料还是不少的,上面的这一篇是说因为diag目录的权限问题导致了core dump。


我马上看了一下,diag还真的权限有点问题,后面又检查了几个目录,好像问题还不是一点,看样子需要重新执行root.sh来解决这个问题了。12.2以前也没有怎么玩过,等下回有时间慢慢折腾着玩吧。

时间有限,就聊这么多吧,最后划下重点,遇到core dump,首先使用stackx分析,在LINUX下可以用gdb和pstack分别分析,可能看到不同的结果。如果stackx无效,那么先用file命令找到是哪个镜像出问题的,然后用gdb <img> <core>来分析就行了。这个方法不仅仅可以用于分析Oracle的问题,对于其他数据库如果遇到core dump的情况,也可以采取类似的方法分析。


如何从core dump文件中提取call stack》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/1142.html