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