DB2 - Problem description
Problem IT17130 | Status: Closed |
SORT RESERVATION MAY BE LEAKED UNDER CONSTRAINED SORT TUNING CONDITIONS, LEADING TO PERFORMANCE DEGRADATION AND SQL0955 ERRORS | |
product: | |
DB2 FOR LUW / DB2FORLUW / B10 - DB2 | |
Problem description: | |
When SORTHEAP is constrained, sort reservation may be leaked during the dynamic acquisition of sort memory (known as incremental sort). This occurs when the additional available reservation amount is small enough that it cannot be effectively utilized by the sort operator. The reservation is acquired then abandoned, the result being that the reservation is never released while the database remains active. Over time the leaked reservation amount builds to the point where the total sort reservation exceeds the configured SHEAPTHRES_SHR size. At this point, sort reservation requests start being heavily throttled (post-threshold sorts), resulting in queries acquiring less memory for execution, which leads to performance degradation. When the total sort reservation reaches 1.25 x SHEAPTHRES_SHR, queries with larger requirements will start failing with SQL0955. Notes: - constrained sortheap can be a result of many factors, including STMM tuning, overall memory available or configured for the database, and activity. For example, if there is a sudden spike in activity requiring sort memory and sort is configured conservatively by STMM, it may take some time for STMM to adjust the configuration, before which the sort configuration may be temporarily constrained. - the leaked reservation is not real memory, it is only an accounting value used to guide sort memory utilization. - use of intra-parallelism may increase the likelihood of encountering the problem due to apportioning the SORTHEAP maximum across multiple agents The problem can be detected by observing unexpectedly high sort reservation levels. For example : 1. during very low activity levels, the sort reservation appears very high, potentially exceeding SHEAPTHRES_SHR 2. sort reservation amounts far exceed the actual sort memory usage levels. To determine the sort memory reservation levels, check the SORT_SHRHEAP_ALLOCATED in the MON_GET_DATABASE routine, or the "Total Shared Sort heap allocated" amount in a database snapshot. Both values are in 4K pages. Compare this to the actual shared sort memory usage - MEMORY_POOL_USAGE for the SHARED_SORT pool type in the MON_GET_MEMORY_POOL routine (value is in 1K units) : eg. db2 select SORT_SHRHEAP_ALLOCATED from table"(MON_GET_DATABASE(null))" db2 select MEMORY_POOL_TYPE, MEMORY_POOL_USED from table"(MON_GET_MEMORY_POOL('DATABASE',null,null))" where MEMORY_POOL_TYPE = "'SHARED_SORT'" | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * All systems may be affected * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 Version 11.1 Mod 1 Fix Pack 1. * **************************************************************** | |
Local Fix: | |
Applying an appropriate fixed SORTHEAP/SHEAPTHRES_SHR tuning will avoid the problem. | |
available fix packs: | |
DB2 Version 11.1 Mod1 Fix Pack1 iFix001 for Linux, UNIX, and Windows | |
Solution | |
Problem first fixed in DB2 Version 11.1 Mod 1 Fix Pack 1 | |
Workaround | |
See Local Fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 20.09.2016 10.10.2017 10.10.2017 |
Problem solved at the following versions (IBM BugInfos) | |
Problem solved according to the fixlist(s) of the following version(s) | |
11.1.1.1 |