Level 0 Restore
Posted in 2007
Topics: General Discussion
I remember that to do a level 0 restore on a different machine it has to be running the same OS and have the same disk slices (or preferably symbolic links to the physical slices) available to IDS, and the slices have to be at least as large as on the source box. I have a feeling it has to be the same version of IDS e.g. V10 can't restore a V7 archive. Would it be possible for someone to confirm this, please? TIA
Cats wrote: > I remember that to do a level 0 restore on a different machine it has > to be running the same OS and have the same disk slices (or preferably > symbolic links to the physical slices) available to IDS, and the > slices have to be at least as large as on the source box. > > I have a feeling it has to be the same version of IDS e.g. V10 can't > restore a V7 archive. Would it be possible for someone to confirm > this, please? > > TIA > Yes. Same OS, same IDS version (a different release level can work...), same storage (v10 allows for chunk pathname rename). If you need to upgrade in a similar OS, resotre with the same version and make the IDS upgrade later. If you're changing architecture/OS than you have to consider other migration paths. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...
On Jul 5, 12:22 pm, Fernando Nunes <s...@domus.online.pt> wrote: > Cats wrote: > > I remember that to do a level 0 restore on a different machine it has > > to be running the same OS and have the same disk slices (or preferably > > symbolic links to the physical slices) available to IDS, and the > > slices have to be at least as large as on the source box. > > > I have a feeling it has to be the same version of IDS e.g. V10 can't > > restore a V7 archive. Would it be possible for someone to confirm > > this, please? > > > TIA > > Yes. Same OS, same IDS version (a different release level can work...), same > storage (v10 allows for chunk pathname rename). > > If you need to upgrade in a similar OS, resotre with the same version and make > the IDS upgrade later. If you're changing architecture/OS than you have to > consider other migration paths. Thanks, was thinking about upgrading the test machine so I could get rid of the 2GB limit and import a database much more easily (yes know I've swapped between level 0 and import there) but upgrading it to v10 would block bringing the level 0 archive over from the live so we'll live with it for the time being. Several of the tables are too large to fit in 2GB which of course complicates an import. We'll wait until the current burst of application upgrade activity is over and then deal with getting the database up-to-date. Thanks again.
On Jul 5, 8:32 am, Cats <ramwa...@uk2.net> wrote:
> On Jul 5, 12:22 pm, Fernando Nunes <s...@domus.online.pt> wrote:
>
>
>
> > Cats wrote:
> > > I remember that to do a level 0 restore on a different machine it has
> > > to be running the same OS and have the same disk slices (or preferably
> > > symbolic links to the physical slices) available to IDS, and the
> > > slices have to be at least as large as on the source box.
>
> > > I have a feeling it has to be the same version of IDS e.g. V10 can't
> > > restore a V7 archive. Would it be possible for someone to confirm
> > > this, please?
>
> > > TIA
>
> > Yes. Same OS, same IDS version (a different release level can work...), same
> > storage (v10 allows for chunk pathname rename).
>
> > If you need to upgrade in a similar OS, resotre with the same version and make
> > the IDS upgrade later. If you're changing architecture/OS than you have to
> > consider other migration paths.
>
> Thanks, was thinking about upgrading the test machine so I could get
> rid of the 2GB limit and import a database much more easily (yes know
> I've swapped between level 0 and import there) but upgrading it to v10
> would block bringing the level 0 archive over from the live so we'll
> live with it for the time being. Several of the tables are too large
> to fit in 2GB which of course complicates an import.
>
> We'll wait until the current burst of application upgrade activity is
> over and then deal with getting the database up-to-date.
>
> Thanks again.
Download my dbexport/dbimport replacement utility, myexport from the
IIUG Software Repository. It permits dbimport compatible exports of
tables larger than 2GB.
You'll also have to download the following support packages which
myexport uses:
utils2_ak - for my dbschema replacement utility myschema as dbschema
output is not dbimport compatible
sqlcmd - for the sqlunload and sqlreload utilities.
myonpload - if you want to use the myexport/myimport option to use
onpload for exporting/importing the data (haven't tested tables
larger than 2GB using onpload though - it definitely works using the
default sqlunload utility).
Art S. Kagel
Cats wrote: > Thanks, was thinking about upgrading the test machine so I could get > rid of the 2GB limit and import a database much more easily (yes know > I've swapped between level 0 and import there) but upgrading it to v10 > would block bringing the level 0 archive over from the live so we'll > live with it for the time being. Several of the tables are too large > to fit in 2GB which of course complicates an import. > Having a different version in development and production is never a good idea. I'm a bit confused by your problem. A table can have a lot more than 2GB. A table can spawn several chunks. And you can also fragment it through several dbspaces. I also don't understand why this is a problem in development and not in production... Do you have larger tables in development than in production? Usually it's the other way around... > We'll wait until the current burst of application upgrade activity is > over and then deal with getting the database up-to-date. If you do level 0 restores from production into the development environment you can (and in fact should do for testing purposes), migrate the development instance to v10. If all goes well it will take you less than five minutes (assuming you jump a few steps used for consistency checking). Than you should test your applications to be sure nothing weird happens when run against v10. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...