ADSM-L

Re: Which is better?

1998-04-29 14:32:10
Subject: Re: Which is better?
From: "Prather, Wanda" <PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU>
Date: Wed, 29 Apr 1998 14:32:10 -0400
As usual, "it depends".

ADSM will get better throughput (MB/sec) sending large objects than it does
sending small ones.
On the small ones, there is more overhead involved in creating and managing
the data base entries for many small files than for 1 large one.  And
obviously you will have more data base I/O on the server.

Whether this is "good" or "bad" for you or not, depends on exactly what you
are trying to do, whether you have sufficient server capacity (processor and
I/O throughput), and whether you have time constraints on getting those many
small files backed up.

For us it is no problem at all.  We have many desktops backing up during
prime shift, but with randomized start times.  We specify COMPRESSION ON at
the client, and most of the work is done at the client end.  The client
collects a "bundle" of 50 files or 50 MB, compresses it, and sends that off
to the server as a transaction.  Then it starts collecting the next bundle,
etc.

As a result we back up all our desktops during prime shift (about 8GB total,
after compression), with no noticeable impact on our network. It would be
much trickier if we were trying to back up just 2 4GB objects in a short
period of time....


===============================================================
Wanda Prather
Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think."
              - Scott Adams/Dilbert
===============================================================





> ----------
> From:         Adrian P Challinor[SMTP:Adrian.Challinor AT osiris.co DOT uk]
> Sent:         Wednesday, April 29, 1998 1:41 PM
> To:   ADSM-L AT vm.marist DOT edu
> Subject:      Re: Which is better?
>
> What do you mean by "prefer"? if you are talking about the time taken to
> get
> the data on to tape, then yes, large objects generally steam better than
> small ones, which is why ADSM supports the concept of storage pools and
> migration pools.
>
> However, this is also a consideration of how you want to restore objects.
> If
> you need to restore only a small amount generally (say a customers
> details)
> then why restore a whole batch of customers? So it really comes down to
> what
> you are trying to achieve.
>
> We have a program (DB*Archiver) which extracts logical objects from
> relational database for long term archival. At present, it does this using
> a
> single large archive file for each run. What we are in the process of
> doing
> is changing this to use a much smaller file for each logical grouping of
> objects (say a group of customers, and all their related data). This is so
> we can make use of high speed tape devices such as the 3590 with its mid
> point load capability.
>
> So, in fact, for applicatio reasons we are going to smaller objects!
>
> _________________________________________________________________________
> Adrian P Challinor                                 Osiris Consultants Ltd
>                                         The Database Archival Specialists
> e-mail: Adrian.Challinor AT osiris.co DOT uk
> www: http://www.osiris.co.uk
>
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf 
> > Of
> > Bill Colwell
> > Sent: 29 April 1998 17:24
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Which is better?
> >
> >
> > I am submitting this for the person named below.  He is having
> > trouble accessing the list.
> >
> >  Hi Group,
> >
> >  We have a dilemma(sp)...
> >  I hear that ADSM prefers fewer larger objects rather than many smaller
> > ones.
> >  If our system design requires that we backup many many small files
> > throughout
> >  the day, what are the issues???
> >  Please advise to group or for faster response email me directly to id
> > below.
> >
> >  Thanks,
> >  Mario Jones
> >  FedEx EDI Network
> >  marioj AT fedex DOT com
> >  901-224-9175
> >
>
<Prev in Thread] Current Thread [Next in Thread>