ADSM-L

Re: AIX Restore

2005-02-15 08:15:45
Subject: Re: AIX Restore
From: "Thach, Kevin G" <KThach AT COVHLTH DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 15 Feb 2005 08:15:30 -0500
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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Monday, February 14, 2005 8:41 PM
To: ADSM-L AT VM.MARIST DOT 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 hdesk AT covhlth DOT com.

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