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) |