Image Copy appears to have data but cannot recover from it.

Joel Pankonin

Image Copy appears to have data but cannot recover from it.
The data bandit got us again... thankfully in test environment only. One
of our programmers discovered a table that is missing 2.5 m rows, it's
completely empty. The recovery job runs with a zero return code but when I
go check the table and it's still empty. The catalog shows a partial
recovery point and when I look at the image copy I can see it has 8000+
tracks of data in it. Why is the recovery process acting like everything
worked? I tried this with the previous image copy and got same result. We
have BMC Recovery Manager doing the image copies for us and we're on DB2 v7.

Any suggestions?



David Wilson

Re: Image Copy appears to have data but cannot recover from it.
(in response to Joel Pankonin)
Have you rebuilt any indexes on your table?

Dave Wilson
MS Tech Support DBA
X4248



Joel Pankonin
<[login to unmask email] To: [login to unmask email]
RICHNA.COM> cc:
Sent by: DB2 Data Subject: Image Copy appears to have data but cannot recover from it.
Base Discussion
List
<[login to unmask email]
LASSOC.COM>


31/12/02 14:15
Please respond to
DB2 Data Base
Discussion List






The data bandit got us again... thankfully in test environment only. One
of our programmers discovered a table that is missing 2.5 m rows, it's
completely empty. The recovery job runs with a zero return code but when I
go check the table and it's still empty. The catalog shows a partial
recovery point and when I look at the image copy I can see it has 8000+
tracks of data in it. Why is the recovery process acting like everything
worked? I tried this with the previous image copy and got same result. We
have BMC Recovery Manager doing the image copies for us and we're on DB2
v7.

Any suggestions?



the DB2-L webpage at http://listserv.ylassoc.com. The owners of the list
can







*********************************************************************

Notice: This email is confidential and may contain
copyright material of the John Lewis Partnership.
If you are not the intended recipient, please
notify us immediately and delete all copies of this
message. (Please note that it is your responsibility
to scan this message for viruses).


*********************************************************************

John Lewis plc Registered in England 233462
Registered office 171 Victoria Street London SW1E 5NN

Websites: http://www.johnlewis.com and http://www.waitrose.com



Christopher Tee

Re: Image Copy appears to have data but cannot recover from it.
(in response to David Wilson)
Is the table in a multi-table tablespace? If so, check the image copy with
DSN1PRNT to see if it has rows for the table in question. Maybe somebody
did a load replace of one of the other tables.

Chris

PS Happy New Year (not sure why I'm still at work!)

-----Original Message-----
From: Joel Pankonin [mailto:[login to unmask email]
Sent: 31 December 2002 14:15
To: [login to unmask email]
Subject: Image Copy appears to have data but cannot recover from it.


The data bandit got us again... thankfully in test environment only. One
of our programmers discovered a table that is missing 2.5 m rows, it's
completely empty. The recovery job runs with a zero return code but when I
go check the table and it's still empty. The catalog shows a partial
recovery point and when I look at the image copy I can see it has 8000+
tracks of data in it. Why is the recovery process acting like everything
worked? I tried this with the previous image copy and got same result. We
have BMC Recovery Manager doing the image copies for us and we're on DB2 v7.

Any suggestions?







-----------------------------------------------------------------------------------------------------------------------
This e-mail is intended only for the above addressee. It may contain
privileged information. If you are not the addressee you must not copy,
distribute, disclose or use any of the information in it. If you have
received it in error please delete it and immediately notify the sender.

evolvebank.com is a division of Lloyds TSB Bank plc.
Lloyds TSB Bank plc, 71 Lombard Street, London EC3P 3BS. Registered in
England, number 2065. Telephone No: 020 7626 1500
Lloyds TSB Scotland plc, Henry Duncan House, 120 George Street,
Edinburgh EH2 4LH. Registered in Scotland, number 95237. Telephone
No: 0131 225 4555

Lloyds TSB Bank plc and Lloyds TSB Scotland plc are regulated by the
Financial Services Authority and represent only the Scottish Widows
and Lloyds TSB Marketing Group for life assurance, pensions and
investment business.

Signatories to the Banking Codes.
-----------------------------------------------------------------------------------------------------------------------

Marcel Harleman

Re: Image Copy appears to have data but cannot recover from it.
(in response to Christopher Tee)
Hi,

Maybe there has been a drop/create of the table? Imagecopy acts on a
tablespace partition level. Drop/create of a table does not invalidate
the imagecopy by removing the registration form SYSCOPY. What
drop/create does do is assigning new object-id's for the table (and
the indexes and so on, but that's of minor importance here). And the
recover simply replaces the contents of the tablespace partition
without minding the table.

It's possible to check whether this is the case by looking at the
creation timestamp of the table (f.i. in SYSIBM.SYSTABAUTH with
GRANTOR=GRANTEE) and comparing that with the timestamp the imagecopy
was taken.

If there has been a drop/create of the table after the imagecopy was
taken then you'll have to find out the object-id of the table before
drop/create, after which you can recover using DSN1COPY with
OBID-translation switched on. Of course there's a pre-requisite: the
table structure must not have been altered.

HTH.

Marcel.

>The data bandit got us again... thankfully in test environment only. One
>of our programmers discovered a table that is missing 2.5 m rows, it's
>completely empty. The recovery job runs with a zero return code but when I
>go check the table and it's still empty. The catalog shows a partial
>recovery point and when I look at the image copy I can see it has 8000+
>tracks of data in it. Why is the recovery process acting like everything
>worked? I tried this with the previous image copy and got same result. We
>have BMC Recovery Manager doing the image copies for us and we're on DB2 v7.
>
>Any suggestions?
>
>
>



Hessel Rus

Re: Image Copy appears to have data but cannot recover from it.
(in response to Marcel Harleman)
Joel,

In case you perform a recovery to current, perhaps the last executed sql
statement was: delete from table..... Then try a tocopy recovery





Joel Pankonin
<[login to unmask email] To: [login to unmask email]
RICHNA.COM> cc:
Sent by: DB2 Data Subject: Image Copy appears to have data but cannot recover from it.
Base Discussion
List
<[login to unmask email]
LASSOC.COM>


12/31/2002 03:15
PM
Please respond to
DB2 Data Base
Discussion List






The data bandit got us again... thankfully in test environment only. One
of our programmers discovered a table that is missing 2.5 m rows, it's
completely empty. The recovery job runs with a zero return code but when I
go check the table and it's still empty. The catalog shows a partial
recovery point and when I look at the image copy I can see it has 8000+
tracks of data in it. Why is the recovery process acting like everything
worked? I tried this with the previous image copy and got same result. We
have BMC Recovery Manager doing the image copies for us and we're on DB2
v7.

Any suggestions?



the DB2-L webpage at http://listserv.ylassoc.com. The owners of the list
can