I'm trying to do a socalled IMAGECOPY, extept this is on DB2 LUW 8.2 on Windows.

I've done a full offline backup and here's mu current environment:

DB = SDBT
Containers in D:\DBSPACE

I want to create a full copy of SDBT in the same instance, with the name SMIG. I also want SMIG to have its own containers under D:\SMIGSPACE

---

I've tried several commands from the manual, and the wizard in the GUI, but it always ends with either containers in use, or unknown system error.

---

A couple of questions.
- Should I use redirectet restore ?
- If yes, should I change the path for all system containers or only the custom ?

I've issued:

db2 restore database sdbt from d into smig redirect without prompting
db2 set .... (with the new path)
db2 restore sdbt continue

---

When I continue I get the different errors ...

Our DBA is not available till tomorrow, and we need a copy to work on.
Thank you in advance.

Though I would always recommend redefining all containers, actaully only the custom ones require redefinition ..

When you say 'Container in use' which container is it complaiing about ... I remember to have experienced this atleast once in the past -- If one redirected restore fails midway - the next attempt complains - 'container in use' and the next attempt succeeds ..

Before you re-attempt the redirected restore, drop the database and also make sure the 'new' container is also deleted ... Otherwise, delete manually ...

HTH

Sathyaram

Is it not true that in a redirected restore that the target DB needs to be created?

No, you can restore as a new database

is a full redirected restore tricker than restoring into a new DB?

It depends what you mean 'tricker' ..

Generally I say 'No' ... Use 'WITHOUT PROMPTING' if you want to avoid manual intervention ..

Also, remember, if you are restoring to an exisiting db, the db cfg is retained as it is for the old db ,...

HTH

Sathyaram

I've struggled back and forth, but evry time I fix the container issues with a redirected restore, I get an unknown error.

I will come back with the solution if I find one. I'm suspecting the Federated Objects in the backup to be the source of some conflict.

db2diag.log should give some clue on the error ..

Set the diaglevel dbm cfg to 4

Sathyaram

Between successive redirected restores, you do not need to drop the database. You can just UNTAG the target (not the source)containers with db2untag -f FN where FN is the full filename. In a previous restore, the pages will have been created and in a large db it could take a long time. I refresh test db with prod data and i have had good luck with db2untag. I untag all test db container files.