Hmmm. I think you're right. I meant occupancy. The contents table is
impossibly slow to process via SELECT.

The occupancy table is much faster, though still not fast. There is an
anomoly I noticed with occupancy data. SELECT * FROM OCCUPANCY is MUCH
faster than QUERY OCC. So much faster that I made a script with it.
Probably the reason is that QUERY OCC joins in platform information
instead of just formatting the table.

If you are looking for active nodes in a system, however, you need
date-last-backedup data, which neither occupancy nor contents has. Basic
data is in the nodes table. That doesn't take into consideration failed
backups, or even bad passwords. What I use is the filespaces table, and
look for backup end dates. Our evolving (and constantly argued over)
rule for defining an inactive node is one which has not completed a
successful backup of any filespace for 4 months, which approximates 1
semester. I'm sure somebody more clever than me, could aggregate
FILESPACES into a list of active nodes based on a specific cutoff date
with SQL, but I use an easy SPSS program that prints nice-looking
reports. SPSS digests anything written by dsmadmc -comma very nicely.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu


On Mar 15, 2008, at 2:36 PM, Roger Deschner wrote:

>That occupancy table can be REALLY slow to process if your system is at
>all large. I prefer to search the summary table which is fast, even with
>my 275gb database.

Roger - Are you thinking of the Contents table?

I have a large system, and it takes about 3 seconds to get results
from that Select of the Occupancy table.  It takes about 20 times
longer to go through the Summary table, where the retention is 30 days.

   Richard Sims