|
Problem IC64206
|
Status: Closed |
APPLICATION MAY FAIL WITH -901 WHEN ACCESSING DGTT DUE TO THE WRONG COUNTER INJECTED INTO THE CACHE BY ANOTHER CONNECTION |
| product: |
DB2 FOR LUW / DB2FORLUW / 910 - DB2 |
| Problem description: |
Applocation may fail with -901 when accessing DGTT due to the
wrong counter injected into the cache by another connection.
When the drop table fails on the DGTT due not able to write
a log record because of log full situation or for any other
reason, the "Number of active user temps" count is not
maintained.
Reproduction:
CONNECTION 1:
declare global temporary table t1 (i int) on commit preserve
rows not logged
commit
DROP table session.t1 -> force this to fail
rollback
insert into session.t1 values 1
CONNECTION 2:
insert into session.t1 values 1 --> fails with -901 as
the cached entry from connection 1 was incorrectly
resolved due to the wrong counter that was injected into the
cache by connection 1.
This is similar to LI73859, however this only occurs when there
is an error during logging - as we rely on the log record to
maintain the count of active user temps correctly.
SYMPTOM:
a) one of the following 2 errors:
SQL0901N The SQL statement failed because of a non-severe
system error.
Subsequent SQL statements can be processed. (Reason
"sqlrl_userTempOpen:
usertemp entry not found".) SQLSTATE=58004
or
SQL0901N The SQL statement failed because of a non-severe
system error.
Subsequent SQL statements can be processed. (Reason
"sqlrl_userTempIUD:
tid/fid not found".) SQLSTATE=58004
b) The db2diag.log should contain the following probes:
2009-10-14-14.57.03.172886-240 I1026949E507 LEVEL: Error
PID : 15116 TID : 183035119808PROC :
db2agent (xxxxxxxx) 0
INSTANCE: xxxxxxxx NODE : 000 DB :
NYGRCPI5
APPHDL : 0-143 APPID:
139.172.165.181.27102.091014184
AUTHID : xxxxxxx
FUNCTION: DB2 UDB, relation data serv, sqlrr_write_logrec,
probe:60
(there will likely be other probes about failure to write log
records) |
| Problem Summary: |
Users Affected: ALL
Problem Description:
Applocation may fail with -901 when accessing DGTT due to the
wrong counter injected into the cache by another connection.
When the drop table fails on the DGTT due not able to write
a log record because of log full situation or for any other
reason, the "Number of active user temps" count is not
maintained.
Problem Summary:
Reproduction:
CONNECTION 1:
declare global temporary table t1 (i int) on commit preserve
rows not logged
commit
DROP table session.t1 -> force this to fail
rollback
insert into session.t1 values 1
CONNECTION 2:
insert into session.t1 values 1 --> fails with -901 as
the cached entry from connection 1 was incorrectly
resolved due to the wrong counter that was injected into the
cache by connection 1.
This is similar to LI73859, however this only occurs when there
is an error during logging - as we rely on the log record to
maintain the count of active user temps correctly.
SYMPTOM:
a) one of the following 2 errors:
SQL0901N The SQL statement failed because of a non-severe
system error.
Subsequent SQL statements can be processed. (Reason
"sqlrl_userTempOpen:
usertemp entry not found".) SQLSTATE=58004
or
SQL0901N The SQL statement failed because of a non-severe
system error.
Subsequent SQL statements can be processed. (Reason
"sqlrl_userTempIUD:
tid/fid not found".) SQLSTATE=58004
b) The db2diag.log should contain the following probes:
2009-10-14-14.57.03.172886-240 I1026949E507 LEVEL: Error
PID : 15116 TID : 183035119808PROC :
db2agent (xxxxxxxx) 0
INSTANCE: xxxxxxxx NODE : 000 DB :
NYGRCPI5
APPHDL : 0-143 APPID:
139.172.165.181.27102.091014184
AUTHID : xxxxxxx
FUNCTION: DB2 UDB, relation data serv, sqlrr_write_logrec,
probe:60
(there will likely be other probes about failure to write log
records) |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.1 Fix Pack 9 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12 for Linux, UNIX and Windows
|
| Solution |
Problem was first fixed in Version 9.1 Fix Pack 9 |
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC64208 IC64209
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 29.10.2009
16.04.2010
16.04.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.1.FP9
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.1.0.9
|
 |
