We have a test database server that we frequently have to "refresh" by performing a virtualnode restore of the production database onto it. Occasionally, we perform the same restore again after some application testing has been performed to return to the baseline. Even when doing the EXACT same restore (exact same data, exact same tapes, exact same client, and no reclamation has been run), sometimes it multi-threads, sometimes it doesn't. To me, that's a bug.
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Monday, February 14, 2005 8:41 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: AIX Restore On Feb 14, 2005, at 4:03 PM, Thach, Kevin G wrote: > We see the exact same behavior when attempting to perform > multi-threaded restores using the "resourceutilization" parameter and > the maxnummp = x. > > As you say, some of the time it works as expected, sometimes it does > not. ... What I think is going on in all this... The amount of parallelism you can achieve in such a restoral is limited by practical realities. Various IBM site Technotes supplement the client manual in providing further insights into NQR restorals. For example, recent Technote 1067365 says that the server starts sending data to the client as soon as it comes up with some candidates, and resumes plowing through the database. We all know how painful it is to perform a Select on the Contents table, particularly in large TSM servers housing hundreds of millions of files. Even running at non-SQL, native database search speed, it's going to take time for the server to gather up all the candidates - worse so as the restoral request is more complex. (Some options cause fall-over to Classic Restore on the client, which can make things even slower, as clients are usually less powerful than a server system.) This is all to say that the entire list of candidate files may not be available as the restoral starts - and we would be complaining about restoral times if the scheme was that the full list be constituted before the restoral process begins. The only answer here may be dramatically better and far more modern database technology, to better deal with the enormous object populations of contemporary data processing - particularly as regulatory requirements call for retaining more data than ever. Richard Sims This E-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended only for the use of the Individual(s) named above. If you are not the intended recipient of this E-mail, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination or copying of this E-mail is strictly prohibited. If you have received this E-mail in error, please immediately notify us at (865)374-4900 or notify us by E-mail at [EMAIL PROTECTED]