DB2 FOR LUW / DB2FORLUW / 970 - DB2

DB2 EDU first traps due to a SIGSEGV (signal #11), then in 
signal handler it keeps looping between "pdLogInternal" and 
"sqlm*" functions and never returns. 
This problem only occurs when running LOAD commands via 
routines, e.g. "ADMIN_CMD". 
 
Following symptoms can help you identify this issue: 
-- The trapped EDU never terminates (can be seen in "db2pd -edu" 
result). 
-- "FODC_Trap_XXX" directory created, trap file generated, but 
no dump files. 
-- In db2diag.log, no information for the trap. 
-- The correspoding application appears hung. 
   The DB2 instance may also hang if the hanging agent is 
holding some latches being requested by others. 
-- The "db2pd -edu" result shows the EDU clocks up a lot of user 
CPU time. 
-- In the trap file, you may see "sqlmStopWaitTimeInterval" or 
"sqlmStartWaitTimeInterval" at the top of the stack trace. 
-- A series of stack traces for the apparently hung EDU shows 
movement and "pdLogInternal" and "sqlm* (e.g. sqlmStopInterval)" 
functions at the top of the stack. 
   To get the stack trace of the EDU, you will need some OS 
utilities. For example, OS debugger or the "pdump.sh" SHELL 
script provided by IBM for AIX platform.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All users of version 9.7 on Linux, Unix and                  * 
* Windowsplatforms.                                            * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* DB2 EDU first traps due to a SIGSEGV (signal #11), then      * 
* insignal handler it keeps looping between "pdLogInternal"    * 
* and"sqlm*" functions and never returns.This problem only     * 
* occurs when running LOAD commands viaroutines, e.g.          * 
* "ADMIN_CMD".Following symptoms can help you identify this    * 
* issue:-- The trapped EDU never terminates (can be seen in    * 
* "db2pd-edu" result).-- "FODC_Trap_XXX" directory created,    * 
* trap file generated,but no dump files.-- In db2diag.log, no  * 
* information for the trap.-- The correspoding application     * 
* appears hung.The DB2 instance may also hang if the hanging   * 
* agent isholding some latches being requested by others.--    * 
* The "db2pd -edu" result shows the EDU clocks up a lot ofuser * 
* CPU time.-- In the trap file, you may see                    * 
* "sqlmStopWaitTimeInterval"or "sqlmStartWaitTimeInterval" at  * 
* the top of the stacktrace.-- A series of stack traces for    * 
* the apparently hung EDUshows movement and "pdLogInternal"    * 
* and "sqlm* (e.g.sqlmStopInterval)" functions at the top of   * 
* the stack.To get the stack trace of the EDU, you will need   * 
* some OSutilities. For example, OS debugger or the "pdump.sh" * 
* SHELLscript provided by IBM for AIX platform.                * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Update to V9.7 FP2 or  avoid  running LOAD commandsviastored * 
* procedures such as ADMIN_CMD.                                * 
****************************************************************

The issue can be avoided by not running LOAD commands via stored 
procedures such as ADMIN_CMD.

DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
 

First fixed in DB2 UDB Version 9.7 FixPak 2.

The issue can be avoided by not running LOAD commands via stored 
procedures such as ADMIN_CMD.

forerunner  : APAR is sysrouted TO one or more of the following: IC68293 
follow-up : 

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

25.04.2010
14.05.2010
14.05.2010

9.7.,
9.7.FP2