In a recent SR with Oracle, the support analyst told us to disable core dumps as all the information captured in core dumps is also present in ORA-7445 trace files.
Metalink Note 397404.1 gives these two methods for disabling core dumps.
Method #1 - Set database parameter SHADOW_CORE_DUMP to NONE.
SHADOW_CORE_DUMP is a static parameter so the database must be restarted in order for the parameter value to be enabled. Setting SHADOW_CORE_DUMP to NONE will block the generation of core dumps from user (client) processes attached to the SGA. Setting this parameter has no impact on core dumps being generated by background processes. It is not possible to set BACKGROUND_CORE_DUMP to NONE. So this method will prevent core dumps from being generated by user processes but will not prevent the generation of core dumps by background processes.
Method #2 - modify the OS ULIMIT
ulimit -c 0
doing this will block core dumps from being generated by all processes executed by this user, which should include all user and background processes on the server. The database will have to be restarted in order for the new ulimit settings to take effect.
Blog dedicated to Oracle Applications (E-Business Suite) Technology; covers Apps Architecture, Administration and third party bolt-ons to Apps
Showing posts with label core. Show all posts
Showing posts with label core. Show all posts
Thursday, June 4, 2009
Friday, April 4, 2008
ALECDC, ARGLTP, XDPCTRLS, FNDLIBR writing core files
After moving the storage to Solaris 10 or cloning from Solaris 8 box to Solaris 10 box, in a few instances the /var/crash/cores directory was reaching 100%. It was full of cores written by ALECDC, ARGLTP, XDPCTRLS, FNDLIBR, MSONEW, MSCSLD etc. I logged an SR with Oracle and they asked me for a stack trace. Metalink Note 1812.1 describes how to get a stack trace from a core file. Here's what I did:
Stack trace for ARGLTP
$ adb /apps11i/erp/appl/ar/11.5.0/bin/ARGLTP
1207343405-ARGLTP-16927-66128-54055-tsgsd1007-sun4u
core file = 1207343405-ARGLTP-16927-66128-54055-tsgsd1007-sun4u -- program
``
/apps11i/erp/appl/ar/11.5.0/bin/ARGLTP'' on platform SUNW,Netra-T12
SIGSEGV: Segmentation Fault
$c
libc.so.1`strcmp+0x60(174ba4, 73737431, 0, 0, 1d1900, 1d18e0)
afppre+0x1cc(2a9900, 262b50, 50, 50, ff1ea2b4, ff1f29f8)
fdpcls+0x3e4(4e, 1c3df4, 1c3de4, 1c3c00, 1c3c00, 1)
main+0x7704(14fc30, 14fc74, ffbf9efc, a, 2a5e28, 7f80)
_start+0xdc(0, 0, 0, 0, 0, 0)
$q
We nailed it finally after long discussions with Oracle. It was a bug. After ATG_PF.H RUP6 when concurrent programs try to write Completed successfully, a variable was not initialized in the code. Because of this even though the concurrent program completed successfully, it used to coredump before it was able to write to its log file: Completed successfully. Applying Patch 6815663 resolved this issue.
Stack trace for ARGLTP
$ adb /apps11i/erp/appl/ar/11.5.0/bin/ARGLTP
1207343405-ARGLTP-16927-66128-54055-tsgsd1007-sun4u
core file = 1207343405-ARGLTP-16927-66128-54055-tsgsd1007-sun4u -- program
``
/apps11i/erp/appl/ar/11.5.0/bin/ARGLTP'' on platform SUNW,Netra-T12
SIGSEGV: Segmentation Fault
$c
libc.so.1`strcmp+0x60(174ba4, 73737431, 0, 0, 1d1900, 1d18e0)
afppre+0x1cc(2a9900, 262b50, 50, 50, ff1ea2b4, ff1f29f8)
fdpcls+0x3e4(4e, 1c3df4, 1c3de4, 1c3c00, 1c3c00, 1)
main+0x7704(14fc30, 14fc74, ffbf9efc, a, 2a5e28, 7f80)
_start+0xdc(0, 0, 0, 0, 0, 0)
$q
We nailed it finally after long discussions with Oracle. It was a bug. After ATG_PF.H RUP6 when concurrent programs try to write Completed successfully, a variable was not initialized in the code. Because of this even though the concurrent program completed successfully, it used to coredump before it was able to write to its log file: Completed successfully. Applying Patch 6815663 resolved this issue.
Subscribe to:
Posts (Atom)