Get the client's dsmsched.log file (best way); or query the contents table (slow!).
Is there some reason why you can't ftp over the client's dsmsched.log, so you can look at it? ---------------------------- 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:[EMAIL PROTECTED]]On Behalf Of > Zoltan Forray/AC/VCU > Sent: Monday, January 14, 2002 2:56 PM > To: [EMAIL PROTECTED] > Subject: Re: Handling spikes in storage transfer > > > Thanks, but, I am looking for file-level information. > > I have the "bytes transfered per node" info from the SMF ACCOUNTING > records generated by the server. I can tell HOW MANY BYTES WERE TRANSFERED > for this node, back to the day it first started talking to TSM. I need to > know what files and how big. > ------------------------------------------------------------------ > ---------------------------------- > Zoltan Forray > Virginia Commonwealth University - University Computing Center > e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 > > > > > "Denis L'Huillier" <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 01/14/2002 02:33 PM > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject: Re: Handling spikes in storage transfer > > > Try, > select sum(bytes) from summary where entity='SuspectedAbuser' and > activity > ='BACKUP' and start_time between '2002-01-13 00:00' and '2002-01-14 00:00' > > This will give you in bytes the amount of data a particular node sent to > the server in a 24 hour period. > Adjust the start_time and entity as required. > > You can also do a > select entity, sum(bytes) blah blah blah blah group by entity > This will give you the bytes for all nodes. > > Hope this helps. > > Regards, > > Denis L. L'Huiller > 973-360-7739 > [EMAIL PROTECTED] > Enterprise Storage Forms -> > http://admpwb01/misc/misc/storage_forms_main.html > > > > Zoltan > Forray/AC/VCU To: [EMAIL PROTECTED] > <zforray@VCU. cc: > EDU> Subject: Re: Handling spikes > in storage transfer > Sent by: > "ADSM: Dist > Stor Manager" > <[EMAIL PROTECTED] > RIST.EDU> > > > 01/14/2002 > 11:02 AM > Please > respond to > "ADSM: Dist > Stor Manager" > > > > > > > I already tried that. The information it gives isn't detailed enough. It > just tells me about the filespaces. > > I need to know specifics, such as the names/sizes of the files/objects in > the file spaces. > > Anybody have any sql to do such ? > > Thanks, anyway ! > ------------------------------------------------------------------ > ---------------------------------- > > Zoltan Forray > Virginia Commonwealth University - University Computing Center > e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 > > > > > "Cook, Dwight E (SAIC)" <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 01/14/2002 10:29 AM > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject: Re: Handling spikes in storage transfer > > > Do a "q occ <nodename>" and look for what file systems are out on your > diskpool in great quantity. > That is, if you send all data first to a diskpool and then bleed it off to > tape (daily). > That will give you an idea of what file systems are sending the most data, > currently. > Then you may perform something like a "show version <nodename> > <filespacename> to see each specific item. > you might note the "filecount" in the "q occ" listing to see how > much will be displayed in the "show version" command. > > hope this helps... > later, > Dwight > > -----Original Message----- > From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 14, 2002 8:47 AM > To: [EMAIL PROTECTED] > Subject: Handling spikes in storage transfer > > > I have an SGI client node that while normally sends <= 1.5GB of data, is > now sending 36GB+. > > Without accessing the client itself, how can I find out what is causing > this increase in TSM traffic ? > > I have contacted the client owner, but their response is taking too long > and this spike it wreaking havoc on TSM. > > ------------------------------------------------------------------ > ---------- > > ------------------------ > Zoltan Forray > Virginia Commonwealth University - University Computing Center > e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 >
