共计 584 个字符，预计需要花费 2 分钟才能阅读完成。
缘起
现场的故障，让我支持一下。
过程
第一次
通过简易的日志，定位到了函数文件，远程连到现场环境，直接 gdb 进程名，一直到函数 return，都没有 core 掉。
干得比较仓促，都没有再看看相关函数
第二次
吃完饭，睡过觉后，继续定位，毕竟现场的优先级高啊。
跟人沟通后，get 到两点思路，让现场确认一下
1、看下.config 的 CLTSERVID 的值和链路的值是不是不样，确认后都是 26。
2、调高日志级别，原来是 0（只显示错误的），让现场改成 3，最高可支持 9。这个后期得了解一下
第一次，我没有找到生成的 core 文件，也就没管，直接 gdb 了，后面就看了一下。
linux 下生成 core dump 文件方法及设置
ulimit - c 如果是 0，则无法生成 core dump，当然也可以用 ulimit - a 查看。用 ulimit -c 2048 去设置 core 的大小
让现场试了以上三招后，重新跑个进程，捞个日志来看看的，给我截图说这个错“ORA-00257: archiver error. Connect internal only, until freed”，是现场的生产环境连接不上库了，于是再次挂起。
最后
参考
段错误调试神器 – Core Dump 详解
关于 ORA-00257: archiver error. Connect internal only, until freed 错误的处理方法
履历
20190212 遇到的问题，写了第一次、第二次。
正文完
