, January 14, 2002 11:13 AM
To: [EMAIL PROTECTED]
Subject: Re: Handling spikes in storage transfer
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
Sounds like they have started doing a SEL /* instead of an INCR /* and are
backing up everything. Typical user error.
-Original Message-
From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 14, 2002 9:47 AM
To: [EMAIL PROTECTED]
Subject: Handling spikes in storage
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
PROTECTED]]
Sent: Tuesday, January 15, 2002 8:49 AM
To: [EMAIL PROTECTED]
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
:(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
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
/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
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
If you know what node it is (sounds like you do), you can run q occ
daily, and see what filesystem is increasing the number of files stored and
space occupied. Once you know the filesystem, you can approach the system
owner with a more direct question. Can't help with the non-response part
, 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
enough is the enemy of excellence.
Zoltan Forray/AC/VCU [EMAIL PROTECTED]
Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED]
01/14/2002 09:19
Please respond to ADSM: Dist Stor Manager
To: [EMAIL PROTECTED]
cc:
Subject:Re: Handling spikes in storage transfer
PROTECTED]]
Sent: Monday, January 14, 2002 11:13 AM
To: [EMAIL PROTECTED]
Subject: Re: Handling spikes in storage transfer
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
)
EDU Subject:
Handling spikes in storage transfer
01/14/02
09:47 AM
Please
respond to
ADSM: Dist
Stor Manager
Zoltan
Forray/AC/VCUTo: [EMAIL PROTECTED]
zforray@VCU.cc:
EDU Subject: Re: Handling spikes in storage
transfer
Sent by:
ADSM: Dist
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
]
cc:
Subject:Re: Handling spikes in storage transfer
Do you still have the older sessions in your actlog? Or you could look in
the summary table. Try to see if it's because of a lot more files, or
just
more data. If not many more files, look in the contents table for files
-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
:
Re: Handling spikes in storage transfer
01/14/02
03:03 PM
Please
respond to
ADSM: Dist
Stor Manager
I am pretty sure it isn't a growth in the # of files. While
/vmail
-Original Message-
From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 14, 2002 12:04 PM
To: [EMAIL PROTECTED]
Subject: Re: Handling spikes in storage transfer
I am pretty sure it isn't a growth in the # of files. While the # of files
backed-up did spike
Er, from contents. Oops.
-Original Message-
From: Alex Paschal
Sent: Monday, January 14, 2002 2:01 PM
To: 'ADSM: Dist Stor Manager'
Subject: RE: Handling spikes in storage transfer
Zoltan,
from a *nix box, I suggest
dsmadmc -server=serverstanza -id=id -password=password -comma -out
Subject: Re: Handling spikes in storage
transfer
Sent by:
ADSM: Dist
Stor Manager
[EMAIL PROTECTED]
RIST.EDU
01/14/2002
02:56 PM
21 matches
Mail list logo
