|
Problem IC68446
|
Status: Closed |
FUTURE-DATED TIMESTAMPS REPORTED BY THE DEADLOCK MONITOR ON SOLARIS X86-64 |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
On the Solaris 64-bit platform, running on the x86-64
architecture, when using the deadlock event monitor while
running DB2, you might see timestamps that are future-dated,
with respect to the system time, in the formatted event monitor
output.
Example:
select current timestamp from sysibm.sysdummy1
1
--------------------------
2010-02-08-11.58.07.170382
450272) Deadlock statement history ...
Deadlock ID : 0
Participant No : 0
Application id : *LOCAL.<instname>.xxxxxxx
Stmt history ID : 502
Type : Dynamic
Section No : 5
Package cache id : 382252089561
Package creator : NULLID
Package name : SYSSH200
Package version :
Lock timeout value : 60
Nesting level of stmt : 0
Invocation ID : 0
Query ID : 0
Source ID : 0
UOW Sequence number : 0001
Isolation level : Cursor Stability
Stmt first use time : 02/27/2010 15:13:26.876148
Stmt last use time : 02/27/2010 15:13:26.877157
Statement text : SELECT CREATE_TIME FROM
SYSTOOLS.HMON_ATM_INFO WHERE SCHEMA = ? AND NAME = ? FOR UPDATE
The "Stmt first use time" and "Stmt last use time" show
future-dated timestamps when compared to the current timestamp
on the server. This is a result of the underlying implementation
used to generate the timestamp data. Note that the problem has
only been seen with the deadlock event monitor, but may not be
limited to it. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* DB2 on Solaris X86-64 *
****************************************************************
* PROBLEM DESCRIPTION: *
* On the Solaris 64-bit platform, running on the *
* x86-64 architecture, when using the deadlock event monitor *
* while running DB2, you might see timestamps that are *
* future-dated, with respect to the system time, in the *
* formatted event monitor output. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 Version 9.7 Fix Pack 3 or use the local fix *
* as a workaround. *
**************************************************************** |
| Local Fix: |
If the time drift grows to be intolerably substantial over time,
terminate all connections to the database, whose deadlock
monitor exhibits this problem, and reconnect. |
| 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 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 |
Problem was first fixed in DB2 Version 9.7 Fix Pack 3. |
| Workaround |
If the time drift grows to be intolerably substantial over
time,
terminate all connections to the database, whose deadlock
monitor exhibits this problem, and reconnect. |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 05.05.2010
20.09.2010
20.09.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
|
|
