It does not matter at all are you using compression or not. The problem is
how much the file is changing and what serialization is set in the copy
group.
If it is SHRSTatic or SHRDYnamic and the file is changing during all
attempts "the sucker" :-) will try up to changingretries (from dsm.opt)
times. After that it will either give up or perform some kind of backup. If
you set serialization of STatic or DYnamic no retries will take place - try
once and see what will happen.
I've made a test recently and for ~250MB file which was constantly modified
during backup (with default SHRSTatic setting) I got 4 retries and after
over 1GB was sent to server the scheduler gave up.

Zlatko Krastev
IT Consultant





Mark Stapleton <stapleto AT BERBEE DOT COM> on 10.10.2001 23:35:17
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: Does compression cause retries?

On Tue, 2 Oct 2001 08:20:24 -0600, it was written:

>Oh vastly experienced TSM wise ones!

Oh, please! You'll turn our pretty heads...

>We have a box with some large files, and a slow network, so I turned on
>compression to see if it would speed the backup, but I think it may have
>backfired. It looks to me like I just caused resends.
>
>From the client schedule.log:
>10/02/2001 04:45:27 Normal File-->     109,740,032
>/fnsw/local/oracle/oraIDB sig  Compressed Data Grew
>10/02/2001 04:45:47 Retry # 1  Normal File-->     109,740,032
>/fnsw/local/oracle/oraIDB sig  Sent

Yes, you did.

TSM scans files and estimates the compression ratio prior to
compression and transmission of the compressed file. If the file is
open or changes between the time the estimate was done and the time
the compressed file is ready for transmission, you'll get the above
message.

The answer? Use a TDP agent (it looks like you're working with Oracle
files) designed to backup open files, if possible. Otherwise
compression is just going to stretch out the amount of time needed to
do the backup. (You're lucky the sucker didn't retry 4 times!)

--
Mark Stapleton (stapleton AT berbee DOT com)
Mark Stapleton (stapleton AT berbee DOT com)