DB2 - Problembeschreibung
Problem IC97805 | Status: Geschlossen |
UNEXPECTED LOCK ESCALATIONS ON DB2 PURESCALE SYSTEMS USING STMM LOCKLIST TUNING OR MANUAL DYNAMIC UPDATE OF LOCKLIST SETTING | |
Produkt: | |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 | |
Problembeschreibung: | |
Due to a logic error on pureScale systems, the locklist manager might calculate an unexpectedly low internal "maximum locks per transaction" value. This results in lock escalations when applications are holding a small number of locks and a locklist that is not exhausted. The calculation error is due to an incorrectly maintained internal counter which tends to increase over time, so the issue is more likely seen the longer a database is active. Systems where STMM is tuning locklist (and maxlocks) are highly vulnerable since the "maximum locks per transaction" is recalculated after database activation. However, the problem might also be introduced on a system if locklists or maxlocks are updated dynamically, since the "maximum locks per transaction" are recalculated at that time and might be influenced by the invalid internal counter. The example escalation below shows a lock escalation that is occurring even though the application is holding only 33 locks. It is reported that this is due to reason code 1, which means that the maximum allowed locks for the application has been reached. This is virtually impossible because of the low locklist and maxlocks settings, and implies the system is encountering the incorrect locklist manager calculation: FUNCTION: DB2 UDB, data management, sqldEscalateLocks, probe:1 MESSAGE : ADM5501I DB2 is performing lock escalation. The affected application is named "db2bp", and is associated with the workload name "SYSDEFAULTUSERWORKLOAD" and application ID "*N0.mcornish.131114133735" at member "0". The total number of locks currently held is "33", and the target number of locks to hold is "16". The current statement being executed is "drop table t1". Reason code: "1" | |
Problem-Zusammenfassung: | |
**************************************************************** * USERS AFFECTED: * * DB2 LUW pureScale systems * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Update to 10.5.0.3 * **************************************************************** | |
Local-Fix: | |
Use manual locklist tuning as opposed to STMM, and avoid dynamically altering the locklist or maxlocks settings. On a system experiencing unexpected locklist escalations, recycling the database will reset the internal "maximum locks per transaction" parameter to a normal value. | |
verfügbare FixPacks: | |
DB2 Version 10.5 Fix Pack 3 for Linux, UNIX, and Windows | |
Lösung | |
Problem Fixed In 10.5.0.3 | |
Workaround | |
see Local Fix | |
Bug-Verfolgung | |
Vorgänger : APAR is sysrouted TO one or more of the following: IC97896 IC97897 Nachfolger : | |
Weitere Daten | |
Datum - Problem gemeldet : Datum - Problem geschlossen : Datum - der letzten Änderung: | 20.11.2013 28.02.2014 02.07.2014 |
Problem behoben ab folgender Versionen (IBM BugInfos) | |
Problem behoben lt. FixList in der Version | |
10.5.0.3 | |
10.5.0.3 |