|
Problem IC95357
|
Status: Closed |
INSTANCE MIGHT CRASH IF A QUERY THAT FEATURES A SORT IS RE-EXECUTED AFTER IT PREVIOUSY RECEIVED SQL0973. |
| product: |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 |
| Problem description: |
An SQL might cause instance crash at sqlrifis2. An example stack
trace might be like below:
sqlrifis2
sqlifnxt
sqlirdk
sqldIndexFetch
sqldRowFetch
This problem can happen if all the following conditions are met:
a) SORT memory is low
b) The query is run and it fails with sql0973 due to lack of
sort memory.
Users can see the out of memory error in the db2diag.log as
below:
2013-05-14-14.38.00.377730 I484339A914 LEVEL: Warning
PID : 7865 TID : 4394300991760 PROC : db2sysc
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-11465 APPID: 192.168.1.1.2080.130514051704
AUTHID : DB2INST1 HOSTNAME: host01
EDUID : 713 EDUNAME: db2agent (SAMPLE)
FUNCTION: DB2 UDB, SQO Memory Management,
sqloCreateMemorySubPool, probe:130
MESSAGE : ZRC=0x8B0F0012=-1961951214=SQLO_NOMEM_SHARED_SORT
"No memory available in 'Shared Sort Heap'"
DIA8300C A memory heap error has occurred.
DATA #1 : String, 52 bytes
Unable to allocate memory for the initial pool size.
c) The same query is run again soon after (while it is still
cached in the SQL workspace).
The problem is most likely to be seen for a query with an access
plan that contains a RIDSCAN over SORT. The typical example
here would be a plan that has something like this (example exfmt
output):
RIDSCN
( 14)
319827
1
|
3000
SORT
( 15)
319827
1
|
3000
IXSCAN
( 16)
10.0149
1
However, the problem is not limited to just plans like the
above. Any SORT that is "simple", like a RID sort as above, or
a sort of just an integer column, has a chance to encounter the
issue. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Users who run SQL involves simple sorts. *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Please upgrade to V10.5 FixPack 3 or later. *
**************************************************************** |
| Local Fix: |
Investigate the memory usage and configuration, and then take
corrective tuning measures to avoid the memory limitations that
lead to the problematic scenario. |
| available fix packs: |
DB2 Version 10.5 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 10.5 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows
DB2 Version 10.5 Fix Pack 9 for Linux, UNIX, and Windows
|
| Solution |
This problem was first fixed in DB2 V10.5 FixPack 3. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 27.08.2013
27.02.2014
27.02.2014 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 10.5.0.3
|
 |
| 10.5.0.3
|
|
