I have never been able to do a simple 'select * from volumeusage'.  It will 
always
hang the server which is 3.7.3.8 on os/390 r6.  I think the problem compared to
other tables is that volumeusage may not be a real table in the database.
Instead I think it is really just a select on the contents table which is 
massive.

Anyone who depends on data from volumeusage might consider opening a
problem with IBM/Tivoli.  Really bad performance can be reported and will 
sometimes
be fixed instead of getting the dread 'working as designed' response.
I have always used occupancy data to make reports.  In version 1
it was slow but not too bad.  In version 2 if got much worse.  I opened
a problem for this and it got fixed, after about 6 months.  The fix was great!
A full read out of occupancy went from 5 hours to 10 minutes or less.
So consider calling in a problem, you might be pleased with the result!


--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <OFEFF0215A.A01EA002-ONCA25698C.001C68B3 AT agl.com DOT au>, on 11/03/00
In <OFEFF0215A.A01EA002-ONCA25698C.001C68B3 AT agl.com DOT au>, on 11/03/00
   at 03:29 PM, Geoff Fitzhardinge <gfitzhar AT AGL.COM DOT AU> said:

>I am still on ADSM 3.1 with OS/390.  I have found variants of this query
>impossible to
>run during normal hours, when other users (online business) seem to think
>they are
>more important than mere housekeeping functions.

>Running out of hours, my query (select node_name from volumeusage where
>stgpool_
>name='xxx') can run for a couple of hours using virtually all of a 60 MIPS
>engine.

>The volumeusage table has more rows than you might think.  There seems to
>be a row
>for each "collocation cluster" on a cartridge, and on 20GB volumes with
>data from the
>Lotus Notes agent, I sometimes see many hundreds of clusters on one volume.
>Even
>so, with only a hundred or so volumes, I find the CPU consumption rather
>over the odds.

>Maybe it gets worse with 3.7, but it would be worth having a look at the
>dispatching priority
>of your TSM server, and what other work might have been running at the same
>time.

>Good luck,
>Geoff Fitzhardinge
>Australian Gas Light Company