All this is why (if you do charge back) you simply charge the client by what
the "auditocc" shows...
Then if "THEY" take their processor time to compress their data they get a
little bit of a charge break
but if "THEY" don't take the time to compress their data, they end up paying
more !
Or should I word that as You end up making a bigger profit ;-)
Sure charge them for 20 or 40 GB of stored data, then compress it down to
just 10 GB (or 1 3590 tape)
What I've seen over time is that clients will use the money saved by using
compression to buy more CPU's for their processors thus making backups run
faster at night (by performing compression quicker) AND makes for a better
running system during the day when they have their clients on their box !
but yet again, it all boils down to
It depends ;-)
Dwight
-----Original Message-----
From: Prather, Wanda [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 08, 2001 2:13 PM
To: [EMAIL PROTECTED]
Subject: Re: Compression / No Compression ???
I agree with Richard and Dwight. It depends. We have client compression
on, I did a bit of testing, and sending client-compressed data on through
the tape drive compression generally doesn't hurt us, but doesn't help much,
either. In some simple tests I ran, we got at most an additional 10%
compression on 3490 tape drives.
The problem with TSM and figuring out what compression is doing, is that TSM
only tells you what the CLIENT reports sending to it. It doesn't KNOW what
the hardware compression is doing. You can't necessarily rely on the
CAPACITY figures it reports for each volume.
Assume, for the sake of simplicity, that the compression ratio is 2:1 for
either client software compression, or your tape hardware compression. And
assume your "native", or raw physical tape cartridge capacity is 20 GB.
- On a client that has 40 GB of data to send, if compression is ON at the
client, it will compress the data down to 20 GB, report 20 GB sent to the
server, and the server will report to YOU that it sent 20 GB to the tape,
and you will have 1 full tape. That tape volume will show "est capacity" at
20 GB.
- On a client that has 40 GB of data to send, if compression is OFF at the
client, it will report 40 GB sent to the server, and the server will tell
you that it sent 40 GB to the tape, and you will still have exactly 1 full
tape, since the hardware will compress the 40 GB down to 20 GB. That tape
volume will show "est capacity" at 40 GB.
If you have a mixture of clients compressing/ not compressing, you can't
look at the "capacity" figures for your tape volumes and tell a darn thing.
All you can do is make some controlled tests where you work with a specific
client to send a specific set of data, and see how much data you can send to
a tape before it fills up. Then you can assume you will get the same
compression ratios on clients with similar data.
-----Original Message-----
From: Richard L. Rhodes [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 08, 2001 9:24 AM
To: [EMAIL PROTECTED]
Subject: Re: Compression / No Compression ???
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?.
>
>
