Re: Database Backup Schedules
Posted in 1995
> Clem Akins writes:
> > Now that we have a clue, here's the real deal...
> > We got a big digital linear tape (DLT) drive that holds 20GB, and we
> > do a level 0 every day. There are several things to beware of, though:
> > Informix won't support
> > tape-drive level compression
>
> Joe Matuscak <matuscak@rohrer.com> writes:
> Could you explain this a bit? Im under the impression that (in the case
> of a TZ87 on Ultrix) that if you write stuff to /dev/rmt0h (for example)
> the driver kicks in the compression automatically, the application isnt
> really aware of whats going out to the tape.
> [...sig deleted...]
>
> John Vemo writes:
> This is something that I have never been able to understand. If your tape
> drive supports H/W compression, through a seperate device access (i.e. tx0
> vs. tx0c), then why in the hell should Informix care?? This is completely
> outside of Informix, all ontape or OnArchive does is pump data to a device.
> If this device can, without addition calls, compress/uncompress the data as
> it writes and reads from the tape, who cares??
>
> OnArchive now supports compression, though its S/W compression being done by
> OnArchive. This is going to slow down your archive times, since additional
> cycles are now required to perform the compression. On the otherhand, drive
> compression, is done at the tape drive device, and actually speeds up
> archive times.
>
> So, go figure........
Both of you are correct. I, too, wonder what business is it of Informix's
what my device does as long as it will return a valid bit stream? My
archive strategy is predicated on my ability to manipulate my archives,
as I write to disk, compress it, then ftp it to a VMS platform!
BUT
Informix still doesn't support it. If I call tech support and ask them for
help with my archives they ask FIRST THING if I am using hardware
compression, and if I answer "yes" then the show's over. We have talked
to them a couple of times, and the problem has never been my manipulation
of the archive (ftp, compress, and gzip have always put things back exactly
the way they were) but I had to lie to them about what I was doing to get
them to go on to the second question. (Tech support, BTW, has been mostly
helpful and able to fix my problems. I've been reasonably happy, except for
this major 129-row update limitation on the Alpha platform.) Your complaints
and arguments are all valid, and you may direct them to Informix. I don't
have any better answer, just the experience trying to get one from Informix.
The purpose of my post was to share that experience with the group, so
that you could save yourself some hassle with the tech support people.
> > more than 1 archive per tape
> > (of course that doesn't mean you can't do it...)
> > There are bugs on the DEC Alpha & 7.1 when restoring from >1 tape
>
> Clem, could you shine a little light on your restore problem? Are you using
> ontape or OnArchive??
Actually, we have no restore problem. Another user posted a problem with
restoring from multiple tapes on the DEC Alpha, and I can't find his post.
My sysadmin dude has some bizarre way to trigger the archive, and I think
it uses ontape. I need to check with him and figure it out for myself.
He talked with tech support the other day trying to figure out why we
couldn't restore, and they told him that he had to be using a rewind
tape device. (He had been using a norewind device, and putting more than
one archive per tape.) Informix doesn't support that, either. Only one
archive per tape. So now he uses a rewind device, and has a separate
script which manipulates the tape to the desired position each time. :(
It works, though, and he has tested it well. OnArchive and ontape check
a little more closely than the older 5.x archive tools, and will be
harder to fool. Complaints about this should (again) be directed to
/dev/null@informix.com, or whoever it is there that logs these tirades.
> [...sig, other topics deleted...]
Your partner in archival crime,
__________________________________________________________________
| Clem Akins Standard Disclaimers Apply |
|Reynolds Metals Co, Alloys Plant "Climb High, Cave Deep!" |
| Muscle Shoals, Alabama USA cwakins@leia.alloys.rmc.com |
|________________________________________________________________|