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.
A poster wanted to restore an IDS 7.31 level-0 ontape archive to a different rootdbs path or host. Jonathan Leffler said redirected restore is not in 7.31 and suggested recreating the original path via symlinks. Neil Truby suggested moving disks with Informix mirroring: mirror to the new storage, swap, then drop the mirror. No confirmation from the poster.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Dear all,
I have a level-0 backup archive of IDS 7.31 and i want to restore it in
another host. Now i met some problems. Can i change the rootdbs
location to a new one?
For example: when i use onstat -d in the IDS instance host and it will
show:
/dev/vx/rdsk/datadg/lvrootdbs is the location of rootdbs.
But in the new host, i want restore the rootdbs to a new location,
maybe change it to /dev/rdsk/lvrootdbs. Can i do it use ontape tool?
OR someone knows use some other IDS tool to make a archive, and then
change the location of database space during the restoring process?
It is very appreciate of your point.
JianwenSha@gmail.com wrote:
> I have a level-0 backup archive of IDS 7.31 and i want to restore it in
> another host. Now i met some problems. Can i change the rootdbs
> location to a new one?
>
> For example: when i use onstat -d in the IDS instance host and it will
> show:
>
> /dev/vx/rdsk/datadg/lvrootdbs is the location of rootdbs.
>
> But in the new host, i want restore the rootdbs to a new location,
> maybe change it to /dev/rdsk/lvrootdbs. Can i do it use ontape tool?
>
> OR someone knows use some other IDS tool to make a archive, and then
> change the location of database space during the restoring process?
In IDS 7.31, I don't think so. Redirected restore was added in IDS
10.00 (unless it was 9.40), but has not been added to 7.31 and won't be.
You might be able to get around the problem by using symlinks - on the
new machine, create a symlink called /dev/vx/rdsk/datadg/lvrootdbs and
have it point to the actual storage on the new machine. You may have
issues if Veritas (that's what the vx indicates, isn't it?) won't let
you mess around in its directories. And you'll have to keep the links
there in perpetuity - until you upgrade to IDS 10.00 and then do a level
0 archive and a redirected restore.
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
Thanks a million!
I think i get the point! But up to now, there's no any plan to upgrade
IDS from 7.31 to 9.4 or 10.0 for our system.
The service request is that we want to transfer all the database
volumes from disk array to SAN, the disk array managed by Veritas and i
want to restore the full database to a different location directory in
the same host and the new volumes provided by SAN, and make the
productive database runing during the restore process.
Please who can give me some advice?
"Jonathan Leffler 写道:
"
> JianwenSha@gmail.com wrote:
> > I have a level-0 backup archive of IDS 7.31 and i want to restore it in
> > another host. Now i met some problems. Can i change the rootdbs
> > location to a new one?
> >
> > For example: when i use onstat -d in the IDS instance host and it will
> > show:
> >
> > /dev/vx/rdsk/datadg/lvrootdbs is the location of rootdbs.
> >
> > But in the new host, i want restore the rootdbs to a new location,
> > maybe change it to /dev/rdsk/lvrootdbs. Can i do it use ontape tool?
> >
> > OR someone knows use some other IDS tool to make a archive, and then
> > change the location of database space during the restoring process?
>
> In IDS 7.31, I don't think so. Redirected restore was added in IDS
> 10.00 (unless it was 9.40), but has not been added to 7.31 and won't be.
>
> You might be able to get around the problem by using symlinks - on the
> new machine, create a symlink called /dev/vx/rdsk/datadg/lvrootdbs and
> have it point to the actual storage on the new machine. You may have
> issues if Veritas (that's what the vx indicates, isn't it?) won't let
> you mess around in its directories. And you'll have to keep the links
> there in perpetuity - until you upgrade to IDS 10.00 and then do a level
> 0 archive and a redirected restore.
>
> --
> Jonathan Leffler #include <disclaimer.h>
> Email: jleffler@earthlink.net, jleffler@us.ibm.com
> Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
↪ replying to JianwenSha@gmail.com
Neil Truby — — source: Usenet: comp.databases.informix
<JianwenSha@gmail.com> wrote in message
news:1169383542.956994.30030@51g2000cwl.googlegroups.com...
Thanks a million!
I think i get the point! But up to now, there's no any plan to upgrade
IDS from 7.31 to 9.4 or 10.0 for our system.
The service request is that we want to transfer all the database
volumes from disk array to SAN, the disk array managed by Veritas and i
want to restore the full database to a different location directory in
the same host and the new volumes provided by SAN, and make the
productive database runing during the restore process.
Please who can give me some advice?
I don't really understand what you are trying to do from this explanation,
sorry.
But if you are trying to move the database from old to new disk, you can use
Informix mirroring to establish a copy of the database server on the new
disk, then reverse the links so that the new location becomes the primary
and the original the mirror, then drop the mirror.
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.