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 IT03264 Status: Closed

Traps and/or Crashes in DPF During Query Activity Against a Db That Was
Previously Created with a Redirected Restore

product:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problem description:
This issue only occurs in a DPF environment. When a database is 
first created using the "CREATE DB" DDL, DB2 identifies this 
database with a db_seed. The db_seed is derived as a function of 
the database creation time and is assumed to be unique for every 
database in the DPF instance. This assumption is broken when a 
backed up database is used to create a copy database in the same 
instance via a redirected restore operation. In this case, it is 
possible to have two uniquely named databases sharing the same 
db_seed. Certain database operations that assume uniqueness of 
the db_seed will be broken. One such operation is the 
inconsistent maintenance of the participating node list for each 
database at the catalog node.  This node list is involved in 
ensuring that drop and alter DDL and other invalidating 
operations (like implicit or explict package rebinds) properly 
invalidate the package cache and the catalog cache on all 
relevant partitions.   With this issue, one or more partition 
may not be sent the invalidating operation - leaving stale and 
invalid entries in either the package cache or the catalog 
cache.    This may potentially lead to outages including traps, 
sql0901n and sql0902n errors for applications connected to 
either database that may occur during compilation or in 
execution of SQL; these errors would have their first point of 
failure at non-catalog partitions. 
 
Another problem that may occur is the successful deactivation of 
a database may not bring down the database even when user 
applications are no longer connected. 
 
A quick method to determine exposure to this issue is to check 
the db_seed of two databases. If they are the same, the problem 
exists. Use the following command to find the db_seed of each 
database. "db2pd -sqedbcb -db <dbname> | grep db_seed". 
 
Similarly, a sample trap  that may occur could be the following: 
 
<StackTrace> 
   ossDumpStackTraceInternal 
   ossDumpStackTraceV98 
   OSSTrapFile::dumpEx 
   sqlo_trce 
   sqloEDUCodeTrapHandler 
   sqlktopn 
   sqlriopn 
   sqlriReceiveDss 
   sqlrr_dss_router 
   sqlrr_subagent_router 
   sqleProcessSubRequest 
   sqeAgent::RunEDU 
   sqzEDUObj::EDUDriver 
   sqlzRunEDU 
   sqloEDUEntry 
</StackTrace>
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* All Users                                                    * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to latest fix pack.                                  * 
****************************************************************
Local Fix:
Solution
First fixed in fix pack 10
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
18.07.2014
15.12.2014
15.12.2014
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)
9.7.0.10 FixList