Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Malcolm needed to migrate a whole IDS 9.40 instance between servers (dbexport/dbimport ruled out by vendor support) and hit a string of obstacles doing an imported restore with ISM: 9.3 and 9.4 use different ISM versions sharing the single /nsr link, dbspaces over 2GB, awkward manual instructions (a wrapped nsradmin command, a bogus symlink example involving the /usr/informix mount point). Suggested alternatives were dd'ing the chunks across the network (piped through remsh, works for raw devices too) then doing an in-place upgrade, or a redirected restore via ontape. No confirmation that the migration succeeded is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
For reasons that are still not exactly clear to me I
have been asked to migrate a complete IDS system from
one IDS 9.40 server to another. I think it has
something to do with a SAGE support statement that
they don't support moving databases using
dbexport/dbimport.
Anyway, has anybody else been through the imported
restore using ISM procedure. I feel that every page I
turn is yet another challenge.
Firstly I have discovered that whilst it is possible
to have IDS 9.3 and IDS 9.4 on the same machine, and
it is possible to have both running at the same time,
the two versions use different versions of ISM. And
as the current version is pointed to by a link called
/nsr it is only possible to have one version of ISM
running.
Thta was problem number ~15. I had already
encountered the difficulties of backing up dbspaces of
more than 2Gbytes using ISM, the problem of how to tar
the output of ISM into one file for ease of transfer
across the network, and numerous other little UNIX
type quirks.
Then I discovered that if you follow the instructions
in the manual you have to be very careful about
continuation lines. The nsradmin command on page 5-12
of the Informix Storage Manager manual for IDS 9.4 is
in fact one line.
And then I following the instruction on page 5-13 I
worked out that I would be tryin to execute the
command
ln -s /usr/informix/informix94 /usr/informix
Which even I realised would not have the desired
effect.
So back into UNIX admin problems. And /usr/informix
is a mount point so I couldn't even rename it.
If I ever finish this migration please suscribe freely
to "Big Issue". It'll probably be me begging.
regards
Malcolm
But if anybody has any bright ideas of how to migrate
IDS systems from machine to machine b easily please
let me know.
sending to informix-list
> Malcolm
>
> But if anybody has any bright ideas of how to migrate
> IDS systems from machine to machine b easily please
> let me know.
If I have understood you correctly
Can you take the source database down?
dd the chunks over the network?
Bring up 9.3 and check all ok
Do inplace upgrade to 9.4
↪ replying to Clive Eisen
Neil Truby — — source: Usenet: comp.databases.informix
Would only work if the original chunks are on file system.
However, if you can take the network hit, Informix mirroring could be made
to make this idea work I guess ...
Personally I've not found redirected restores diffficult, but admittedly
we've done them with ontape.
--
Neil Truby t:01932 724027
Director m:07798 811708
Ardenta Limited e:neil.truby@ardenta.com
"Clive Eisen" <clive@serendipita.com> wrote in message
news:412f178d$0$6157$db0fefd9@news.zen.co.uk...
> > Malcolm
> >
> > But if anybody has any bright ideas of how to migrate
> > IDS systems from machine to machine b easily please
> > let me know.
>
> If I have understood you correctly
>
> Can you take the source database down?
>
> dd the chunks over the network?
>
> Bring up 9.3 and check all ok
>
> Do inplace upgrade to 9.4
Neil Truby wrote:
> Would only work if the original chunks are on file system.
> However, if you can take the network hit, Informix mirroring could be made
> to make this idea work I guess ...
> Personally I've not found redirected restores diffficult, but admittedly
> we've done them with ontape.
>
No - I've done it raw - why do you think it only works with cooked?
↪ replying to Clive Eisen
Neil Truby — — source: Usenet: comp.databases.informix
"Clive Eisen" <clive@serendipita.com> wrote in message
news:412fb27d$0$6166$db0fefd9@news.zen.co.uk...
> Neil Truby wrote:
> > Would only work if the original chunks are on file system.
> > However, if you can take the network hit, Informix mirroring could be
made
> > to make this idea work I guess ...
> > Personally I've not found redirected restores diffficult, but admittedly
> > we've done them with ontape.
> >
> No - I've done it raw - why do you think it only works with cooked?
>> ... dd the chunks over the network ...
Here I'd taken you to mean via NFS. But perhaps you meant a dd piped
through a remsh between raw devices, in which case sorry, I misunderstood.
Neil Truby wrote:
> "Clive Eisen" <clive@serendipita.com> wrote in message
> news:412fb27d$0$6166$db0fefd9@news.zen.co.uk...
>
>>Neil Truby wrote:
>
> Here I'd taken you to mean via NFS. But perhaps you meant a dd piped
> through a remsh between raw devices, in which case sorry, I misunderstood.
exactly
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.