首页 » ORACLE 9i-23ai, 系统相关 » Linux core.NNNN文件导致文件系统耗尽

Linux core.NNNN文件导致文件系统耗尽

在oracle rdbms on Linux的环境有时会在$ORACLE_HOME/dbs生成几十GB的core.NNNN的core dump文件，更甚至导致文件系统耗尽，影响oracle进程稳定性， core文件用于分析进程异常终止原因，不只是oracle数据库，在其它数据库环境也经常会产生，如openGauss系这类线程(threads) 式进程数据库如果遇到这类异常，就不会如oracle、postgresql这类进程(processes)式只影响某进程crash, 而是整个实例crash，这也是线程数据库缺点，但往往他们宣传时线程式时避而不谈。 下面就一个案例记录一下core分析过程。

要分析Oracle进程产生的core文件，可以按照以下步骤进行：

1. 确认core文件的位置：首先，确定core文件的存储位置。通常，core文件存储在Oracle实例的diag目录下的rdbms目录中，具体路径可能是CORE_DUMP_DEST/core_NNNNNN或$ORACLE_HOME/dbs

2. 收集相关信息：在开始分析之前，收集一些相关的信息，如操作系统类型和版本、Oracle数据库版本、核心文件生成的时间戳等。这些信息有助于更好地理解和分析core文件。

$ls –l core*
 -rw------- 1 oracle asmadmin 24750448640 Jul  7 22:09 core.25657

note:
注意文件产生的owner为oracle, 日期和文件名后的进程号

3. 使用gdb调试器：使用gdb调试器来分析core文件。在命令行中运行gdb命令，指定core文件的路径和Oracle可执行文件的路径。例如，可以使用以下命令启动gdb调试器：
gdb <program> <path_to_core_file>
在其它平台可以使用其它OS工具或oracle的stackx工具,参考《工具: 分析core dump file》

<program> 不一定是oracle，可以使用file <core_file> 或strings 查看core文件生成的程序，如果是oracle的<program>替换为<path_to_oracle_executable>

strings core.24587 |more
CORE
CORE
ora_p007_anbob2
ora_p007_anbob2 
SIGICORE
CORE
FILECORE
#/u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle
/u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle
/u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle
/SYSV00000000 (deleted)
/SYSV00000000 (deleted)
/SYSV00000000 (deleted)
/SYSV00000000 (deleted)
/SYSV00000000 (deleted)
/SYSV00000000 (deleted)
/SYSV00000000 (deleted)
/SYSV00000000 (deleted)
/SYSV00000000 (deleted)
/SYSV00000000 (deleted)
/SYSV3c5d86d8 (deleted)
/dev/shm/ora_3c5d86d8_2e7c4497_1_KSIPC_MGA_NMSPC_2_0_0.dat
/dev/shm/ora_3c5d86d8_2e7c4497_1_KSIPC_MGA_NMSPC_2_0_1.dat
/usr/lib64/libc-2.17.so
/usr/lib64/libc-2.17.so
/u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle

Note：
program 为/u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle， 产生的进程为ora_p007_anbob2 一个并行的slave进程.

4. 分析堆栈信息：一旦进入gdb调试器的交互界面，可以使用`bt`命令查看堆栈信息。堆栈信息可以帮助你确定在生成core文件时发生了什么，以及导致进程崩溃的原因。

5. 查看变量和内存信息：在gdb调试器中，可以使用`print`命令查看特定变量的值，或使用`x`命令查看内存的内容。这些命令可以帮助你进一步分析问题并了解进程崩溃的具体情况。

6. 分析日志文件：除了分析core文件，还应该查看Oracle数据库的日志文件（如alert日志、trace文件等），操作系统日志，CRS alert，以获取更多关于问题的信息。日志文件可能包含有关错误、异常和其他相关事件的详细信息。
这个案例中DB alert log并无报错，但在OS日志message中有报错信息.

Dec  3 16:45:47 host01 systemd: Started Session 4923884 of user ywjk.
Dec  3 16:45:47 host01 systemd: Starting Session 4923884 of user ywjk.
Dec  3 16:45:51 host01 abrt-hook-ccpp: Process 24587 (oracle) of user 800 killed by SIGABRT - dumping core
Dec  3 16:45:53 host01 systemd-logind: New session 4923885 of user ywjk.
Dec  3 16:45:53 host01 systemd: Started Session 4923885 of user ywjk.

Note:
这个消息意味着进程编号为24587的用户800的进程（oracle）被SIGABRT信号终止。SIGABRT是一个信号，它通常表示进程遇到了一个严重的错误或异常情况，需要终止。当进程收到SIGABRT信号时，它会执行一些清理操作然后终止。
在这种情况下，abrt-hook-ccpp是一个用于处理进程错误的工具。它可能会捕获到进程崩溃的信息，并将其记录下来core文件，以便后续分析和处理。进一步的分析可能需要查看相关的日志文件和堆栈信息来确定具体的问题和原因。

