ADSM-L

Re: AW: (Too) long no query restore?

2006-02-27 11:31:12
Subject: Re: AW: (Too) long no query restore?
From: "Whitlock, Brett" <brett.whitlock AT COUNTRYFINANCIAL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 27 Feb 2006 10:30:43 -0600
Are TSM Windows servers included?  


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Rainer Wolf
Sent: Monday, February 27, 2006 3:27 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] AW: (Too) long no query restore?

Hi,
 don't think so . Had this problem some years ago on aix-tsm 5.1.x
server and now actually the same on solaris-tsm 5.3.2.1 server.

When migrating from aix to solaris I first thought this problem has
evacuated. Moving our cyrus-mail-server on the new platform the restore
was continously very good - even after 8 months ( we have retver=45 ) .
The data to be restored is located on 2-4 tapes (3592) and disk-cache.
The relation between aktive - inactive files for this node is about
4.2 mio aktive files  + 1.1 mio inactive files.
Because of the fantastic new drives we did not do any tape-reclamation
and we had no problems at all.
Because my collegue who normally do the restorals on mail-folders (
mostly just some hundred files up to some thousand using
a restore command like   ' dsmc restore
/mail/imap/x/user/xuser/remfolder/ ' )
is sitting vis-a-vis I know that the restore-performance was always very
good.
Then I said to him   -ohhh we should use the tapes a bit more before
running out of warranty-  and started some reclamations on tapes being
full and with a usage of lets say 20% or less.
Thus one of the tapes the mail-server-tsm-client has data on ( the
storagepool has node-collocation) has reclaimed ...
... and uuuuuups  : the old problem ( waiting for files ...) suddenly
arised again.
So another 'workaround' might be not to use reclamation ;-)

Greetings
Rainer


"Whitlock, Brett" wrote:
>
> Is this problem platform specific?
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Richard Sims
> Sent: Friday, February 24, 2006 9:47 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] AW: (Too) long no query restore?
>
> Ironically, the most crucial part of the TSM product - restoral - has 
> become its most troublesome.  Since the advent of the well-intentioned

> NQR, when customers perform qualified restorals they never know what 
> to expect in terms of restoral speed.
> Indeed, restorals can end up being prohibitively long.
>
> I'm incredulous that IBM *still* has not tackled and resolved this 
> long-festering problem in the product, which has simply lingered for 
> years now.  Descriptive APARs and Technotes only tell of alternatives 
> for when the customer runs into a debilitating restoral, but we see no

> initiative to address the architectural problems.  TSM is an 
> Enterprise level product, and yet a crippling problem of this severity

> remains in it?
> Not good.
>
>     Richard Sims
>
> On Feb 24, 2006, at 10:22 AM, Rainer Wolf wrote:
>
> > Hi,
> >
> > I often experienced this and was in discussion with IBM - at last it

> > was closed by ibm-support with a point to
> > http://www-1.ibm.com/support/docview.wss?uid=swg1IC34713
> > IC34713: PERFORMANCE
> >          DEGRADATION WHEN
> >          RUNNING NO QUERY
> >          RESTORES
> > I don't know why this old one is still active ( tsm 4.2 ) ??
> >
> > In our case the performance-problem arised at that point when the 
> > first reclamation-process has run on a tape on which the client has 
> > data on ... maybe also by hazard.
> > For me that problem sometimes seems to be the most alarming one in 
> > TSM.
> >
> > Greetings
> > Rainer

--
------------------------------------------------------------------------
Rainer Wolf                          eMail:       rainer.wolf AT uni-ulm DOT de
kiz - Abt. Infrastruktur           Tel/Fax:      ++49 731 50-22482/22471
Universitaet Ulm                     wwweb:        http://kiz.uni-ulm.de

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