在grid目录下，/scratch/oracle/app/11.2.0/grid/log/linux/cssd/下有个 core文件和一些log。log文件我能理解，但是那个core文件我就搞不懂了。
-rw------- 1 54414848 2003-11-01 06:29 core
core里面都是乱码
想知道这个core是干嘛的，是怎么产生的。谢谢。
-rw------- 1 54414848 2003-11-01 06:29 core
core里面都是乱码
想知道这个core是干嘛的，是怎么产生的。谢谢。
解决方法参照metalink
The information in this document applies to:
Oracle Server - Enterprise Edition - Version: 8.1.7.4
This problem can occur on any platform.Errors
ORA-7445 "exception encountered: core dump [%s] [%s]"Symptoms
- Oracle is dumping CORE in $ORACLE_HOME/dbs directory rather than CORE_DUMP_DEST
- The default directory filesystem usage peaked at 100%.
Cause
If the CORE_DUMP_DEST is not used, the default will be the ORACLE_HOME/dbs
directory.The common causes are:
- CORE_DUMP_DEST not set.
- Invalid directory specified (includes case sensitive naming convention).
- Insufficient privileges on the specified directory.
- Insufficient space in the directory.If you have already checked and ruled out these causes then the remaining
reason is (from Note:39793.1 "PARAMETER:CORE_DUMP_DEST"):
" In some cases this parameter may not have been read when a core file
is produced. In this case the core dump is typically written to the
default location ($ORACLE_HOME/dbs). "In certain cases when if the the SGA is not mapped, there is no way we can find
out where core_dump_dest is and dumps are created in ORACLE_HOME/dbs directory.
- This cannot be avoided.This is usually the case when there is a memory related issue that is flagged
before the error moves to the point in the code stack where the CORE_DUMP_DEST
is read. In terms of the use of the CORE_DUMP_DEST vs ORACLE_HOME/dbs, this is
considered an 'expected behavior'
Fix
CORE_DUMP_DEST should point to the directory where core dumps from the Oracle server will be placed. A core dump is a memory image of the Oracle shadow process produced when an unexpected , unrecoverable or invalid condition occurs.Note that Oracle should always try to write a trace file before producing a core dump. Always check and locations for trace files first.In some cases this parameter may not have been read when a core file is produced. In this case the core dump is typically written to the default location ($ORACLE_HOME/dbs). CORE_DUMP_DEST should have WRITE permission for the Oracle user.Here are some parameters that may help in handling problems due to huge core files.
For large databases, SGA will be huge and core files will take large space in disk.
Normally, we should keep the core files around for debugging purposes, but occasionally one may need to draw the line when 50 Mb core files are continually deposited into the file systems. To control the size of core files two new init.ora parameters can be used: - shadow_core_dump = full, partial, none (default full)
- background_core_dump = full, partial (default full) Core files will be generated for all process other than shadow process by default. One way we can control the size of the control the size of core file is by detaching SGA before producing core. If "shadow_core_dump" is full core files will be generated for shadow process. SGA will not be detached. This is default. If "shadow_core_dump" is partial, SGA will be detached before generating core files. This way the core files are much smaller. If "shadow_core_dump" is none, no core files will be generated for shadow process.
Solution Summary
================
- This is a expected behavior
- Limit the size of core dumps using the parameter MAX_DUMP_FILE_SIZE.
- Relink the executables to check if the cores are not generated because of linking issues.
- Check the directory permissions of the CORE_DUMP_DEST if the Oracle user has write access.
具体修改参数
sqlplus "/as sysdba"
show parameter core_dump_dest
show parameter max_dump_file_size
之后修改
alter system set max_dump_file_size=500000 scope=both;
我show parameter core_dump_dest 后的目录是/scratch/sysvldb/app/sysvldb/diag/rdbms/orcl/orcl1/cdump
但实际的core文件是在/scratch/oracle/app/11.2.0/grid/log/linux/cssd/下 名字就叫core 里面全是乱码
程序崩溃，内核有可能把该程序当前内存映射到core文件里，方便程序员找到程序出现问题的地方。