Well, we love to support the TSM community, and are happy to share some of
the utility scripts --
but these three depend on having our database filled with info.
You can use the demo free for 30 days though, and that may be enough to
solve your problems, at least in the short term.
Call me for more info, or see our banner ad at www.adsm.org - this is not
supposed to be a marketing list.
Thanks, Jane.
----------------------------
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
> Jane Bamberger
> Sent: Wednesday, January 23, 2002 3:51 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TSM and capacity planning
>
>
> Hi Lindsay,
>
> Any chance you would share makegraph, mknode, and a sample of the
> conf file?
> This looks like something our hospital could use!
>
> Jane
>
> %%%%%%%%%%%%%%%%%%%%%%
> Jane Bamberger
> Bassett Healthcare
> TSM 4.2.1.9
> AIX 4.3.3
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Mr. Lindsay Morris
> Sent: Wednesday, January 23, 2002 2:32 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TSM and capacity planning
>
>
> 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
> 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
> >
>
|
