|
Problem IT03298
|
Status: Closed |
INSERT MIGHT NOT RESPOND OR BE VERY SLOW OR HANG ON PURESCALE SYSTEMS |
| product: |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 |
| Problem description: |
There is a timing problem at a pureScale specific index function
which allocates new pages to an index object. The result might
be poor INSERT performance in a DB2 pureScale environment. It
can be hit on any large index object that is both growing and
that has a steady stream of index scans.
Symptoms:
From db2trace.flwt files by db2fodc -hang, we will see a list,
taking time order.
-----
sqlbfix 0.020207583 409
sqlbgbGetPagePLock 0.019451659 410
sqlplMakeNewRequestSD 0.018708391 410
sqlpLLMInformGLMIfStateChanged 0.018120826 820
sqlpLLMBGThreadWaitForWork 0.017240770 54
sqloWaitEDUWaitPost 0.017163650 37
SAL_GLM_HANDLE::SAL_SetLockStateN 0.016707163 468
sqlpLLMSetLockState 0.016065740 411
SAL_GLM_HANDLE::SAL_SetLockState 0.015775890 411
SAL_GLM_HANDLE::SAL_GetNotification 0.014422430 3
sqliFixSMP 0.012805986 202
sqlplrq 0.012142976 203
-----
Here is the associated calling chain in that file.
-----
2902 sqliFixSMP entry [eduid 59409 eduname db2agent]
2903 | sqlbfix entry [eduid 59409 eduname db2agent]
2909 | sqlbfix data [probe 100]
2911 | | sqlbgbGetPagePLock entry [eduid 59409 eduname
db2agent]
...snip...
3131 | | sqlbgbGetPagePLock exit
3132 | | sqlbAddPageToDirtyList entry [eduid 59409
eduname db2agent]
3133 | | sqlbAddPageToDirtyList exit
3134 | sqlbfix exit
3135 sqliFixSMP exit
-----
There is no related message at db2diag.log. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* DB2 pureScale instances *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 version 10.5.0.5. *
**************************************************************** |
| Local Fix: |
The problem will correct itself over time, but the following can
also be used to workaround the problem. The workarounds are
listed in increasing order of impact to the system:
- Temporarily disable the read activity on the table.
- Acquire an EXCLUSIVE connection to the database and create
and then drop a new index on the table.
- Recreate the index object (i.e. run REORG INDEXES ALL with
the ALLOW NO ACCESS option or use db2dart's /mi option to
mark the indexes invalid and rebuild them on next table
access). |
| Solution |
The problem was first fixed in DB2 version 10.5.0.5. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 22.07.2014
05.03.2015
09.04.2015 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 10.5.0.5
|
 |
