Reply,

Debbie,

One thing that I noticed about your comments below....... you indicated

"Hardware compression was always there during my tests."

Maybe I was misunderstand what you mean by the statement...... but just in
case I didn't........

If you had HW and SW compression "on" at the same time for some of your
tests.... you have may inadvertantly skewed your results. It is NEVER good
to use both HW and SW compression simultaneously. If you are compressing
compressed files.......
(excluing files that are compressed as a result of the filesystem type ..
like in AIX.. or the type of drive... like with NT)

1) They usually grow in size (at least slightly)
2) Sometimes, through the 2 compression algorithms..... you corrupt the data.

FYI -

Jennifer


At 09:45 AM 7/10/98 -0400, you wrote:
>I was trying to be brief in my response, so I didn't give all the
>details.  The average compression ratio, client side, was about 45%.
>This means that we were about breaking even on that point.  The weighing
>factor was the relatively few files that "grew" during compression, and
>the time required for backup and restore.  I decided that it was easiest
>to turn off client (software) compression, and let the data fall where
>it may.  Hardware compression was always there during my tests.
>
>As for how I came up with the average,  I used a query occupancy command
>for each node (we only have about 25) to find out how much space each
>was occupying in the tapepool.  I added the numbers up, divided by the
>number of tapes in the pool, and then adjusted them acording to the
>average percent reclaimable in the tapepool.  And, like I said earlier,
>with compression on (software, client side) we were average around 6.5
>Gb per tape in the pool.  With compression off that number jumped up to
>around 10 Gb per tape.  As you can see, with an average compression
>ratio of  45% we are getting approximately the same amount of  "raw"
>data on each tape, but backups and restores run slightly faster (I am
>not just guessing at this, I actually tested it).
>
>As for how many bytes are actually on the tape, I don't trust any of the
>query commands to really tell me that with absolute accuracy.  When you
>can display a tape that is 54% used, and 54% reclaimable, you know
>something doesn't add up.  I was just carefull to use the same set of
>numbers during each trial to give a good comparison.
>
>So now you've heard the long version of the story.  As you might be able
>to tell, we were quite concerned with the number of tapes that we were
>consuming.  Our original estimates were way off, and completely blew our
>relatively small budget last year.  So a considerable amount of my time
>was spent trying to figure out why we were using so many tapes.  Our
>biggest error was in estimating the copy pool, not considering that it
>was a copy of the ENTIRE tape pool, not just the latest backups (full
>backup mindset).  We also misjudged the effect of the retention factor.
>
>> -----Original Message-----
>> From: Jerry Lawson [SMTP:jlawson AT THEHARTFORD DOT COM]
>> Sent: Thursday, July 09, 1998 3:26 PM
>> To:   ADSM-L AT VM.MARIST DOT EDU
>> Subject:      Re: 3575-L24 Tape Library
>>
>> ---------------------------- Forwarded with Changes
>> ---------------------------
>> From: owner-adsm-l AT VM.MARIST DOT EDU at SMTP
>> Date: 7/9/98 10:50AM
>> To: Jerry Lawson at ASUPO
>> *To: ADSM-L AT vm.marist DOT edu at SMTP
>> Subject: Re: 3575-L24 Tape Library
>> ----------------------------------------------------------------------
>> ---------
>> How are you measuring the amount of data that actually goes on the
>> tape?  If
>> you are using the ADSM Q VOL reports you may be deluding yourself.
>> That
>> report gives the amount of data it wrote to the physical tape -
>> measured in
>> the number of bytes it wrote - not the actual size of the files that
>> get
>> written.  This means that if you are doing client compression, the
>> number
>> being reported is compressed data.  If you are doing hardware
>> compression,
>> the number being reported is raw uncompressed data.  The long and the
>> short
>> of it is that you really need to know the compression amount on the
>> clients
>> before you can adequately measure what the impact of the various
>> compression
>> methods is.  And that's a fun thing to do - determining the
>> compression ratio
>> of files backed up on a hundred different machines on many different
>> days!
>>
>> Jerry Lawson
>> jlawson AT thehartford DOT com
>>
>>
>> ______________________________ Forward Header
>> __________________________________
>> Subject: Re: 3575-L24 Tape Library
>> Author:  owner-adsm-l AT VM.MARIST DOT EDU at SMTP
>> Date:    7/9/98 10:50 AM
>>
>>
>> We are AVERAGING about 10 Gb/3570 tape now that we have turned off
>> client compression (I am unsure of the model & of our 3575 Library).
>> When we had compression on we averaged about 6.5 Gb/tape.
>>
>> > -----Original Message-----
>> > From: Rui Malheiro [SMTP:rmalheiro AT MAIL.TELEPAC DOT PT]
>> > Sent: Thursday, July 09, 1998 7:53 AM
>> > To:   ADSM-L AT VM.MARIST DOT EDU
>> > Subject:      Re: 3575-L24 Tape Library
>> >
>> > Replying to: "McNamara, Linda" <LMCNAMA AT CITGO DOT COM> (Wed, 1 Jul 1998
>> > 10:15:17
>> > -0500)
>> >
>> > >Hi!
>> > >
>> > >We are about to purchase a 3575-l24 Tape Library.  For those of you
>> > who
>> > >are currently using this particular library, what is the average
>> > amount
>> > >of data you able to store on a tape?
>> >
>> > For an Oracle database, we're seeing an average of 25GB per tape, no
>> > compression on the client.
>> >
>> > --
>> > Rui Malheiro,
>> > 6 Mil - Tecnologias de Informacao
>> > URL: <http://www.6mil.pt/>
>
>