Thomas,
I agree with Richard Sims, you're probably between a rock and a hard place.
If you're not able to get your restore working reasonably quickly, here's
something you might try. It's a little bit of work, but it should work.
dsmadmc -id=id -pa=pa -comma -out=tempfile select \* from backups where
node_name=\'NODENAME\' and filespace_name=\'/FSNAME/\' and filespace_id=ID
and state=\'INACTIVE_VERSION\' and TYPE=\'DIR\' and hl_name like
\'dir.to.restore.within.FS\%\'
Then process the tempfile to create a list of the directories that have
files you want restored (sorting, filtering, whatever). I would probably
use the deactivate_date to just get the directories that were deactivated at
the right date (doable within the select, but it might tell you something to
see all of them), then trim out the various unnecessary columns and
concatenate hl_name and ll_name, get rid of any duplicates. Run a script
that does a dsmc restore -pitd for each line of the temp file without the
-subdir=yes command. That will speed things up considerably and you'll be
able to monitor progress. Additionally, if necessary, you can stop the
script and pick up where you left off without having to redo the whole
thing.
Good luck.
Alex Paschal
Freightliner, LLC
(503) 745-6850 phone/vmail
-----Original Message-----
From: Thomas Denier [mailto:Thomas.Denier AT MAIL.TJU DOT EDU]
Sent: Thursday, March 13, 2003 7:17 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Restore performance
> Because of the -subdir=yes specification, omitting the ending slash could
> cause TSM to search for all files named "saa001" in /var/spool/imap/user
> and its subdirectories. If these are very large, then that could be the
> cause of the Based on the size of these directories, it could be very
> timeconsuming. Also, it is good practice to put an ending slash after the
> target directory name.
>
> Putting the ending slashes should make things better, plus you should get
> the benefit of no query restore.
We have retried the restore with the trailing slashes, and things have
not gotten any better.
The performance of our TSM server degrades over time. We are finding it
necessary to restart the server at least twice a day to maintain
even marginally acceptable performance. Unfortunately, we are finding
that the end of support for 4.2 has, for all practical purposes, already
happened. It seems clear that IBM's strategy for responding to our
performance problem is to stall until April 15. We are concentrating
on completing tests of the 5.1 server, and living with the frequent
restarts in the meantime. The last few attempts at the problem restore
have not gotten as far as requesting a tape mount before a server
restart occured. The restart terminate the restore session but leaves
a restartable restore behind. The client administrator has issued
'restart restore' commands after the last couple of restarts, arguing
that this will enable restore processing to pick up where it left off.
Is he correct, given that the restore process was terminated before
it got as far as requesting its first tape mount?
|
