|
Problem IC87326
|
Status: Closed |
DB2 INSTANCE CRASH IN SQLUCONVDATATOTARGET() DURING LOAD INTO TABLE |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
Instance will crash in SQLUCONVDATATOTARGET() during load when
all the following conditions are present.
repro scenario:
db2 "create table t1 (c1 long varchar, c2 varchar(100))"
db2 "insert into t1 values ('hi', 'hello')"
db2 "export to t1.ixf of ixf select c1, c2 from t1"
db2 "create table t2 (a1 varchar(100), a2 char(100) generated
always as (a1))"
db2 "load from t1.ixf of ixf modified by generatedignore replace
into t2" <=== DB2 crashes
1. Input data file is IXF type, and has a long varchar column
( Using our example, the first column c1 in t1.ixf is of long
varchar type)
Also be aware that there is a possibility of getting a long
varchar type in ixf file if we export from DB2 iSeries (even
when column is casted to varchar type)
2. We are loading the long varchar data into a char or varchar
column
(column a1 in table t2 in our example)
3. The load target table has a generated column whose value
depends on the char/varchar column mentioned previously
(in our example, a2 is a generated column whose value depends
on a1, a1 being the char/varchar column where we are loading a
long varchar data into)
4. LOAD is actually generating the value for the generated
column
(in our example, if we only export column c1 into t1.ixf, and
don't specify any "modified by generated...." option, then LOAD
will also generate a2's value and we will also hit the problem)
(in our example, if we use "modified by generatedoverride"
instead of "modified by generatedignore", then LOAD will insert
the 'hello' from the t1.ixf input data file into column a2,
instead of generating a2's value, and we will NOT hit this
problem.)
5. No codepage conversion involved (i.e. codepage of data in ixf
file is the same as database codepage).
Stack generated similar to the following
Stack #1 Signal #11 Timestamp
2012-09-12-14.23.59.339544
0 sqluConvDataToTarget
1 sqluCGenColDataFormatter::iBindInValues
2 sqluGenBindIn
3 sqlribni
4 sqlriSectInvoke
5 sqluCGenColDataFormatter::iExecuteSection
6 sqluCGenColMgr::iProcessGeneratedCols
7 @148@sqluGetAndFormatRecords
8 sqluCFormatter::iRun
9 sqluLoadEDUDriver
10 sqloEDUEntry |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* ALL *
****************************************************************
* PROBLEM DESCRIPTION: *
* Instance will crash in SQLUCONVDATATOTARGET() during load *
* when *
* all the following conditions are present. *
* *
* *
* repro scenario: *
* *
* db2 "create table t1 (c1 long varchar, c2 varchar(100))" *
* db2 "insert into t1 values ('hi', 'hello')" *
* db2 "export to t1.ixf of ixf select c1, c2 from t1" *
* db2 "create table t2 (a1 varchar(100), a2 char(100) *
* generated *
* always as (a1))" *
* db2 "load from t1.ixf of ixf modified by generatedignore *
* replace *
* into t2" <=== DB2 crashes *
* *
* *
* *
* 1. Input data file is IXF type, and has a long varchar *
* column *
* ( Using our example, the first column c1 in t1.ixf is of *
* long *
* varchar type) *
* Also be aware that there is a possibility of getting a *
* long *
* varchar type in ixf file if we export from DB2 iSeries (even *
* when column is casted to varchar type) *
* *
* 2. We are loading the long varchar data into a char or *
* varchar *
* column *
* (column a1 in table t2 in our example) *
* *
* 3. The load target table has a generated column whose value *
* depends on the char/varchar column mentioned previously *
* (in our example, a2 is a generated column whose value *
* depends *
* on a1, a1 being the char/varchar column where we are loading *
* a *
* long varchar data into) *
* *
* 4. LOAD is actually generating the value for the generated *
* column *
* (in our example, if we only export column c1 into t1.ixf, *
* and *
* don't specify any "modified by generated...." option, then *
* LOAD *
* will also generate a2's value and we will also hit the *
* problem) *
* (in our example, if we use "modified by *
* generatedoverride" *
* instead of "modified by generatedignore", then LOAD will *
* insert *
* the 'hello' from the t1.ixf input data file into column a2, *
* instead of generating a2's value, and we will NOT hit this *
* problem.) *
* 5. No codepage conversion involved (i.e. codepage of data in *
* ixf *
* file is the same as database codepage). *
* *
* *
* Stack generated similar to the following *
* *
* Stack #1 Signal #11 Timestamp *
* 2012-09-12-14.23.59.339544 *
* 0 sqluConvDataToTarget *
* 1 sqluCGenColDataFormatter::iBindInValues *
* 2 sqluGenBindIn *
* 3 sqlribni *
* 4 sqlriSectInvoke *
* 5 sqluCGenColDataFormatter::iExecuteSection *
* 6 sqluCGenColMgr::iProcessGeneratedCols *
* 7 @148@sqluGetAndFormatRecords *
* 8 sqluCFormatter::iRun *
* 9 sqluLoadEDUDriver *
* 10 sqloEDUEntry *
****************************************************************
* RECOMMENDATION: *
* upgrade to V9.7 Fix Pack 8 *
**************************************************************** |
| Local Fix: |
Use import |
| available fix packs: |
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
|
| Solution |
Fixed in V9.7 Fix pack 8 |
| Workaround |
Use import |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC91272
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 17.10.2012
02.04.2013
02.04.2013 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP8
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.8
|
 |
