ADSM-L

Re: Restoring Database to new Location

2006-10-21 16:10:56
Subject: Re: Restoring Database to new Location
From: Jason Lee <english AT ANIM.DREAMWORKS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sat, 21 Oct 2006 13:09:36 -0700
My mistake, I meant dsmserv.dsk.

In the end I did it by editing the file and restoring the database.
Worked fine and I was (or could have been) done in about 3.5 hours.
Creating and deleting dbvs would have taken just around a week (with
a trailing wind), which was time I didn't have.


Thanks everyone for the input.


Jason



On Oct 20, 2006, at 1:24 PM, Prather, Wanda wrote:

Not to mention that if you use the recommended approach, you can do
everything while your TSM server is up and running!

Wanda Prather
"I/O, I/O, It's all about I/O"  -(me)


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf Of
Thomas Denier
Sent: Friday, October 20, 2006 4:19 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Restoring Database to new Location

-----Jason Lee wrote: -----

could anyone confirm that if one takes a backup of the database,
then changes the location of the database files in devconfig and
then does a restore of the db, it'll do the right thing and restore
to the new locations... assuming you have dbvs dsmfmt'd in place?

I have a 1/2 TB database to move, and going the delete dbv route
will take days to complete - hence the question.

The database file locations are not stored in the devconfig file.
They and the recovery file locations are in dsmserv.dsk. This file
is updated using the dsmserv command with the 'format' option.
A database restore will restore the database contents to whatever
files are listed in dsmserv.dsk even if the file locations are
different than the ones in use when the database was backed up. In
fact, the numbers and sizes of the files can be different as well,
as long as the total amount of space in the files is sufficient.
We have made these kinds of changes during disaster recovery tests.

That being said, I don't recommend this approach. The mirrored
volume manipulations mentioned in other responses strike me as a
safer approach. If you want the option of changing volume sizes
during the migrations, I would recommend defining new volumes and
deleting old ones despite the elapsed time this appraoch wouldtake.

<Prev in Thread] Current Thread [Next in Thread>