Fw: Questions about ontape

["Vasyl Shulzhenko" <vasilis@softline.kiev.ua>]

----- Original Message -----
From: Art S. Kagel <kagel@bloomberg.net>
Newsgroups: comp.databases.informix
To: <CKGeier@nwc.edu>
Sent: 1 ХЧМЪ 2000 Ц. 17:28
Subject: Re: Questions about ontape


> CKGeier@nwc.edu wrote:
> >
> > What kind of backup is ontape? How does it work? Is it a "dd" or
something
> Something else, read below.
>
> > else? I have read we can work through the backup with no ill-effects,
but
> Correct.
>
> > will processing be slowed? Are tables or other structures locked, other
> Nothing is locked except BLOB pages temporarily (see the Backup and
Restore
> Guide for details).
>
> > than blobs fields, when the archive is running? We want to run a mergeid
> > process at night, when these ontape archives are being created.
> No problem.
>
> > TIA and thanks for answering my earlier questions today!
>
> Ontape is Informix's original claim to fame.  When Informix first
developed
> its enterprise quality engine (it already had the Standard Engine) it was
> named Informix Online because you could safely archive it using ontape
> without having to kick users off and shutdown the engine as you had to at
> the time for virtually ALL other database servers and there was minimal
> impact on production.  Truth is until IDS7.2x the impact was noticeable
> but the process has been constantly improved over the years.  In IDS7.3x
> and IDS9.2x there is no noticeable impact on current performance during an
> archive.  I have servers with over 400GB of disk chunks that take over 36
hours
> to archive to a 5 DLT7000 drive RAID tape array so I run archives
> during production almost every day (we alternate archiving each of two
> sister machines so I have a window for maintenance like adding chunks on
> the off days).
>
> Ontape accomplishes this feat by archiving directly from disk to tape
> through a private set of buffers that does not affect the system buffer
> cache.  Informix maintains data integrity through concurrent updates by
> having the engine copy the preimage of any page modified after the start
of
> the archive to a set of temp tables, one per dbspace.  Once each dbspace
> has been copied to the archive device/file that dbspace's temp table is
> dumped to the archive device as well and (in 7.30 or later) dropped.  Thus
> during a restore any page modified during the archive which may or may not
> have had its altered version flushed to disk before the archive got to it
> will be overwritten with the preimage copy and thus restored to its
original
> condition as-of the start of the archive.
>
> Art S. Kagel