DB2 - Problem description
| Problem IC67039 | Status: Closed |
UNABLE TO EXECUTE NON-SQL STORED PROCEDURES ON SYSTEM WITH HIGH NUMBER OF LICENSED CPU CORES | |
| product: | |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 | |
| Problem description: | |
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> | |
| Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * ALL * **************************************************************** * PROBLEM DESCRIPTION: * * See ERROR DESCRIPTION. * **************************************************************** * RECOMMENDATION: * * At minimum this fixpack should be applied to the server. * **************************************************************** | |
| Local Fix: | |
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. | |
| available fix packs: | |
DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows | |
| Solution | |
Problem was first fixed in v9.5 Fixpak 6. | |
| Workaround | |
not known / see Local fix | |
| BUG-Tracking | |
forerunner : APAR is sysrouted TO one or more of the following: IC67246 IC67254 IC67773 IC67957 follow-up : | |
| Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 09.03.2010 15.09.2010 19.10.2010 |
| Problem solved at the following versions (IBM BugInfos) | |
9.5. | |
| Problem solved according to the fixlist(s) of the following version(s) | |