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  


Christoph Pilgram wrote:
> 
> Hi
> I had the same problem, and as Wanda wrote I tried it with the TESTFLAG
> DISABLEQR and it finished in about 5 minutes. Another test was : do the
> complete restore with the exception of one file in one of the subdirectories
> : did run in 5 minutes.
> 
> Best wishes
> Christoph
> 
> -----Ursprüngliche Nachricht-----
> Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag 
> von
> Prather, Wanda
> Gesendet: Mittwoch, 22. Februar 2006 17:06
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: (Too) long no query restore?
> 
> If you have the luxury of re-creating the problem, try again and put
> TESTFLAG DISABLENQR in the dsm.opt file (search on DISABLENQR in the
> archives to see what people have said about this before).
> 
> That turns off NQR and uses CLASSIC restore.  It is known that sometimes
> CLASSIC will outperform NQR.
> 
> If you get no difference in performance between the two, then you have
> something in your hardware config that needs tuning.
> 
> Wanda Prather
> "I/O, I/O, It's all about I/O"  -(me)
> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Thomas Rupp
> Sent: Wednesday, February 22, 2006 10:26 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: AW: [ADSM-L] (Too) long no query restore?
> 
> Some additional information:
> 
> Server: IBM eserver xSeries 346, Intel Xeon CPU, 3.2GHz
> Database: 20GB on 4 Volumes (EMC AX100)
> Storagepool: 1317GB on 13 Volumes (EMC AX100)
> 
> No tape activity is involved as all data (40MB) is restored from disk.
> 
> So TSM seems to spend most of the time scanning through the database.
> And I think more than 4.5 hours to scan 9.5 million files is way to
> long.
> 
> Thomas

-- 
------------------------------------------------------------------------
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