DB2 FOR LUW / DB2FORLUW / A10 - DB2

BACKUP DATABASE command prunes the "table space change history 
file (DB2TSCHG.HIS)", right before the end of the BACKUP 
DATABASE command. When an ONLINE BACKUP is pruning the 
DB2TSCHG.HIS file, it might block applications that are doing 
COMMIT at the same time. 
The problem happens to "full" BACKUP only, as opposed to 
"tablespace-level" BACKUP. 
 
To identify the problem, please issue "db2pd -stack all" command 
to generate stack files. 
 
Stack file of the BACKUP coordinator agent will have content 
similar to the following: 
=========================================== 
<StackTrace> 
sqlpPruneTsChgHistoryFile 
sqluhPruneDatabaseHistoryOnePass 
sqluhPruneDatabaseHistory 
sqlubupHistoryFile 
sqlubcka 
</StackTrace> 
 
<LatchInformation> 
Holding Latch type: 
(SQLO_LT_SQLP_LOGTS_LOG_FILES_INFO__latchLogTsInfo) 
</LatchInformation> 
=========================================== 
It's holding the 
'SQLO_LT_SQLP_LOGTS_LOG_FILES_INFO__latchLogTsInfo' latch which 
is being waited by EDU named 'db2logts': 
=========================================== 
<StackTrace> 
sqloXlatchConflict 
sqlpDirtyPoolHandler 
sqloEDUEntry 
</StackTrace> 
 
<LatchInformation> 
Waiting on latch type: 
(SQLO_LT_SQLP_LOGTS_LOG_FILES_INFO__latchLogTsInfo) 
</LatchInformation> 
=========================================== 
 
Meanwhile, all agents that are doing COMMIT are stuck in one of 
the following stack traces: 
=========================================== 
sqloXlatchConflict 
sqlpUploadDirtyPoolEntry 
sqlpUploadDirtyPoolEntry 
sqlpEndUowRuntime 
sqlpxcm1 (or 'sqlpxcm2') 
 
or 
 
sqloSpinLockReleaseConflict 
sqlpUploadDirtyPoolEntry 
sqlpUploadDirtyPoolEntry 
sqlpEndUowRuntime 
sqlpxcm1 (or 'sqlpxcm2') 
 
or 
 
ossSleep 
sqlorest 
sqlpUploadDirtyPoolEntry 
sqlpUploadDirtyPoolEntry 
sqlpEndUowRuntime 
sqlpxcm1 (or 'sqlpxcm2') 
=========================================== 
 
If the DB2TSCHG.HIS file is big in size and too many entries 
need to be retained in the file (which is controlled by database 
configuration parameter named REC_HIS_RETENTN), the BACKUP 
DATABASE command might take a long time in pruning the 
DB2TSCHG.HIS file. As a result, there is a good chance to hit 
the problem. 
 
The fix of the APAR will improve the performance of pruning 
DB2TSCHG.HIS file, hence minimize the chance of hitting the 
problem.

**************************************************************** 
* USERS AFFECTED:                                              * 
* All users of version 10.1 on Linux, Unix and Windows         * 
* platforms.                                                   * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Update to DB2 LUW Version 10.1 Fix Pack 4 or higher levels.  * 
****************************************************************

1) Set DB2 registry variable DB2_COLLECT_TS_REC_INFO=OFF to stop 
updating DB2TSCHG.HIS file, which can definitely avoid the 
problem. 
2) Set a small value to parameter REC_HIS_RETENTN. 
3) Prune the DB2TSCHG.HIS file manually by "PRUNE HISTORY" 
command to reduce the size of the file.

DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows
 

First fixed in DB2 LUW Version 10.1 Fix Pack 4.

1) Set DB2 registry variable DB2_COLLECT_TS_REC_INFO=OFF to stop 
updating DB2TSCHG.HIS file, which can definitely avoid the 
problem. 
2) Set a small value to parameter REC_HIS_RETENTN. 
3) Prune the DB2TSCHG.HIS file manually by "PRUNE HISTORY" 
command to reduce the size of the file.

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

08.10.2013
09.05.2014
09.05.2014