|
Problem IC70418
|
Status: Closed |
CONNECT RESET (IMPLICIT OR EXPLICIT) MAY APPEAR TO HANG WHEN ALTER TABLESPACE TYPE OPERATIONS ARE RUNNING |
| product: |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 |
| Problem description: |
An CONNECT RESET operation (either an explicit CONNECT RESET, or
a CONNECT TO DB operation that invokes a connect-reset
implicitly because a connection already exists) may hang when an
ALTER TABLESPACE EXTEND/RESIZE/DROP type of operation is
running.
The latching protocol used by the connect-reset operation to
determine if the disconnecting application has quiesced any
tablespaces conflicts with latches that are held by the
alter-tablespace operation.
Stack dumps of the hanging processes will show:
- the connect-reset operation executing in
sqlbTerminateApplication and waiting for this readLatch:
"Waiting on latch type: (SQLO_LT_SQLB_POOL_CB__readLatch) -
Address: (0x643144fb8), Line: 6278, File: sqlbenvi.C"
- the alter-tablespace operation typically executing in
sqlbAlter... and holding this readLatch:
"Holding Latch type: (SQLO_LT_SQLB_POOL_CB__readLatch) -
Address: (0x643144fb8), Line: 5210, File: sqlbistorage.h"
The fix will prevent the connect-reset from waiting only if no
other application is holding a QUIESCE state on the tablespace
that is being altered. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* DB2 V9.5 *
****************************************************************
* PROBLEM DESCRIPTION: *
* An CONNECT RESET operation (either an explicit CONNECT *
* RESET, or *
* a CONNECT TO DB operation that invokes a connect-reset *
* *
* implicitly because a connection already exists) may hang *
* when an *
* ALTER TABLESPACE EXTEND/RESIZE/DROP type of operation is *
* *
* running. *
* *
* *
* *
* The latching protocol used by the connect-reset operation to *
* *
* determine if the disconnecting application has quiesced any *
* *
* tablespaces conflicts with latches that are held by the *
* *
* alter-tablespace operation. *
* *
* *
* *
* Stack dumps of the hanging processes will show: *
* *
* - the connect-reset operation executing in *
* *
* sqlbTerminateApplication and waiting for this readLatch: *
* *
* "Waiting on latch type: (SQLO_LT_SQLB_POOL_CB__readLatch) - *
* *
* Address: (0x643144fb8), Line: 6278, File: sqlbenvi.C" *
* *
* *
* *
* - the alter-tablespace operation typically executing in *
* *
* sqlbAlter... and holding this readLatch: *
* *
* "Holding Latch type: (SQLO_LT_SQLB_POOL_CB__readLatch) - *
* *
* Address: (0x643144fb8), Line: 5210, File: sqlbistorage.h" *
* *
* *
* *
* The fix will prevent the connect-reset from waiting only if *
* no *
* other application is holding a QUIESCE state on the *
* tablespace *
* that is being altered. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to V9.5 FP7 *
**************************************************************** |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
APAR fixed in DB2 V9.5 FP7 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 05.08.2010
20.12.2010
20.12.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.5.FP7
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.1.0.7
|
 |
| 9.5.0.7
|
|
