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 <[EMAIL PROTECTED]> Reply-To: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
