|
Problem IC73767
|
Status: Closed |
In archive logging mode COMMIT statements might be blocked for a short while if COMMIT statements are submitted too frequently. |
| product: |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 |
| Problem description: |
The problem exists only in 'archive logging' mode. It could
happen when COMMIT statements are submitted too frequently.
When this problem occurs, any COMMIT statement being performed
by 'db2agent' will be blocked for a short period of time in
units of seconds, e.g. 1 second or 2 seconds. Corresponding
applications will be in state of 'Commit Active' during the
time.
In most cases the COMMIT statement will be blocked for only 1
second. In very rare situations where there are too many COMMIT
statements submitted frequently, it could be blocked for 2
seconds or even longer.
The COMMIT statement is actually being blocked by EDU 'db2logts'
which is flushing data from memory to DB2TSCHG.HIS.
To identify the problem, collect 'db2trc' data when 'db2agent'
is issuing COMMIT statement and see if the function
sqlpUploadDirtyPoolEntry() costs too much time (e.g. 1 second or
2 seconds). |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All users of version 9.5 on Linux, Unix and Windows *
* platforms. *
****************************************************************
* PROBLEM DESCRIPTION: *
* The problem exists only in 'archive logging' mode. It could *
* happen when COMMIT statements are submitted too frequently. *
* *
* When this problem occurs, any COMMIT statement being *
* performed by 'db2agent' will be blocked for a short period *
* of time in units of seconds, e.g. 1 second or 2 seconds. *
* Correspoding applications will be in state of 'Commit *
* Active' during the time. *
* In most cases the COMMIT statement will be blocked for only *
* 1 second. In very rare situations where there are too many *
* COMMIT statements submitted frequently, it could be blocked *
* for 2 seconds or even longer. *
* *
* The COMMIT statement is actually being blocked by EDU *
* 'db2logts' which is flushing data from memory to *
* DB2TSCHG.HIS. *
* *
* To identify the problem, collect 'db2trc' data when *
* 'db2agent' is issuing COMMIT statement and see if the *
* function sqlpUploadDirtyPoolEntry() costs too much time *
* (e.g. 1 second or 2 seconds). *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 UDB Version 9.5 FixPak 8 or higher levels. *
**************************************************************** |
| Local Fix: |
Setting DB2 registry variable DB2_COLLECT_TS_REC_INFO=OFF to
stop EDU 'db2logts'. |
| available fix packs: |
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
First fixed in DB2 UDB Version 9.5 FixPak 8. |
| Workaround |
Setting DB2 registry variable DB2_COLLECT_TS_REC_INFO=OFF to
stop EDU 'db2logts'. |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC75445
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 10.01.2011
30.06.2011
30.06.2011 |
| Problem solved at the following versions (IBM BugInfos) |
9.5.
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.5.0.8
|
 |
