Try this... but alter the "<1" to fit your need... maybe need <2 etc...
select * from adsm.backups where (node_name='YOUR_NODE' and cast((current_timestamp-backup_date)day as decimal(18,0))<1) -----Original Message----- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 10:02 AM To: [EMAIL PROTECTED] Subject: Re: Handling spikes in storage transfer 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
