Oracle db's are highly compressable.  We run our Oracle backups
through the unix compress utility.  I've seen tablespace files on a
newly created instance (no data loaded yet) compress from 1gb down
to 10mb.  A normal tablespace file full of data will tipically
compress about 3-to-1.

In general, data can only be compressed once.  If you compress via
sftw, like the unix compress utility or TSM's client then the drive
hdwr compressions won't add anything.  In this case you would
basically get the native capacity of the tape drive onto a tape.  We
use 3590E drives with tapes that have 40gb native capacity.  Our
tapes that hold oracle backups generally end up with right around
40gb.  Client side compression accomplishes the same thing.

When hdwr compression is turned on, the tape drive tries to compress
the datastream it receives from the tsm server.  When not using
client compression and not backing up already compressed files, the
tape drive will attempt to compress the datastream.  On the tapes
with this kind of backups we get anywhere from 50gb up to 120gb.
120gb on a 40gb tape is a 3:1 compression ratio.  An ORacle db will
compress around 3 to 1.

Client side compression takes cpu cycles and in general will result
in a much slower backup but uses much less network bandwidth.  Hdwr
compression in the tape drive is very fast, much faster than client
side compression (usually).

The big argument is usually whether you should run your tape drive in
compressed mode even if you send already compressed data to it
(client side compression or just backing up .Z or .zip files).  If
you compress a datastream that is already compressed, the datastream
will actually get bigger.  Go ahead, run a unix compress on an
existing .Z file.  My answer is to always leave it ON.  Modern
compression chips used in tape drives can detect when data received
by the drive is uncompressable, and will stop compressing the data.
AIT drives are like this.  I've got to believe that IBM 3590 drives
are at least that smart!!!  For that matter, the TSM client can also
do this!!! That's the purpose of the "compressalways" command for the
client side dsm.opt file.  When running "compression yes" and
"compressalways no", the client will attempt to compress files.  If
the client detects that a file is uncompressable,  the client stops
compression and just send the file.

The one place I've found client side compression very usefull is when
backing up remote systems on a wan.  If I run the backup without
client compression I destroy response time for all wan users.  By
using client side compression I throttle the backup.  The client
systems can't compress/send the data fast enough to dominate the wan
link. Oh for a client side bandwidth parm like Veritas has . . . . .

Rick



On 8 Mar 2001, at 11:29, Roy Lake wrote:
> Hi Chaps,
>
> Just wanted to share my findings with you with regards to TSM compression/no 
> compression.
>
> We have 3575-L18 tape library. We use 3570-C Format tapes. We used to have 
> CLIENT compression set to YES when doing backups, with DRIVE compression OFF. 
> Most of the data on our systems is Oracle.  When we had client compression 
> set to YES, each cartridge would take about 5GB.
>
> I have done some testing and found that when I switched compression OFF, we 
> managed to get around 21GB on each cart, and also the backups were a LOT 
> quicker.
>
> IBM recommend (and I quote:) "Oracle databases are normally full of white 
> space, so compression is required. Either h/w or client compression."
>
> Could someone please explain WHY compression is required if we get more on 
> tape with it switched OFF, and the backups are quicker?.
>
> In our environment, TSM has its own 10Meg a sec network, and 99.9% of the 
> backups are done overnight, so there is no problem with performance issues.
>
> Am I missing something here, or is it REALLY a better idea to forget about 
> compression totally?.
>
>