First, no you do not need to create the target database before doing a
restore. If it does not exist, it will be created automatically.
Second, the "table space inaccessible" error can happen if you have
user-specified paths for tablespaces in the original db. For example, if
you have a tablespace path of "/mytbspace", then tat path will also be
stored in the backup. When you try to restore from that backup, DB2 will
try to put your tablespace in that same path, and if your original
tablespace is already there, there will be a conflict. If this is the case,
you can use the "redirect" keyword on your restore command to specify a
different path for your tablespace, or you can just drop your original
database before attempting the restore.
--
Larry Menard
IBM Workstation Database (DB2) Information Development, Samples Coordinator
Defender of Geese and of All Things Natural
"Hakim" <ha***@pictsolution.com> wrote in message
news:c9**************************@posting.google.c om...
Hi there,
I am a rookie in DB2. I have tried to do a database restoration on my
system.
Since it should not go directly to our REAL database, I tried to
restore to a dummy database.
Below are my questions,
- should I create this dummy database first before I could restore?
- I also try to put this restoration into a specific logical volume
named /dummy
- these are the commands I used :
db2 restore db life2 from /dev/rmt0 to /dummy into dbtest
db2 restore db life2 from /dev/rmt0 to /dummy
System Info:
1. O/S : AIX 4.3
2. DB2 : Version 5.2
3. Tape : DDS 3
4. REAL db : life2
5. DUMMY db : dbtest
6. LV name : /dummy
some of the error messages: container already in use
Any ideas guys?
