Zoltan,
Here is some sql which should tell you which is the large file/s
Change the backup_date to the period you are interested in,
This will not give you sizes but the large file/s will have the largest time gap
before
the next entry.
SELECT HL_NAME,LL_NAME,BACKUP_DATE FROM BACKUPS -
WHERE NODE_NAME='your node name ' -
AND FILESPACE_NAME='your filespace name' -
AND BACKUP_DATE BETWEEN '2002-01-04 22:39' AND '2002-01-05 04:26'
"Zoltan Forray/AC/VCU" <[EMAIL PROTECTED]> on 01/15/2002 01:48:51 PM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: John Naylor/HAV/SSE)
Subject: Re: Handling spikes in storage transfer
Did that. TERSE is on and the log contains only the summary of what is
going on. No file info.
Don't have access to this system. It is an SGI IRIX box and the owners are
very particular about who accesses it.
"Mr. Lindsay Morris" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
01/14/2002 03:04 PM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Handling spikes in storage transfer
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
>
**********************************************************************
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy plc.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission.
Scottish Hydro-Electric, Southern Electric, SWALEC and S+S
are trading names of the Scottish and Southern Energy Group.
**********************************************************************
