Re: Fw: Domino 8 compression -- MIDRANGE-L

My bet is that the 5 minutes you gained was because of the deletion of those log files. When sending information to a tape, think about it as one
really long serial stream of data. Whether it's compressed in the front or back makes no difference to the tape. If you have compression enabled on
the tape, you can't gain more space by compressing again, unless you use a more efficient form of compression. Anyways, you said that the total size
did not appreciably change due to removing those log files. So in essence you're still backing up the same amount of physical data, it just takes up
less room on the file system now. Now you're compressing that data on the front end in the file system instead of just compressing on the back end on
the tape. Also, you mentioned removing 3 x 70GB disks of data, did you mean that you physically removed those DASD's or you removed that much "data"
by compression? If you physically removed the disks and your backup time was nearly the same, all that tells me is that you had enough disk arms to
support the data throughput required to feed an LTO3 tape drive with enough data to keep it from shoe shining (backup and start again). Shoe shining
is a very bad thing to be doing in backups because it can significantly increase your backup times, like double if you can't feed the drives fast
enough. It doesn't sound like you're having that issue. I can agree and disagree with what Rob said below by not re-compressing the backup
information to tape. On one hand it makes sense, but on that other hand it doesn't. I think you'll have to test it both ways over a couple of days
to see how it actually performs. I would believe you'd still need compression enabled on the tape because in essence they are two different file
system formats, and compression will still be needed to keep the number of tapes reduced. Decompressing the data and then writing it to tape could
free up CPU and memory use, but it would increase the amount of physical storage consumed on the tapes. That's my belief based on what I know
generically of tapes.

Good luck,
Bill Epperson Jr.
Systems Communications Analyst
Memorial Health System
(719) 365-8831

rob@xxxxxxxxx

Sent by: midrange-l-bounces@xxxxxxxxxxxx To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc
06/30/2009 09:03
Subject
Re: Fw: Domino 8 compression
Please respond to
Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>

Good point. I may try changing the backup from the defaults of
DTACPR(*DEV) COMPACT(*DEV)
to
DTACPR(*NO) COMPACT(*NO)

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From:
Charles Wilt <charles.wilt@xxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
06/30/2009 10:53 AM
Subject:
Re: Fw: Domino 8 compression
Sent by:
midrange-l-bounces@xxxxxxxxxxxx

Rob,

Since the bulk of the data is already compressed, you might want to
make sure that the save isn't trying to compress it again; as that
would waste time.

Charles

On Tue, Jun 30, 2009 at 10:37 AM, <rob@xxxxxxxxx> wrote:

Let's see if I get an answer on the midrange l list...

I have several domino servers on this one lpar. One of the Domino

servers

is saved with it's own save. (It's quite significant.)

I did two changes:
1 - Used some nice Domino 8.0 (not the 8.5 DAOS stuff yet) compression
that freed up 200GB or just under three 70gb disk drives.
2 - Deleted 850 Domino archive log files and turned off archive logging.
These 850 files really didn't take up an appreciable amount of space.

The length of the save duration didn't really change that much.

Summary,

only chopped off 5 minutes by using three less of our 70GB disk drives.
What's the deal, it's the number of the files and not the size? So did

save the 5 minutes by removing the 800+ insignificant l_ archive log
files and not by the compression of the large files which freed up over
200GB?

Before compression:
05/11/09 17:32:13 start
05/11/09 19:01:48 2017181 blocks processed for sequence 1, volume

AMON15

05/11/09 20:33:31 2042477 blocks processed for sequence 1, volume

AMON25

05/11/09 21:00:36 576892 blocks processed for sequence 1, volume AMON35
05/11/09 21:00:40 4308 objects saved.

After compression:
05/18/09 17:32:12 start
05/18/09 19:01:48 1742161 blocks processed for sequence 1, volume

AMON11

05/18/09 20:33:45 1747936 blocks processed for sequence 1, volume

AMON21

05/18/09 20:55:23 387384 blocks processed for sequence 1, volume AMON31
05/18/09 20:55:26 3555 objects were saved on volumes AMON11 AMON21

AMON31

I figure the number of blocks stored on each tape decreased because the
data is now compressed and tape compression could not compress it down
much further.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.