Re: backup takes too long
Tim Schaefer wrote:
>
> Neil Truby wrote:
> >
> > >> I'm periodically hearing about how bad OnArchive is, but nobody has any definite reasons why.
> >
> > Because it's crap! :-)
> >
> > Specifically, it's rather flaky. I've never had any problems restoring
> > with it, and do it every day to a contingency environment, but the two
> > major problems I have are:
> >
> > (1) The catalog frequently gets out of step with what's actually on
> > disk. This happens particularly when you've done a restore - the
> > archive you've restored from is not registered in the catalog of the
> > restored database! Ergo, when next you archive, an inconsistency is
> > reported.
> >
>
> Hmmm, so it's ok for doing the backup, but the restore is questionable.
> This would be the major point of the backup, to restore as needed,
> obviously.
>
> It appears that it would be safer to just backup each table
> individually,
> via unloads, do a nightly dbschema, storing the schema and all the data
> on
> tape, or other media. The advantage I guess is that the backup can
> occur as
> soon as the largest table is unloaded, which wouldn't prevent anyone
> from using
> the data base. The recovery would be as good as the latest backup. Is
> there
> something I'm missing here? I realize in OLTP systems you might have to
> re-enter
> transactions, but here again, the restore would be a simple reload of
> the data,
> and then the users re-enter from the point in time of the last backup.
> And it
> could be a phased restore, or parallel, with onpload, unless of course
> you used
> rowids.
>
> > (2) The continuous log back-up option is prone to crash when a logical
> > log fills during an archive.
> >
> > The first problem is specific to disk dumping. I would suggest that this
> > product has been "designed" for those of us who dump, and have always
> > dumped, to disk. One of my surprises when joining the Informix
> > community is the obsession that people seem to have with dumping to
> > tape. This seems to be an out-of-date concept to me, unless of cousrse
> > your databases are huge.
> >
>
> Well, more and more we're seeing larger and larger data bases, in the
> gigabytes
> of data, rather than just megabytes. So I would suspect disk dumping
> will
> either become more of a refined science, or faster tape drives. I
> noticed the
> OnArchive program handles archiving to disk, which is something I
> recommended,
> and then the O/S would pick up the archive on it's regular UNIX backup.
> (HP/UX)
>
> For extremely large databases, of course the big problem is in the
> window of
> available time to do the backup. Do you create a series of unloads, to
> ascii,
> i.e. "onpload ... | gzip > file" ? or OnBar? It certainly gets more
> complex
> as the data base grows.
>
> > Neil Truby
> > Chase Manhattan
> > Bournemouth, UK
>
> Thanks for the info, I'll refrain from using OnArchive, but please tell
> me about
> something else that is a better way.
>
> :-)
>
> Tim
> --
> Tim Schaefer \\\\|//
> tschaefe@mindspring.com (6 6)
> ------------------------oOOo---( )---o00o---------
> http://www.mindspring.com/~tschaefe
> http://www.inxutil.com
> MAKE TIDAL WAVES DIVE IN THE OCEAN IS BIG
As an ex-Informix engineer, I will throw my two cents worth in.
The version 5.x program tbtape was recognized by Informix not to be
robust enough to handle the requirements of DSA such as fragmentization,
parallel archives, etc. They contracted a third party to create a new
archive product and that became OnArchive. Informix recognized early on
that Onarchive was not a very good product but at least it would give
users the ability to do archives of a subset of the instance and not the
whole thing. This let parallel archives happen. Informix now has a new
product that combines the best of both OnArchive and Ontape called
OnBar. However, it requires that users purchase a third party storage
management product such as Legato Networker, IBM ADSM, or HP OmniBack.
This just moves the old OnArchive complexity to the new product. I have
used all of the products and can say that OnBar is faster than OnArchive
which is faster than Ontape. OnArchive is okay once you learn all of its
idiosyncracies just like any other product. I always told my clients
that unless they could justify the use of OnArchive for parallel
backups, point-in-time recoveries, or such, that they should stick with
Ontape. (There is no way you can back up a 200 gig database in 3 hours
with Ontape but I can do it with OnArchive). Doing an archive to disk is
a great idea as long as you have enough disk to support it. I had a
client who would archive to disk and then use UNIX compression against
the resulting file. This worked fine but he had to de-compress his files
before he could restore.
Lastly, if you use something like unloads to do the archiving, the
engine will never recognize the fact that it has had an 'archive'.
During an archive the engines cleans up things like logs and records the
archive in the reserved pages to make restores easier. This then will
let you know exactly which log files are needed for a roll forward.
Doug McAllister
ex-Informix engineer