DB2 FOR LUW / DB2FORLUW / 970 - DB2

This issue is applicable only to DB2 Workgroup Edition 
installations where the number of installed CPUs is greater than 
the maximum number of CPU cores (maximum 16) which can be 
licensed under DB2 Workgroup Edition. 
 
Calling a non-SQL routine (stored procedure/user defined 
function) may return one of the following symptoms: 
 
1) A hang or SQL1042 returned when calling the routine along 
with the following messages in the db2diag.log that the 
call to sqlochsr failed with the error SQLO_NOSEG. 
Note the example was from Windows so on 
Linux/UNIX the CALLED and OSERR parts of the message may differ 
slightly. 
 
2010-01-01-11.00.36.987000-400 I6620F560          LEVEL: Severe 
(OS) 
PID     : 1224                 TID  : 3924        PROC : 
db2fmp64.exe 
INSTANCE: DB2                  NODE : 000 
EDUID   : 3924 
FUNCTION: DB2 UDB, SQO Memory Management, sqlocshr, probe:140 
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG 
          "No Storage Available for allocation" 
          DIA8305C Memory allocation failure occurred. 
CALLED  : OS, -, OpenFileMapping 
OSERR   : 2 "The system cannot find the file specified." 
DATA #1 : String, 21 bytes 
 
Global\DB2SHMDB2_0DBM 
 
On AIX system you might see the following in the db2diag.log: 
 
CPU: total:<double digit value> 
 
and message: 
 
2010-07-20-16.23.40.766844-240 I133669A805        LEVEL: Severe 
( 
PID     : 712742               TID  : 1           PROC : db2fmp 
INSTANCE: db2inst1               NODE : 000 
EDUID   : 1                    EDUNAME: db2fmp 
FUNCTION: DB2 UDB, SQO Memory Management, sqlocshr, probe:180 
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG 
          "No Storage Available for allocation" 
          DIA8305C Memory allocation failure occurred. 
CALLED  : OS, -, shmat 
OSERR   : EINVAL (22) "Invalid argument" 
DATA #1 : Memory set handle, PD_TYPE_OSS_MEM_SET_HDL, 48 bytes 
... 
 
 
2) SQLCODE=-1131, SQLSTATE=38503 or segmentation fault from 
db2fmp process with the following stack: 
 
<StackTrace> 
--Frame--- ------Function + Offset------ 
0xBFFFF3A0 ossLinuxIA32FetchAndAdd32Internal + 0x0008 
        (/home/db2inst1/sqllib/lib32/libdb2osse.so.1) 
0xBFFFF40C sqlocshr. + 0x06a8 
        (/home/db2inst1/sqllib/lib32/libdb2.so.1) 
0xBFFFF56C sqlerFmpThreadInit + 0x00cc 
        (/home/db2inst1/sqllib/lib32/libdb2.so.1) 
0xBFFFF5B8 sqlerFmpOneTimeInit + 0x04f6 
        (/home/db2inst1/sqllib/lib32/libdb2.so.1) 
0xBFFFF9A8 main + 0x071e 
        (db2fmpr) 
0xBFFFFA08 __libc_start_main + 0x00dc 
        (/lib/libc.so.6) 
</StackTrace>

See ERROR DESCRIPTION.

Workaround for AIX: 
 
The "CPU: total: " value equals to all logical CPUs on the 
physical  box, including all LPARs calculated using the value of 
"maximum virtual processors". 
 
Check lparstat -i and change if possible the value of "maximum 
virtual processors" from  hardware management  console (HMC) to 
reduce the value of "CPU: total:" reported in db2diag.log. 
 
Workaround for Windows/Linux on Intel x86: 
 
Try disabling Intel Hyperthreading to reduce the number of CPUs 
visible to the operating system.

At minimum this fix should be applied to the server side.  First 
fixed in v9.7 FP3.

See LOCAL FIX.

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

11.04.2010
16.10.2010
19.10.2010

9.7.FP3