Justin, take a look at this node-by-node data table:
http://www.servergraph.com/gallery/adsm.Node_Data.Sortable_Node_Data.html

The point is this:
    "query contents" will indeed be a very expensive query to run.
    "query occupancy" can break out TSM storage used by backup, archive, and
HSM storage.
    "query filespace" can show you local storage used (i.e. on the node's
local disks, not TSM storage) by the node.

The two sets of data are synergistic: for example, if node X is using 5 GB
locally (from "q files"), but has somehow managed to amass store 100GB of
TSM storage (from "q occ"), then it has a "hog_factor" of 20 - it's using 20
times more space on TSM than it owns locally!

You should do this calculation on all your nodes, and sort them by
hog_factor.  There always seem to be a couple that are exorbitant.

For such nodes, you'd immediately want to see if they are archiving
everything weekly, or if they have very aggressive backup policies.
Separating backup storage from archive storage (with q occ f=d) shows you
instantly which is which (though the table above, unfortunately, is not
configured to show that).

You may want to take advantage of this when you start writing Perl scripts.

Cheers, and good luck.

----------------------------
Mr. Lindsay Morris
Mr. Lindsay Morris
CEO
Applied System Design
www.servergraph.com
859-253-8000 ofc
425-988-8478 fax



> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Justin Derrick
> Sent: Wednesday, January 23, 2002 1:36 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TSM and capacity planning
>
>
> My approach is very similar, but probably a little more database
> intensive...
>
> dsmadmc -id=<uid> -password=<pass> -outfile=tsmrpt -tabdelimited "select
> filespace_name,sum(file_size) as \"File Size\" from contents group by
> filespace_name"
>
> The resulting file should be able to be parsed easily and imported into
> Excel for down-to-the-byte accuracy on how large each of your filespaces
> are.  I'm going to look at this a little more closely when I get home next
> week, and maybe write a little Perl script to help organize it into
> something meaningful.
>
> -JD.
>
> >Hehe... When using SQL BackTrack, it isn't real comforting to look at all
> >those filespaces (query filespace) with big goose eggs next to them.  One
> >way to do it would be to not view the filespaces to calculate how much is
> >being backed up on a node but to use a select statement:
> >
> >select stgpool_name, sum(physical_mb) from occupancy where node_name
> >='<NODE>' group by stgpool_name
> >
> >Querying the files spaces will give you a capacity based on an
> estimate and
> >it will take a while to compute the percentage
> >utilized anyway.
> >
> >George Lesho
> >Storage/System Admin
> >AFC Enterprises
> >
> >
> >
> >
> >
> >
> >"MacMurray, Andrea (CC-ETS Ent Storage Svcs)"
> ><Andrea.MacMurray AT CONAGRAFOODS DOT COM>@VM.MARIST.EDU> on 01/22/2002 
> >11:40:46
> >AM
> >
> >Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >
> >Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >
> >
> >To:   ADSM-L AT VM.MARIST DOT EDU
> >cc:    (bcc: George Lesho/Partners/AFC)
> >Fax to:
> >Subject:  TSM and capacity planning
> >
> >
> >
> >Hi everybody,
> >I have been tasked with capacity planning for TSM. We are running on AIX
> >4.3.3 TSM version 4.2.1.9. Most of the information is in the log
> with some
> >scripting you can all this ata into a database. The problem I have is SQL
> >backtrack. All those database instances backup to tsm without leaving any
> >stats, I do know where the backtrack logs are, but they are not
> very pretty
> >. So my question is if there is anybody out there who had to do something
> >like that before.
> >Thanks in advance
> >
> >
> >Andrea Mac Murray
> >Sen. Systems Administrator
> >ConAgra Foods, Inc.
> >7300 World Communication Drive
> >Omaha,NE 68122
> >Tel: (402) 577-3603
> >andrea.macmurray AT conagrafoods DOT com
>