1.查找到系统程序崩溃时产生的core文件：
[root@rac1 ~]# find /u01 -name core.* -exec ls -lthr {} \
-rw------- 1 root root 480M Sep 27 12:01 /u01/oracle/product/crs/log/rac1/crsd/core.3907
core文件大小为480M，文件还挺大的。所以，平时，如果遇到磁盘空间不足的时候，没准就是core文件在做怪呢！
2.定位出是由于哪个文件肆穗姿产生的core文件：
[root@rac1 ~]# find /u01 -name core.* -exec ls -lthr {} \|awk '{print $9}'|xargs file/u01/oracle/product/crs/log/rac1/crsd/core.3907: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'crsd.bin'
由以下命令，可以看出core.3907的产生，是由于'裂绝crsd.bin'文件引起的。
3.使用gdb对core进行追踪：
[root@rac1 ~]# gdb /u01/oracle/product/crs/bin/crsd.bin /u01/oracle/product/crs/log/rac1/crsd/core.3907GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
warning: Can't read pathname for load map: Input/output error.
warning: .dynamic section for "/lib/libdl.so.2" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /u01/oracle/product/crs/lib/libocr10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libocr10.so
Reading symbols from /u01/oracle/product/crs/lib/libocrb10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libocrb10.so
Reading symbols from /u01/oracle/product/crs/lib/libocrutl10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libocrutl10.so
Reading symbols from /u01/oracle/product/crs/lib/libhasgen10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libhasgen10.so
Reading symbols from /u01/oracle/product/crs/lib/libclntsh.so.10.1...done.
Loaded symbols for /u01/oracle/product/crs/lib/libclntsh.so.10.1
Reading symbols from /u01/oracle/product/crs/lib/libskgxn2.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libskgxn2.so
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libstdc++.so.5...done.
Loaded symbols for /usr/lib/libstdc++.so.5
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /u01/oracle/product/crs/lib/libnnz10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libnnz10.so
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `/u01/oracle/product/crs/bin/crsd.bin reboot'.
Program terminated with signal 6, Aborted.
[New process 4787]
[New process 4789]
[New process 4786]
[New process 4785]
[New process 4784]
[New process 4783]
[New process 4782]
[New process 4781]
[New process 4780]
[New process 4779]
[New process 4778]
[New process 4721]
[New process 4701]
[New process 4700]
[New process 4665]
[New process 4664]
[New process 4663]
[New process 4662]
[New process 4661]
[New process 4660]
[New process 4659]
[New process 4658]
[New process 4657]
[New process 4656]
[New process 4655]
[New process 4654]
[New process 4653]
[New process 4652]
[New process 4651]
[New process 4650]
[New process 4649]
[New process 4648]
[New process 4647]
[New process 4641]
[New process 4640]
[New process 4639]
[New process 4638]
[New process 4637]
[New process 4636]
[New process 4635]
[New process 4634]
[New process 4514]
[New process 3907]
#0 0x00389402 in __kernel_vsyscall ()
(gdb) where
#0 0x00389402 in __kernel_vsyscall ()
#1 0x009a1df0 in raise () from /lib/libc.so.6
#2 0x009a3701 in abort () from /lib/libc.so.6
#3 0x0099b26b in __assert_fail () from /lib/libc.so.6
#4 0x08363c8e in destr_detour5 () at clsThreadMain.cpp:70
#5 0x00af45ab in start_thread () from /lib/libpthread.so.0
#6 0x00a4acfe in clone () from /lib/libc.so.6
(gdb)
注意：上面的两行红色部分：
Core was generated by `/u01/oracle/product/crs/bin/crsd.bin reboot'.
Program terminated with signal 6, Aborted.
恰恰说明，由于系统发生reboot重启 *** 作，而产生了core文件。
oracle 产生core文件
xyk欠款3万以上还不上，12月14日最新逾期政策调整，联系我们
xyk网贷逾期处理
广告
Oracle Core- Essential Internals for DBAs and Developers 无水印pdf
25下载·0评论
2017年9月29日
oracle数据库原理基本知识点,ORACLE数据库基础知识1.doc
108阅读·0评论·0点赞
2021年5月7日
浅谈Core文件分析
6248阅读·0评论·0点赞
2014年7月23日
执行oracle命令时core,oracle coredump
135阅读·0评论·0点赞
2021年5月4日
oracle core文件使用率,Oracle EBS$INST_TOP/ora/10.1.2/forms存在很多core.*文件
165阅读·0评论·0点赞
2021年5月1日
不断有core文件在$ORACLE_HOME/dbs目录产生
3149阅读·0评论·0点赞
2014年1月21日
无锡xyk还不上了，不想连累家人，联系我们帮您
全国逾期处理中心
广告
oracle目录下core文件是什么,学习猿地-oracle core 概述
298阅读·0评论·0点赞
2021年5月2日
oracle core文件使用率,不断有core文件在$ORACLE_HOME/dbs目录产生
221阅读·0评论·0点赞
2021年4月3日
oracle目录下core文件是什么,oracle中adump,bdump,dpdump,udump目录中一些内容的作用
270阅读·0评论·0点赞
2021年5月2日
oracle 产生core文件,11.2.0.3 AIX RAC下$ORACLE_HOME/dbs生成大量core_* dump文件
181阅读·0评论·0点赞
2021年5月8日
linux core 调试 gdb,gdb core 调试_gdb coredump 调试_linux gdb core 调试(3)
159阅读·0评论·0点赞
2021年5月26日
软件测试解决Oracle问题,如何快速解决Oracle数据库中的常见问题
39阅读·0评论·0点赞
2021年5月4日
core文件截断的处理方法
4949阅读·0评论·0点赞
2012年2月10日
oracle设置core文件大小,Linux的Core文件设置与调试
488阅读·0评论·0点赞
2021年5月5日
oracle core文件使用率,oracle core dump 分析 - Oracle数据库管理 - Oracle数据库数据恢复、性能优化来问问AskMaclean - ParnassusDat...
190阅读·0评论·0点赞
2021年5月1日
GDB Core
651阅读·0评论·0点赞
2013年10月31日
Oracle core读书笔记
1735阅读·0评论·1点赞
2022年2月18日
oracle目录下core文件是什么,AIX上Oracle RAC 11g r2不断产生core文件问题的解决
98阅读·0评论·0点赞
2021年5月2日
Core文件产生以及调试
295阅读·0评论·0点赞
2021年9月24日
去首页
看看更多热门内容
先说说core的原理类似于飞机的黑匣子机制，在系统dump的时候，将那个时间点内存中的数据保存在磁盘上，以备后期的处理人员了解情况来用的。好比黑匣子，记录了发生事故前的一些具体的状态。
/usr/sap这个目录主要是保存SAP中运岁胡行的线程信息和日志的，在这个目录中出现core文件一般来说是SAP的进程出现了问题崩溃。前段打印不了是因为打印的的假脱机请求内容也是存储在这个文件系统中，如果这个文件系统已经塞满，那么新乎运拦的请求处理不了，所以就不能打印了。
程序不够强壮是主要原因,最该做的是去分析程序并且对程序进行改进，虽然这确实很难，一般也没有很多人重视。
当然剩下的处理就只剩下增大文件系统，增大文件悄搭系统，多一些空间，扩多大，扩到CORE塞不死就行了，再定期删除就行了。
还有不了解的，可以加入我组织的SAP爱好者群讨论，号码在我的空间里面有。
进程Core Dump产生的技术原因，基本等同于系统DUMP，就是说从程序原理上来说是基本一致的。但进程是运行在低一级的优先级上（此优先级不同于系统中对进程定义的优先级，而是指CPU代码指令的优先级），被 *** 作系统所控制，所以 *** 作系统可以在一个进程出问题时，不影响其他进程的情况下，中止此进程的运行，并将相关环境保存下来，这就是core dump文件，可供分析。
如果进程是用弊茄高级语言编写并编译的，且用户有源程序，那么可以通过在编译时带上诊断用符号表（所有高级语言编译程序都有这种功能），通过系统提供的分析工具，加上core文件，能够分析到哪一个源程序语句造成的问题，进而比较容易地修正问题，当然，要做到这样，除非一开始就带上了符号表进行编译，否则只能重新编译程序，并重新运行程序，重现错误，才能显示出源程序出错位置。
如果用户没有源程序，那么只能分析到汇编指令的级别，难于查找问题所在并作出修正，所以这种情况下就不必多费心了，找到出问题的地方也没有办法。
进程Core Dump的时候， *** 作系统会将进程异常终止掉并释放其占用的资源，不可能对系统本身的运行造成危害。这是与系统DUMP根本区别租衡察的一点，系统DUMP产生时，一定伴随着系统崩溃和停机，进程Core Dump时，只会造成相应的进程被终止，系统本身不可能崩溃。当然如果此进程与其他进程有关联，其他进程也会受到影响，至于后果是什么，就看相关进程对这种异常情况（与自己相关的进程突然终止）的处理机制是什么了，没有一概的定论。
如何生成coredump文件?
登陆LINUX服务器，任意位置键入
echo "ulimit -c 1024" >>/etc/profile
退出LINUX重新登陆LINUX
键入 ulimit -c
如果显示 1024 那么说明coredump已经被开启。
//---------------------------------------------------------------
1. core文件的简单介绍
//---------------------------------------------------------------
在一个程序崩溃时，它一般会在指定目录下生成一个core文件。core文件仅仅是一个内存映象(同时加上调试信息)，主要是用来调试的。
//---------------------------------------------------------------
2. 开启或关闭core文件的生成
//---------------------------------------------------------------
用以下命令来阻止系统生成core文件:
ulimit -c 0
下面的命令可以检查生成core文件的选项是否打开:
ulimit -a
该命令将显示所有的用拦汪户定制，其中选项-a代表“all”。
也可以修改系统文件来调整core选项
在/etc/profile通常会有这样一句话来禁止产生core文件，通常这种设置是合理的:
# No core files by default
ulimit -S -c 0 >/dev/null 2>&1
但是在开发过程中有时为了调试问题，还是需要在特定的用户环境下打开core文件产生的设置
在用户的~/.bash_profile里加上ulimit -c unlimited来让特定的用户可以产生core文件
如果ulimit -c 0 则也是禁止产生core文件，而ulimit -c 1024则限制产生的core文件的大小不能超过1024kb
//---------------------------------------------------------------
3. 设置Core Dump的核心转储文件目录和命名规则
//---------------------------------------------------------------
/proc/sys/kernel/core_uses_pid可以控制产生的core文件的文件名中是否添加pid作为扩展，如果添加则文件内容为1，否则为0
proc/sys/kernel/core_pattern可以设置格式化的core文件保存位置或文件名，比如原来文件内容是core-%e
可以这样修改:
echo "/corefile/core-%e-%p-%t" >core_pattern
将会控制所产生的core文件会存放到/corefile目录下，产生的文件名为core-命令名-pid-时间戳
以下是参数列表:
%p - insert pid into filename 添加pid
%u - insert current uid into filename 添加当前uid
%g - insert current gid into filename 添加当前gid
%s - insert signal that caused the coredump into the filename 添加导致产生core的信号
%t - insert UNIX time that the coredump occurred into filename 添加core文件生成时的unix时间
%h - insert hostname where the coredump happened into filename 添加主机名
%e - insert coredumping executable name into filename 添加命令名
//---------------------------------------------------------------
4. 使用core文件
//---------------------------------------------------------------
在core文件所在目录下键入:
gdb -c core
它会启动GNU的调试器，来调试core文件，并且会显示生成此core文件的程序名，中止此程序的信号等等
如果你已经知道是由什么程序生成此core文件的，比如MyServer崩溃了生成core.12345，那么用此指令调试:
gdb -c core MyServer
以下怎么办就该去学习gdb的使用了
//---------------------------------------------------------------
5. 一个小方法来测试产生core文件
//---------------------------------------------------------------
直接输入指令:
kill -s SIGSEGV $$
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）