|
Problem IC70044
|
Status: Closed |
If db2ckmig is not run prior to upgrading a database, database upgrade will halt and require downlevel database recovery. |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
db2ckmig is a required pre-upgrade step for all databases on all
nodes (in Data Partitioned environments). One of its tasks is
to identify orphan rows which will cause database upgrade to
fail midway. These orphan rows, should they exist, need to be
cleaned up prior to upgrading to the new release.
If db2ckmig was skipped for any reason, and orphan rows exist,
database upgrade will fail. To alleviate the need of reverting
back to the downlevel release, a new internal registry variable
will allow the database to complete the upgrade leaving the
orphan rows in place. They will then require cleanup
immediately after the upgrade is complete.
Please contact DB2 Support to learn how to enable this registry
variable, and help perform the orphan row cleanup post-upgrade.
Orphan rows during upgrade can be identified by the following
types of db2diag.log entries:
2009-xx-xx-xx.xx.xx.xxxxxx-xxx xxxxxxxxxxxx LEVEL: Severe
PID : xxxxxx TID : xxxx PROC : db2sysc
0
INSTANCE: xxxxxx NODE : 000 DB : xxxxxx
APPHDL : 0-12 APPID: *LOCAL.xxxxxx.xxxxxxxxxxxx
AUTHID : xxxxxx
EDUID : xxxx EDUNAME: db2agent (xxxxxx ) 0
FUNCTION: DB2 UDB, relation data serv, sqlrr_dump_ffdc,
probe:300
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
sqlcaid : SQLCA sqlcabc: 136 sqlcode: -902 sqlerrml: 36
sqlerrmc: Migration DMS rc=80040001: DB2.SSER
sqlerrp : SQLRM028
sqlerrd : (1) 0x00000001 (2) 0x00000001 (3)
0x00000000
(4) 0x00000003 (5) 0xFFFFF35F (6)
0x00000000
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
sqlstate: |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Users doing the database upgrade without running db2ckmig. *
****************************************************************
* PROBLEM DESCRIPTION: *
* Without this APAR, customer is exposed to the issue as *
* described in the "ERROR DESCRIPTION" section. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to product version DB2 Version 9.7, Fixpack 3. *
**************************************************************** |
| Local Fix: |
n/a |
| available fix packs: |
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 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
First fixed in DB2 Version 9.7, Fixpack 3. |
| Workaround |
n/a |
| Comment |
Suggested improvement in the code. |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 21.07.2010
13.10.2010
13.10.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP3
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.3
|
 |
| 9.7.0.3
|
|