ABRT（Automatic Bug Reporting Tool）
abrt-hook-ccpp是ABRT（Automatic Bug Reporting Tool）工具集合中的一个组件。ABRT是一个用于自动收集、报告和处理程序崩溃的工具，它包含了多个组件和插件，其中之一就是abrt-hook-ccpp。

ABRT的主要目标是在程序崩溃时自动收集相关的信息，并生成崩溃报告，以便开发人员或系统管理员能够更方便地分析和处理问题。abrt-hook-ccpp是ABRT中用于处理C/C++程序崩溃的一个钩子（hook）。

当一个C/C++程序崩溃时，abrt-hook-ccpp会被触发，它会捕获崩溃时的关键信息，如堆栈信息、内存转储等，并将其记录下来。除了记录信息，abrt-hook-ccpp还可以执行其他操作，如生成崩溃报告、发送邮件通知、执行预定义的动作等。

Signal 6 (SIGABRT) = SIGABRT is commonly used by libc and other libraries to abort the program in case of critical errors. 
For example, glibc sends an SIGABRT in case of a detected double-free or other heap corruptions

Signal     Value     Action   Comment
──────────────────────────────────────────────────────────────────────
SIGABRT       6       Core    Abort signal from abort(3) And abort(3):

NAME
abort - cause abnormal process termination

也可以使用abrt的命令行工具查看信息

# abrt-cli list

id ff0bf165dbb7026e9b10a9116d15649594f94345
reason:         sshd killed by SIGABRT
time:           Tue 15 Oct 2019 04:19:21 PM CST
cmdline:        'sshd: root@notty' '' '' '' ''
package:        openssh-server-7.4p1-11.el7
uid:            0 (root)
count:          1
Directory:      /var/spool/abrt/ccpp-2019-10-15-16:19:21-52295
Run 'abrt-cli report /var/spool/abrt/ccpp-2019-10-15-16:19:21-52295' for creating a case in Red Hat Customer Portal

关于ABRT服务 参考https://buildmedia.readthedocs.org/media/pdf/abrt/latest/abrt.pdf

Core文件产生的一些限制
core产生的大小限制

# ulimit -S -c unlimited > /dev/null 2>&1

# vi /etc/security/limits.conf
        * soft core unlimited
* 表时所有用户coredump size无限制

# vi /etc/sysctl.conf
      kernel.core_pattern = /var/crash/core.%e.%p.%h.%t

/var/crash 表示core生成的路径,默认文件名是core.%p，可以改成 core.%e.%p.%h.%t
     %e - executable filename   
       %p - PID of dumped process
       %t - time of dump (seconds since 0:00h, 1 Jan 1970)
       %h - hostname (same as ’nodename’ returned by uname(2))

要确保配置的目录都有足够的权限 (e.g. /var/crash/).
如果修改了以上配置，sysctl -p系统生效，并且生启abrtd和abrt-ccpp 服务

 In Oracle Linux 5 6: 
# service abrtd restart
# service abrt-ccpp restart

In Oracle Linux 7:  
/bin/systemctl start abrtd.service
/bin/systemctl start abrt-ccpp.service

注：
Oracle Linux 不支持 Red Hat 自动错误报告工具 (ABRT) 提供的守护程序和功能。 ABRT 包和关联文件（例如 libreport）包含在发行版中以满足包依赖性，但不支持这些包中的功能。

对于oracle环境的abrt服务建议

通常oracle数据库进程的终止不希望abrt来协助生成core文件，至少目前还很少遇到借助core分析数据库问题，通常关键进程的crash在oracle自己的捕捉日志已经满足。我个人还是建议在oracle rdbms的环境禁用abrt服务或配置

1.禁用操作系统ABRT服务

systemctl stop abrtd
systemctl stop abrt-oops

systemctl disable abrtd
systemctl disable abrt-oops

2.abrt服务黑名单忽略oracle。

/etc/abrt/abrt-action-save-package-data.conf 中BlackListedPaths
--Or
/etc/abrt/plugins/CCpp.conf 中IgnoredPaths
重启abrt 服务生效
systemctl restart abrtd.service

需要注意的是，分析core文件可能需要一定的调试和系统知识，并且取决于具体的问题和环境。在处理core文件之前，建议先备份相关文件，以防止意外情况发生。如果你不确定如何正确分析core文件，建议寻求专业的支持或与Oracle技术支持团队联系。

打赏

,

对不起，这篇文章暂时关闭评论。

上一篇：

下一篇：