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 [EMAIL PROTECTED] 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
