DB2 V8 for z/OS Unload from a dropped table's FIC

Ruediger Kurtz

DB2 V8 for z/OS Unload from a dropped table's FIC
Hi everyone out there,

yesterday we experienced the following scenario:

We accidentally dropped a table, but since we had an image-copy from that very day we didn't think that we might run into big trouble; we unloaded the image-copy and got the following warning:
DBT2 DSNUULIA - TABLESPACE DT7DB990.TMKUN013 IS EMPTY

OK, we thought, just re-create the table and everything will be fine.

After we recreated the table we re-ran the unload and this time we got
DSNUUNLD - UNLOAD PHASE STATISTICS - NUMBER OF RECORDS UNLOADED=0

A RECOVER TO COPY also produced an empty table.

We then checked via DSN1PRNT and IEBGENER and found that the data we were looking for was actually in the dataset, but apparently DB2 couldn't get to it.

We do think that all this is because of a change of the table's OBID, but our question runs as follows:

Is this a WAD-issue ?

Any comments or suggestions are highly appreciated.

TIA Ruediger

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Michael Ebert

Re: DB2 V8 for z/OS Unload from a dropped table's FIC
(in response to Ruediger Kurtz)
Yes it's WAD (at least under V7, but I don't think V8 changed the UNLOAD
semantics that much). DB2 knows that the IC is not from the same table as
the one you currently have and it's protecting you from all sorts of data
inconsistency issues. Use DSN1COPY with OBIDXLAT and RESET to trick DB2.
The usual DSN1COPY caveats apply. Also note: DB2 COPY and RECOVER are
designed to protect you from media failure, nothing else. They're
definitely not for drop recovery.

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany




Kurtz, Rüdiger <[login to unmask email]>
To
[login to unmask email]
cc

bcc

Subject
[DB2-L] DB2 V8 for z/OS Unload from a dropped table's FIC





Kurtz, Rüdiger <[login to unmask email]>
Please respond to DB2 Database Discussion list at IDUG
<[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
12-12-06 14:49


Hi everyone out there,

yesterday we experienced the following scenario:

We accidentally dropped a table, but since we had an image-copy from that
very day we didn't think that we might run into big trouble; we unloaded
the image-copy and got the following warning:
DBT2 DSNUULIA - TABLESPACE DT7DB990.TMKUN013 IS EMPTY

OK, we thought, just re-create the table and everything will be fine.

After we recreated the table we re-ran the unload and this time we got
DSNUUNLD - UNLOAD PHASE STATISTICS - NUMBER OF RECORDS UNLOADED=0

A RECOVER TO COPY also produced an empty table.

We then checked via DSN1PRNT and IEBGENER and found that the data we were
looking for was actually in the dataset, but apparently DB2 couldn't get
to it.

We do think that all this is because of a change of the table's OBID, but
our question runs as follows:

Is this a WAD-issue ?

Any comments or suggestions are highly appreciated.

TIA Ruediger

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm