It sounds like you are not sure as to what is happening with the restore.
You mention that there is activity with the TSM DB.  I would recommend
giving it another go.  Set a server and client trace.  Set your maxtrace
size to something manageable.  Then look and see if the client trace grows.
Check the server trace for anything that is registered against the server's
session id for the restore.

You may require the help of TSM support to analyze the trace if you have not
done so before.

JT

From: Roger Deschner <rogerd AT UIC DOT EDU>
Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Restore performance
Date: Tue, 11 Mar 2003 00:42:57 -0600

OK, I'll take a stab at this: You are pretty plainly asking for more
files to be restored than you realize. Specifying a simple subdirectory
to be restored, from even a filespace containing a vast number of files,
is fast. e.g. RESTORE /var/mail/johndoe/* Our end-users do it all the
time with the Unix linemode client dsmc command interface, and they're
not phoning me to complain that it performs badly. Every time you run an
ordinary incremental backup for this client node, a similar process
happens so that the TSM client program can figure out which files need
to be backed up this time. The "diff" is done on the client system after
downloading the full list of that node's files from the server to the
client. If that were as slow as you report, normal backups could never
happen. So something else has to be wrong, such as asking to restore a
lot more files than you really wanted, so that the list it is building
of the files you want restored is growing wildly.

Perhaps this is a typo in a wildcard specification. Perhaps you need to
specify a fully-qualified path here but you are only specifying a
relative path. Try specifying the -pick option on the restore command,
and see how many files it comes up with for you to pick from. Try
copying the exact specification you are using on the dsmc restore
command, into a unix ls command, and see how many files it lists. You
might be surprised with a lot of files - that you didn't want.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
               Academic Computing & Communications Center


On Mon, 10 Mar 2003, Thomas Denier wrote:

>We are attempting to perform a point in time restore for one of several
>thousand users on a large mail server. The file system involved contains
>almost four million files. The server is at level 4.2.3.2 and running
>under OS/390. The client is at level 5.1.1.0 and running under Linux
>at a 2.4.9-34s kernel level. The system administrator has declined to
>offer any estimate of the number of files to be restored. Several
>attempts to carry out the restore have been terminated to allow normal
>backup processing to run. In desparation we have suspended normal
>expiration and reclamation processing to enable the restore to get as
>much of the server's resources as possible. We also restarted the
>server to ensure that server memory management was as clean as possible.
>The restore has been running for nearly an hour with no data movement to
>or from the client and no tape mount requests. It is presumably figuring
>out which files to restore and where the files are located. Tivoli
>has never thought it necessary to provide any sort of progress indicator
>for this kind of processing. However, 'query db f=d' commands show
>almost eight million buffer requests, most of them presumably from the
>restore. How does the number of buffer requests scale with the number
>of files to be restored?
>

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail