|
Problem IC87905
|
Status: Closed |
IN A HADR SYSTEM, THE REPLAY OF VIEW REGENERATION ON STANDBY DOESN'T ENABLE REPLAY ONLY WINDOW. |
| product: |
DB2 FOR LUW / DB2FORLUW / A10 - DB2 |
| Problem description: |
Regeneration of view updates the system catalog's. When this
catalog update is replayed on standby replay only window should
be enabled but it is not. Due to this, applications trying to
access the particular catalog table could see a corrupted LOB
thus bringing down the standby database. A simple repro that
could trigger this situation is
create table t1 (c1 int)
create view v1 as select * from t1
drop table t1
create table t1 (c1 int)
select * from v1 |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* DB2 LUW HADR users with reads on standby enabled on standby *
****************************************************************
* PROBLEM DESCRIPTION: *
* Problem: *
* ---------- *
* Regeneration of a view changes catalog tables and updates *
* LOB columns. This is a DDL operation but due to the way it *
* is designed it doesn't go through the normal DDL code path. *
* When a view is regenerated it's not enabling the Replay Only *
* Window on Standby. *
* *
* Impact: *
* --------- *
* When the log's records for the regen view stmt are being *
* replayed on standby, readers on standby will not be blocked. *
* Applications trying to access the particular catalog table *
* could see a corrupted LOB thus bringing down the database. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 v10.1 fixpack 2. *
**************************************************************** |
| Local Fix: |
One can avoid the issue by manually terminating all applications
on standby before a regen view is being replayed. No new
applications should attempt to connect while the view
regeneration log records are replayed on standby.
In case, the database is brought down due to the mentioned
issue, restart the standby database. There should be no impact
to the database contents. It will come back normal. |
| available fix packs: |
DB2 Version 10.1 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows
|
| Solution |
The defect is fixed in DB2 v10.1 Fixpack 2 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 04.11.2012
18.12.2012
18.12.2012 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 10.1.0.2
|
 |
| 10.5.0.2
|
|
