Re: ontape/ondatartr restores -Reply
Sky Southwell wrote:
>
> >>> <ntruby@netcomuk.co.uk> 11/01/96 11:49am wrote:>>>
> >It's well known that OnLine demands that a restore requires the original chunks to be
> >available, or at least the same symbolic links.
> >
> >But why is this? I can't understand why, since the physical location of pages is
> >unimportant. The important thing is the relative address of each page wrt the start of
> >its dbspace.
> >
> >Other DBMSs, e.g. Adabas, work entirely on relative address blocks
> >(pages). This makes transfer of data between servers, or between prod and dev on the same
> >server, much easier.
> >
> >Neil Truby
> >Chase Manhattan Bank
> >Bournemouth, UK
>
> =========
>
> But 'restore' and 'transfer' are two different concepts, and INFORMIX has different
> utilities for each. To do a table or database transfer, that is relatively FAST, try the
> onunload/onload combination (See Chapters 34 and 40 on the 7.1 Admin Guide for details).
> These utilities move the data in binary, page-sized units, and do not care about physical
> location.
>
> The OnTape/OnArchive utilities are meant to put your system back the way it was before
> 'something amiss' occurred, or to get you started on data replication.
>
> --
> Sky
> +-------(southwel@smtpgw.maricopa.gov)-------+- Maricopa County -+
> | Schuyler L. Southwell | Attorney's Office |
> | Data Management Consultant | 301 W. Jefferson |
> | Voice: 602-506-8107 **** FAX: 602-506-3970 | Phoenix, AZ 85003 |
> +--------------------------------------------+-------------------+
Thanks for your interest. I obviously didn't put over very well the
point I was trying to make. I realise that I can use onunload/dbexport
to move between different configurations. My question is not "Can I use
ontape/onarchive?", but "Why can't I?". As I see it, once you define
the physical location of rootdbs (in the config file), then the physical
locations of all other dbspaces in this instance can be read from the
system tables therein. Thus, provided dbspaces identical in number and
size to those of the source of the archive, their physical location
should be irrelevant. Clearly it isn't, but I believe this is just a
design "feature" introduced by the developers, and that there is no good
reason for it.
Neil