DB2 FOR LUW / DB2FORLUW / 970 - DB2

Problem description : 
After applying FP2 on V9.7 on Linux, autonomic backup does not 
function under some circumstances. The degree of parallelism 
chosen in FP2 when taking a full backup now equals the number of 
tablespaces the customer has, without concern for the system 
resources.  As a  result when taking a full non-ITP backup with 
a large number of tablespaces the degree of parallelism chosen 
will cause too many db2bm Processes to be generated resulting in 
possible poorer performance or even a system hang. 
 
The db2diag.log file shows hundreds of 
the following entries: 
 
 
2010-05-31-13.56.35.754214+120 I4003620A486      LEVEL: Info 
PID    : 4784           TID  : 2203100113232 PROC :db2sysc 0 
INSTANCE: db2inst1      NODE : 000            DB  :SAMPLE 
APPHDL  : 0-17          APPID: *LOCAL.db2inst1.100531115629 
AUTHID  : db2inst1 
EDUID  : 674          EDUNAME: db2bm.18.492 (SAMPLE)  0 
FUNCTION: DB2 UDB, database utilities, sqluOpenQueue, probe:225 
MESSAGE : Opening message queue 
DATA #1 : Hex integer, 4 bytes 
0x022B0011 
 
 
2010-05-31-13.56.35.809273+120 E4004107A549  LEVEL: Error(OS) 
PID    : 4784           TID  : 2203779590480PROC :db2sysc 0 
INSTANCE: db2inst1      NODE : 000           DB  :SAMPLE 
APPHDL  : 0-17          APPID: *LOCAL.db2inst1.100531115629 
AUTHID  : db2inst1 
EDUID  : 773           DUNAME: db2bm.18.303 (SAMPLE) 0 
FUNCTION: DB2 UDB, oper system services, sqloCSemCreate, probe:1 
MESSAGE : ZRC=0x8300001C=-2097151972 
CALLED  : OS, -, unspecified_system_function 
OSERR  : ENOSPC (28) "No space left on device" 
 
It creates lot of db2bm processes,until number of semaphores or 
message queues is exhausted.  Then the system hangs. Seems to 
create a db2bm for each tablespace, and customer has many 
hundred tablespaces, So it is that in 9.7 FP2 that the autonomic 
backup tuning for some reason chooses parallelism=number of 
tablespaces. 
 
Setting  DB2_ITP_LEVEL=0 made no difference. 
A db2_kill had to be issued to stop the system.

**************************************************************** 
* USERS AFFECTED:                                              * 
* Users prior to DB2 V97 FP x.                                 * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* Will update later                                            * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Will update later                                            * 
****************************************************************

Workround the issue by adding parallelism to the backup command. 
 
Example: 
 
"backup db <dbname> online use tsm parallelism 4" .

DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
 DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
 

Will update later

keiner bekannt / siehe Local-Fix

Vorgänger  : APAR is sysrouted TO one or more of the following: IC70403 
Nachfolger : 

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

23.06.2010
23.09.2010
16.02.2012