home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IC91790 Status: Closed

SPECIFYING SHARED CONTAINER PATH DURING CREATION OF DMS TABLE SPACE IN
PARTITIONED ENVIRONMENT MAY CAUSE INSTANCE ABEND

product:
DB2 FOR LUW / DB2FORLUW / A10 - DB2
Problem description:
When creating a DMS table space, DB2 checks the presence and 
physical properties of all the table space containers specified 
in the CREATE TABLESPACE command. When the user incorrectly 
attempts to use the same (shared) container with multiple nodes, 
SQL0294N (The container is already in use) will be returned 
since the same container will already have been allocated and 
used by a different node. However, in certain timing sensitive 
scenarios, for example when the CREATE TABLESPACE command is 
issued simultaneously on multiple nodes, the instance may panic. 
 
Example: 
 
1. Set up host1 and host2 as a partitioned system. Your 
db2nodes.cfg will look similar to: 
0 host1 0 
1 host1 1 
2 host1 2 
3 host2 0 
4 host2 1 
5 host2 2 
 
2. Choose two nodes residing on different hosts, and run the 
following CREATE TABLESPACE command on both nodes at 
approximately the same time. The command is purposely specifying 
a shared container, and the action should fail with SQL0294N. 
However, if the timing is right, the instance will panic 
instead: 
 
$ db2 "create tablespace ts1 managed by database using (file 
'/<directory_shared_by_all_hosts>/ts1' 1M)" 
DB21034E  The command was processed as an SQL statement because 
it was not a 
valid Command Line Processor command.  During SQL processing it 
returned: 
SQL1224N  The database manager is not able to accept new 
requests, has 
terminated all requests in progress, or has terminated the 
specified request 
because of an error or a forced interrupt.  SQLSTATE=55032 
 
A good eyecatcher is container mismatch errors followed by 
"sqlbDMSAddContainerRequest - rc == SQLB_CONTAINER_IN_USE" in 
db2diag.log, for example: 
 
2013-02-08-04.22.00.246987-360 I1022004A4198      LEVEL: Severe 
PID     : 74262                TID  : 24000       PROC : db2sysc 
1 
INSTANCE: db2inst1             NODE : 001         DB   : SAMPLE 
APPHDL  : 0-31789              APPID: *N0.db2inst1.130209025546 
AUTHID  : DB2INST1 
EDUID   : 24000                EDUNAME: db2agntp (SAMPLE) 1 
FUNCTION: DB2 UDB, buffer pool services, 
sqlbContainerTagIsValid, probe:100 
DATA #1 : String, 20 bytes 
*pTag(CONTAINER_TAG) 
DATA #2 : Hexdump, 512 bytes 
<...snip...> 
CALLSTCK: (Static functions may not be resolved correctly, as 
they are resolved to the nearest symbol) 
  [0] pdLog 
  [1] pdLog@glue436 
  [2] sqlbContainerTagIsValid 
  [3] sqlbDMSAddContainerRequest 
  [4] sqlbDoDMSAddContainerRequests 
  [5] sqlbDMSAddContainersToNewPool 
  [6] sqlbDMSCreatePool 
  [7] sqlbSetupPool 
  [8] sqlbCreatePool 
  [9] sqldPoolCreate 
 
2013-02-08-04.22.00.261564-360 I1026203A3137      LEVEL: Severe 
PID     : 74262                TID  : 24000       PROC : db2sysc 
1 
INSTANCE: db2inst1             NODE : 001         DB   : SAMPLE 
APPHDL  : 0-31789              APPID: *N0.db2inst1.130209025546 
AUTHID  : DB2INST1 
EDUID   : 24000                EDUNAME: db2agntp (SAMPLE) 1 
FUNCTION: DB2 UDB, buffer pool services, 
sqlbContainerTagIsValid, probe:200 
DATA #1 : Codepath, 8 bytes 
2:3:10:11:12:14:15:16 
DATA #2 : String, 19 bytes 
iTag(CONTAINER_TAG) 
DATA #3 : Hexdump, 512 bytes 
<...snip...> 
 
2013-02-08-04.22.00.264301-360 I1029341A580       LEVEL: Severe 
PID     : 74262                TID  : 24000       PROC : db2sysc 
1 
INSTANCE: db2inst1             NODE : 001         DB   : SAMPLE 
APPHDL  : 0-31789              APPID: *N0.db2inst1.130209025546 
AUTHID  : DB2INST1 
EDUID   : 24000                EDUNAME: db2agntp (SAMPLE) 1 
FUNCTION: DB2 UDB, Common Trace API, sqlbfix, probe:1657 
DATA #1 : String, 56 bytes 
sqlbDMSAddContainerRequest - rc == SQLB_CONTAINER_IN_USE 
DATA #2 : Hexdump, 4 bytes 
0x07000001157FA9B4 : 8002 0039 
...9 
 
2013-02-08-04.22.00.289508-360 E1029922A937       LEVEL: 
Critical 
PID     : 74262                TID  : 24000       PROC : db2sysc 
1 
INSTANCE: db2inst1             NODE : 001         DB   : SAMPLE 
APPHDL  : 0-31789              APPID: *N0.db2inst1.130209025546 
AUTHID  : DB2INST1 
EDUID   : 24000                EDUNAME: db2agntp (SAMPLE) 1 
FUNCTION: DB2 UDB, RAS/PD component, pdStartFODC, probe:10 
MESSAGE : ADM14001C  An unexpected and critical error has 
occurred: "Panic".
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* all                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* First Fixed in DB2 V101 FP3                                  * 
****************************************************************
Local Fix:
Ensure the container paths are unique for every node in the 
cluster.
available fix packs:
DB2 Version 10.1 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows

Solution
First Fixed in DB2 V101 FP3
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
22.04.2013
14.10.2013
14.10.2013
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)
10.1.0.3 FixList
10.1.0.3 FixList