|
P: n/a
|
We use redirected restore to refresh test from prod on different AIX 5.2
servers. The databases have the same number, size and names of cooked
containers. The only difference is the fully qualified path contains a
different "SID": eg. "/db2/PRD/data1/..." versus "/db2/TST/data1/...".
(Please note as an SAP installation I cannot change this layout).
We use "set tablespace container" statements to redefine the fully
qualified container names. During the restore the existing containers are
dropped and new containers are created. This process takes a long time.
My question is, can we somehow avoid re-creating these containers. For
example, what would happen if we just created a symbolic link PRD->TST so
that the restore would find the existing containers? (I've done this
successfully using Informix raw devices.)
Or, do the containers need to be re-created for a valid restore?
Thanks,
Chris
--
Message posted via http://www.dbmonster.com | |
Share this Question
|
P: n/a
|
CCC via DBMonster.com wrote: We use redirected restore to refresh test from prod on different AIX
5.2 servers. The databases have the same number, size and names of cooked
containers. The only difference is the fully qualified path contains
a different "SID": eg. "/db2/PRD/data1/..." versus
"/db2/TST/data1/...". (Please note as an SAP installation I cannot change this layout).
We use "set tablespace container" statements to redefine the fully
qualified container names. During the restore the existing containers
are dropped and new containers are created. This process takes a long
time.
My question is, can we somehow avoid re-creating these containers.
For example, what would happen if we just created a symbolic link
PRD->TST so that the restore would find the existing containers? (I've done this
successfully using Informix raw devices.)
Or, do the containers need to be re-created for a valid restore?
Thanks,
Chris
--
Message posted via http://www.dbmonster.com
UDB does not allow links for restores. As a matter of fact, you cannot
even create a database using containers that are links.
"set tablespace containers...." command simply re-defines containers.
When you do a "restore db DBName continue", this is when the restore
process actually starts. Restore is still a restore and takes its sweet
time regardless -- whether it be regular or redirected restore. If UDB
were to allow links, I don't think you will see any significant
difference in restore time.
BTW, I agree with you -- Informix does have this flexibility.
Keith Ponnapalli
IBM Certified Advanced Database Administrator - DB2 UDB V8.1 for
Linux,UNIX, and Windows
INFORMIX Certified Database Administrator | |
|
P: n/a
|
Thank you. So "links" aren't a valid workaround. Maybe you could educate
me a bit. (I'm new to DB2, but do have Informix & Oracle experience).
When I simply restore a database (not "redirected"), I don't believe it
recreates the containers; it just starts restoring the data into the
existing containers. However, the redirected restore does rebuild DMS
containers. I can watch them being deleted and regenerated. I assume this
is a result of the "set tablespace containers". The transfer of data from
tape doesn't begin until all the containers are rebuilt. In fact we had to
increase TSM timeout settings to allow for this finish.
Am I doing something wrong here?
Chris
--
Message posted via http://www.dbmonster.com | |
|
P: n/a
|
"CCC via DBMonster.com" <fo***@nospam.DBMonster.com> wrote in message
news:08******************************@DBMonster.co m... We use redirected restore to refresh test from prod on different AIX 5.2
servers. The databases have the same number, size and names of cooked
containers. The only difference is the fully qualified path contains a
different "SID": eg. "/db2/PRD/data1/..." versus "/db2/TST/data1/...".
(Please note as an SAP installation I cannot change this layout).
We use "set tablespace container" statements to redefine the fully
qualified container names. During the restore the existing containers are
dropped and new containers are created. This process takes a long time.
My question is, can we somehow avoid re-creating these containers. For
example, what would happen if we just created a symbolic link PRD->TST so
that the restore would find the existing containers? (I've done this
successfully using Informix raw devices.)
==============
Yes, you can use symbolic link, you can also use redirected restore, both
should work in your scenario.
Or, do the containers need to be re-created for a valid restore?
===========================
DB2 restore will check if the tbspaces/containers are existed, if not, db2
will build them first, then restore the data.
Thanks,
Chris
--
Message posted via http://www.dbmonster.com | |
|
P: n/a
|
Please help me clarify a couple of questions:
Because I am cloning a source onto a target which has a different
DB2INSTANCE, database name, host, etc, I assume I must use a "redirected
restore". Just because I have links that make the target filesystem "look"
like the source system, I cannot do a regular restore. Is this correct?
Is the deletion and recreation of the exisiting containers I observe during
the redirected restore a result of the "set tablespace containers"
statements?
If this is true, given links that make the filesystems look the same, can I
do the redirected restore without using the "set tablespace constainers"
statements?
This would save me 2-3 hours on my 300GB database.
Thanks
Chris
--
Message posted via http://www.dbmonster.com | |
|
P: n/a
|
CCC via DBMonster.com wrote: Please help me clarify a couple of questions:
Because I am cloning a source onto a target which has a different
DB2INSTANCE, database name, host, etc, I assume I must use a
"redirected restore". Just because I have links that make the target filesystem
"look" like the source system, I cannot do a regular restore. Is this
correct?
Is the deletion and recreation of the exisiting containers I observe
during the redirected restore a result of the "set tablespace containers"
statements?
If this is true, given links that make the filesystems look the same,
can I do the redirected restore without using the "set tablespace
constainers" statements?
This would save me 2-3 hours on my 300GB database.
Thanks
Chris
--
Message posted via http://www.dbmonster.com
I guess I goofed on this one. Links will work. You can use 'restore
from ...into targetDB ... ' , so it doesn't matter if it it's in
another instance/db.
I'd make sure links are supported/recommeneded by both IBM/SAP just in
case if something were to go wrong.
K | |
|
P: n/a
|
"CCC via DBMonster.com" <fo***@DBMonster.com> wrote in message
news:57******************************@DBMonster.co m... Please help me clarify a couple of questions:
Because I am cloning a source onto a target which has a different
DB2INSTANCE, database name, host, etc, I assume I must use a "redirected
restore". Just because I have links that make the target filesystem "look"
like the source system, I cannot do a regular restore. Is this correct?
============================
No, that isn't quite correct. If you have two physical boxes, two physical
instances/databases, the regular restore still can work very well.
You can build all the containers on your target and create links and makes
them exactly look like the source server.
You can run the restore, just like you run the restore on the source server.
db2 restore db source_db ... into target_db ...
You don't must run redirect restore in order to clone a database onto
another physical database.
In fact you can even restore into the target from an online backup image
which taken from the source server, if both target and source server used
the same db2 udb version, and you can run the rollforward to the end of
logs.
Is the deletion and recreation of the exisiting containers I observe
during the redirected restore a result of the "set tablespace containers"
statements?
I did redirect restore before. But never observe the whole process. I can't
understand why the restore need to delete something.
When you restore a database to the different place, you'd better build all
the necessary containers, instead of letting the restore process to build
them, which will impact the restore performance.
If this is true, given links that make the filesystems look the same, can
I do the redirected restore without using the "set tablespace constainers"
statements?
Again, for your case, you can just run a restore, w/o redirect.
This would save me 2-3 hours on my 300GB database.
Thanks
Chris
--
Message posted via http://www.dbmonster.com | |
|
P: n/a
|
Another option you might want to consider is the use of raw partitions
(i.e. tablespace containers of type device) since they don't need to be
'created' in a similar fashion to file based containers. A create
tablespace or set tablespace containers command takes no time on these
types of containers. The last time I tried it, it was possible to
convert from file to device and vice versa with a redirected restore.
regards
tim
| | This discussion thread is closed Replies have been disabled for this discussion. | |  Question stats - viewed: 5777
- replies: 7
- date asked: Nov 12 '05
|
