External Restoration

Hello, IDS 11.10 FC3 on solaris 10. Problem: I have instance lt1 on my test server having 25 medium size databases (level 0 backup size of about 400 GB using ontape), now I want all these databases on the same server in another instance. Currenly the chunks of lt1 are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same server. I simply cannot build another instance and restore the level 0 as the chunk paths won’t be the same and restoration will abort giving me an error. What options do I have, OTHER than Export / Import OR HPL OR Archecker? Would External Backup and Restore help me in this case? I see the documents say that Cold Restoration would allow me to change the chunk path. Old path of chunks /dbs/lt1/….. New path of chunks /ids/lt2/….. Can this help me with my requirement? If yes then I need help with the restoration process as, what should be the path of root dbspaces for the new instance when I want to initialize it for the first time so that I have a instance which I can now take down and start the External Restoration with the copied chunks from old instance. Or do i have so simple create a new instance with the chunks in new path ( in this case do i have to build all the chunks as that of old instance or only rootdbs ). Else any suggestions of doing this in a better way will help me! Regards, Vikas

Vikas, You need to perform an ontape backup with chunk rename. I am assuming that you have correctly setup the onconfig of the destination. Here ensure that the servernum of the source and destination are different. Create a text file with the following structure, called dest_rename. <chunk name in source> <chunk offset> <chunk name in destination> <chunk offset in destination> Ensure that you include all the chunks here as otherwise you might end up overwriting the live db. On both the source database and destination set the tape dev to STDIO. In the ONCONFIG of the target ensure that the rootdbs is pointing to the root chunk of the source (otherwise restore fails) Assuming you have an env file for the source Informix instance called src.env and one for the destination Informix instance called dest.env. If the destination chunks are files, pre-create them by just touching them and set the appropriate permissions, chmod 0660 informix:Informix <files> Run $ . src.env $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to thefile created with the rename details as indicated above>) After it finishes the destination will be in quiescent mode. BTW, you can use ontape instead of STDIO, but STDIO is faster ;) You can monitor the progress of the backup using onstat -g arc on the source and the progress of the restore using onstat -D on the destination. Regards, Kenneth Penza Systems Engineer| SMD MALTA INFORMATION TECHNOLOGY AGENCY * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : http://www.mita.gov.mt * Please read our Legal Notice: http://emailpolicy.mita.gov.mt P Please consider your environmental responsibility before printing this e-mail -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of VIKAS HIVARKAR Sent: 03 February 2009 16:58 To: ids@iiug.org Subject: External Restoration [14708] Hello, IDS 11.10 FC3 on solaris 10. Problem: I have instance lt1 on my test server having 25 medium size databases (level 0 backup size of about 400 GB using ontape), now I want all these databases on the same server in another instance. Currenly the chunks of lt1 are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same server. I simply cannot build another instance and restore the level 0 as the chunk paths won't be the same and restoration will abort giving me an error. What options do I have, OTHER than Export / Import OR HPL OR Archecker? Would External Backup and Restore help me in this case? I see the documents say that Cold Restoration would allow me to change the chunk path. Old path of chunks /dbs/lt1/..... New path of chunks /ids/lt2/..... Can this help me with my requirement? If yes then I need help with the restoration process as, what should be the path of root dbspaces for the new instance when I want to initialize it for the first time so that I have a instance which I can now take down and start the External Restoration with the copied chunks from old instance. Or do i have so simple create a new instance with the chunks in new path ( in this case do i have to build all the chunks as that of old instance or only rootdbs ). Else any suggestions of doing this in a better way will help me! Regards, Vikas ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

You can indeed use a backup and restore. IDS 11.10 and later allow you to rename the chunks at restore time. Just make sure that either the original server is offline, or that the new server has a different SERVERNUM and SERVERNAME in its ONCONFIG file than the existing one. Art On Tue, Feb 3, 2009 at 10:58 AM, VIKAS HIVARKAR <vikas.hivarkar@gmail.com>wrote: > Hello, > > IDS 11.10 FC3 on solaris 10. > > Problem: I have instance lt1 on my test server having 25 medium size > databases > (level 0 backup size of about 400 GB using ontape), now I want all these > databases on the same server in another instance. Currenly the chunks of > lt1 > are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same > server. > > I simply cannot build another instance and restore the level 0 as the chunk > paths won't be the same and restoration will abort giving me an error. > > What options do I have, OTHER than Export / Import OR HPL OR Archecker? > > Would External Backup and Restore help me in this case? I see the documents > say that Cold Restoration would allow me to change the chunk path. > > Old path of chunks /dbs/lt1/….. > New path of chunks /ids/lt2/….. > > Can this help me with my requirement? If yes then > > I need help with the restoration process as, what should be the path of > root > dbspaces for the new instance when I want to initialize it for the first > time > so that I have a instance which I can now take down and start the External > Restoration with the copied chunks from old instance. > Or do i have so simple create a new instance with the chunks in new path ( > in > this case do i have to build all the chunks as that of old instance or only > rootdbs ). > > Else any suggestions of doing this in a better way will help me! > > Regards, > Vikas > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. --0016360e3b3ccd985b046206332a

Kenneth, Art. Thanks for the help ! one query: --- In the ONCONFIG of the target ensure that the rootdbs is pointing to the root chunk of the source (otherwise restore fails)---- Does it mean, we would be restoring the level 0 backup of one instance to itself but at new place? Regards, Vikas. ------------------------------------------------------------------------------ You can indeed use a backup and restore. IDS 11.10 and later allow you to rename the chunks at restore time. Just make sure that either the original server is offline, or that the new server has a different SERVERNUM and SERVERNAME in its ONCONFIG file than the existing one. Art ------------------------------------------------------------------------------ Vikas, You need to perform an ontape backup with chunk rename. I am assuming that you have correctly setup the onconfig of the destination. Here ensure that the servernum of the source and destination are different. Create a text file with the following structure, called dest_rename. <chunk name in source> <chunk offset> <chunk name in destination> <chunk offset in destination> Ensure that you include all the chunks here as otherwise you might end up overwriting the live db. On both the source database and destination set the tape dev to STDIO. In the ONCONFIG of the target ensure that the rootdbs is pointing to the root chunk of the source (otherwise restore fails) Assuming you have an env file for the source Informix instance called src.env and one for the destination Informix instance called dest.env. If the destination chunks are files, pre-create them by just touching them and set the appropriate permissions, chmod 0660 informix:Informix <files> Run $ . src.env $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to thefile created with the rename details as indicated above>) After it finishes the destination will be in quiescent mode. BTW, you can use ontape instead of STDIO, but STDIO is faster ;) You can monitor the progress of the backup using onstat -g arc on the source and the progress of the restore using onstat -D on the destination. Regards, Kenneth Penza Systems Engineer| SMD MALTA INFORMATION TECHNOLOGY AGENCY * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : http://www.mita.gov.mt * Please read our Legal Notice: http://emailpolicy.mita.gov.mt P Please consider your environmental responsibility before printing this e-mail -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of VIKAS HIVARKAR Sent: 03 February 2009 16:58 To: ids@iiug.org Subject: External Restoration [14708] Hello, IDS 11.10 FC3 on solaris 10. Problem: I have instance lt1 on my test server having 25 medium size databases (level 0 backup size of about 400 GB using ontape), now I want all these databases on the same server in another instance. Currenly the chunks of lt1 are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same server. I simply cannot build another instance and restore the level 0 as the chunk paths won't be the same and restoration will abort giving me an error. What options do I have, OTHER than Export / Import OR HPL OR Archecker? Would External Backup and Restore help me in this case? I see the documents say that Cold Restoration would allow me to change the chunk path. Old path of chunks /dbs/lt1/..... New path of chunks /ids/lt2/..... Can this help me with my requirement? If yes then I need help with the restoration process as, what should be the path of root dbspaces for the new instance when I want to initialize it for the first time so that I have a instance which I can now take down and start the External Restoration with the copied chunks from old instance. Or do i have so simple create a new instance with the chunks in new path ( in this case do i have to build all the chunks as that of old instance or only rootdbs ). Else any suggestions of doing this in a better way will help me! Regards, Vikas

Vikas, Basically you will be restoring a backup of the source instance to a new destination. The root chunk must be the same, so that the restore process starts, during the restore ontape will map the old rootdbs chunk with the new one as specified in the file. The restore will be on the new chunks specified. That is why you must be sure that the rename file is correctly setup. Regards, Kenneth Penza Systems Engineer| SMD MALTA INFORMATION TECHNOLOGY AGENCY * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : http://www.mita.gov.mt * Please read our Legal Notice: http://emailpolicy.mita.gov.mt P Please consider your environmental responsibility before printing this e-mail -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of VIKAS HIVARKAR Sent: 04 February 2009 09:50 To: ids@iiug.org Subject: Re: External Restoration [14722] Kenneth, Art. Thanks for the help ! one query: --- In the ONCONFIG of the target ensure that the rootdbs is pointing to the root chunk of the source (otherwise restore fails)---- Does it mean, we would be restoring the level 0 backup of one instance to itself but at new place? Regards, Vikas. ------------------------------------------------------------------------ ------ You can indeed use a backup and restore. IDS 11.10 and later allow you to rename the chunks at restore time. Just make sure that either the original server is offline, or that the new server has a different SERVERNUM and SERVERNAME in its ONCONFIG file than the existing one. Art ------------------------------------------------------------------------ ------ Vikas, You need to perform an ontape backup with chunk rename. I am assuming that you have correctly setup the onconfig of the destination. Here ensure that the servernum of the source and destination are different. Create a text file with the following structure, called dest_rename. <chunk name in source> <chunk offset> <chunk name in destination> <chunk offset in destination> Ensure that you include all the chunks here as otherwise you might end up overwriting the live db. On both the source database and destination set the tape dev to STDIO. In the ONCONFIG of the target ensure that the rootdbs is pointing to the root chunk of the source (otherwise restore fails) Assuming you have an env file for the source Informix instance called src.env and one for the destination Informix instance called dest.env. If the destination chunks are files, pre-create them by just touching them and set the appropriate permissions, chmod 0660 informix:Informix <files> Run $ . src.env $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to thefile created with the rename details as indicated above>) After it finishes the destination will be in quiescent mode. BTW, you can use ontape instead of STDIO, but STDIO is faster ;) You can monitor the progress of the backup using onstat -g arc on the source and the progress of the restore using onstat -D on the destination. Regards, Kenneth Penza Systems Engineer| SMD MALTA INFORMATION TECHNOLOGY AGENCY * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : http://www.mita.gov.mt * Please read our Legal Notice: http://emailpolicy.mita.gov.mt P Please consider your environmental responsibility before printing this e-mail -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of VIKAS HIVARKAR Sent: 03 February 2009 16:58 To: ids@iiug.org Subject: External Restoration [14708] Hello, IDS 11.10 FC3 on solaris 10. Problem: I have instance lt1 on my test server having 25 medium size databases (level 0 backup size of about 400 GB using ontape), now I want all these databases on the same server in another instance. Currenly the chunks of lt1 are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same server. I simply cannot build another instance and restore the level 0 as the chunk paths won't be the same and restoration will abort giving me an error. What options do I have, OTHER than Export / Import OR HPL OR Archecker? Would External Backup and Restore help me in this case? I see the documents say that Cold Restoration would allow me to change the chunk path. Old path of chunks /dbs/lt1/..... New path of chunks /ids/lt2/..... Can this help me with my requirement? If yes then I need help with the restoration process as, what should be the path of root dbspaces for the new instance when I want to initialize it for the first time so that I have a instance which I can now take down and start the External Restoration with the copied chunks from old instance. Or do i have so simple create a new instance with the chunks in new path ( in this case do i have to build all the chunks as that of old instance or only rootdbs ). Else any suggestions of doing this in a better way will help me! Regards, Vikas ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

No. I don't know what Kenneth is referring to. Ontape does NOT need to know about the original root db space. You can set that to anything you want as long as you are including a rename clause for that particular chunk. Art On Wed, Feb 4, 2009 at 3:50 AM, VIKAS HIVARKAR <vikas.hivarkar@gmail.com>wrote: > Kenneth, Art. Thanks for the help ! > > one query: > > --- In the ONCONFIG of the target ensure that the rootdbs is pointing to > the > root chunk of the source (otherwise restore fails)---- > > Does it mean, we would be restoring the level 0 backup of one instance to > itself but at new place? > > Regards, > Vikas. > > > ------------------------------------------------------------------------------ > > You can indeed use a backup and restore. IDS 11.10 and later allow you to > rename the chunks at restore time. Just make sure that either the original > server is offline, or that the new server has a different SERVERNUM and > SERVERNAME in its ONCONFIG file than the existing one. > > Art > > > ------------------------------------------------------------------------------ > Vikas, > > You need to perform an ontape backup with chunk rename. I am > assuming that you have correctly setup the onconfig of the destination. > Here ensure that the servernum of the source and destination are > different. Create a text file with the following structure, called > dest_rename. > <chunk name in source> <chunk offset> <chunk name in destination> <chunk > offset in destination> > > Ensure that you include all the chunks here as otherwise you might end > up overwriting the live db. > > On both the source database and destination set the tape dev to STDIO. > In the ONCONFIG of the target ensure that the rootdbs is pointing to the > root chunk of the source (otherwise restore fails) > Assuming you have an env file for the source Informix instance called > src.env and one for the destination Informix instance called dest.env. > If the destination chunks are files, pre-create them by just touching > them and set the appropriate permissions, chmod 0660 informix:Informix > <files> > > Run > $ . src.env > $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to the> file created with the rename details as indicated above>) > > After it finishes the destination will be in quiescent mode. > > BTW, you can use ontape instead of STDIO, but STDIO is faster ;) > You can monitor the progress of the backup using onstat -g arc on the > source and the progress of the restore using onstat -D on the > destination. > > Regards, > Kenneth Penza > Systems Engineer| SMD > MALTA INFORMATION TECHNOLOGY AGENCY > * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : > http://www.mita.gov.mt > * Please read our Legal Notice: http://emailpolicy.mita.gov.mt > P Please consider your environmental responsibility before printing this > e-mail > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > VIKAS HIVARKAR > Sent: 03 February 2009 16:58 > To: ids@iiug.org > Subject: External Restoration [14708] > > Hello, > > IDS 11.10 FC3 on solaris 10. > > Problem: I have instance lt1 on my test server having 25 medium size > databases > (level 0 backup size of about 400 GB using ontape), now I want all these > > databases on the same server in another instance. Currenly the chunks of > lt1 > are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same > server. > > I simply cannot build another instance and restore the level 0 as the > chunk > paths won't be the same and restoration will abort giving me an error. > > What options do I have, OTHER than Export / Import OR HPL OR Archecker? > > Would External Backup and Restore help me in this case? I see the > documents > say that Cold Restoration would allow me to change the chunk path. > > Old path of chunks /dbs/lt1/..... > New path of chunks /ids/lt2/..... > > Can this help me with my requirement? If yes then > > I need help with the restoration process as, what should be the path of > root > dbspaces for the new instance when I want to initialize it for the first > time > so that I have a instance which I can now take down and start the > External > Restoration with the copied chunks from old instance. > Or do i have so simple create a new instance with the chunks in new path > ( in > this case do i have to build all the chunks as that of old instance or > only > rootdbs ). > > Else any suggestions of doing this in a better way will help me! > > Regards, > Vikas > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. --0016361e8252684c2f04621665de

he's talking about the ROOTPATH in the onconfig file ... That has to be set to the original location in the target file ... the rename will then change it .. Peter Logan Senior Database Administrator Phone: 616/878-8309 From: "Art Kagel" <art.kagel@gmail.com> To: ids@iiug.org Date: 02/04/2009 06:51 AM Subject: Re: External Restoration [14728] Sent by: ids-bounces@iiug.org No. I don't know what Kenneth is referring to. Ontape does NOT need to know about the original root db space. You can set that to anything you want as long as you are including a rename clause for that particular chunk. Art On Wed, Feb 4, 2009 at 3:50 AM, VIKAS HIVARKAR <vikas.hivarkar@gmail.com>wrote: > Kenneth, Art. Thanks for the help ! > > one query: > > --- In the ONCONFIG of the target ensure that the rootdbs is pointing to > the > root chunk of the source (otherwise restore fails)---- > > Does it mean, we would be restoring the level 0 backup of one instance to > itself but at new place? > > Regards, > Vikas. > > > ------------------------------------------------------------------------------ > > You can indeed use a backup and restore. IDS 11.10 and later allow you to > rename the chunks at restore time. Just make sure that either the original > server is offline, or that the new server has a different SERVERNUM and > SERVERNAME in its ONCONFIG file than the existing one. > > Art > > > ------------------------------------------------------------------------------ > Vikas, > > You need to perform an ontape backup with chunk rename. I am > assuming that you have correctly setup the onconfig of the destination. > Here ensure that the servernum of the source and destination are > different. Create a text file with the following structure, called > dest_rename. > <chunk name in source> <chunk offset> <chunk name in destination> <chunk > offset in destination> > > Ensure that you include all the chunks here as otherwise you might end > up overwriting the live db. > > On both the source database and destination set the tape dev to STDIO. > In the ONCONFIG of the target ensure that the rootdbs is pointing to the > root chunk of the source (otherwise restore fails) > Assuming you have an env file for the source Informix instance called > src.env and one for the destination Informix instance called dest.env. > If the destination chunks are files, pre-create them by just touching > them and set the appropriate permissions, chmod 0660 informix:Informix > <files> > > Run > $ . src.env > $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to the> file created with the rename details as indicated above>) > > After it finishes the destination will be in quiescent mode. > > BTW, you can use ontape instead of STDIO, but STDIO is faster ;) > You can monitor the progress of the backup using onstat -g arc on the > source and the progress of the restore using onstat -D on the > destination. > > Regards, > Kenneth Penza > Systems Engineer| SMD > MALTA INFORMATION TECHNOLOGY AGENCY > * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : > http://www.mita.gov.mt > * Please read our Legal Notice: http://emailpolicy.mita.gov.mt > P Please consider your environmental responsibility before printing this > e-mail > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > VIKAS HIVARKAR > Sent: 03 February 2009 16:58 > To: ids@iiug.org > Subject: External Restoration [14708] > > Hello, > > IDS 11.10 FC3 on solaris 10. > > Problem: I have instance lt1 on my test server having 25 medium size > databases > (level 0 backup size of about 400 GB using ontape), now I want all these > > databases on the same server in another instance. Currenly the chunks of > lt1 > are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same > server. > > I simply cannot build another instance and restore the level 0 as the > chunk > paths won't be the same and restoration will abort giving me an error. > > What options do I have, OTHER than Export / Import OR HPL OR Archecker? > > Would External Backup and Restore help me in this case? I see the > documents > say that Cold Restoration would allow me to change the chunk path. > > Old path of chunks /dbs/lt1/..... > New path of chunks /ids/lt2/..... > > Can this help me with my requirement? If yes then > > I need help with the restoration process as, what should be the path of > root > dbspaces for the new instance when I want to initialize it for the first > time > so that I have a instance which I can now take down and start the > External > Restoration with the copied chunks from old instance. > Or do i have so simple create a new instance with the chunks in new path > ( in > this case do i have to build all the chunks as that of old instance or > only > rootdbs ). > > Else any suggestions of doing this in a better way will help me! > > Regards, > Vikas > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. --0016361e8252684c2f04621665de ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Hi, no. There is a general requirement that the ONCONFIG file configuration for the restore be the same as it was at backup time. (Some onconfig parameters are not checked strictly, but others are.) For that reason (among other parameters) the ROOTPATH has to be the same as during the backup. In your case that means it has to point to the chunk of the source IDS instance. [ For your "cloning" scenario, some other parameters in the ONCONFIG for the restore need to be explicitly different, e.g. SERVERNAME. ] TO AVOID OVERWRITING the source IDS instance, you have to use the RENAME functionality during the restore. And here you have to specify a RENAMING FOR ALL CHUNKS, including the chunks of the root dbspace. The restore itself will then change the ONCONFIG file (of the restored instance) to reflect the new ROOTPATH correctly as specified in the renaming. And of course the restore will use these new locations for the restoring of data to the disks, thus not overwriting anything from the source instance. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 04.02.2009 09:50:00: > Kenneth, Art. Thanks for the help ! > > one query: > > --- In the ONCONFIG of the target ensure that the rootdbs is pointing to the > root chunk of the source (otherwise restore fails)---- > > Does it mean, we would be restoring the level 0 backup of one instance to > itself but at new place? > > Regards, > Vikas. > > ------------------------------------------------------------------------------ > > You can indeed use a backup and restore. IDS 11.10 and later allow you to > rename the chunks at restore time. Just make sure that either the original > server is offline, or that the new server has a different SERVERNUM and > SERVERNAME in its ONCONFIG file than the existing one. > > Art > > ------------------------------------------------------------------------------ > Vikas, > > You need to perform an ontape backup with chunk rename. I am > assuming that you have correctly setup the onconfig of the destination. > Here ensure that the servernum of the source and destination are > different. Create a text file with the following structure, called > dest_rename. > <chunk name in source> <chunk offset> <chunk name in destination> <chunk > offset in destination> > > Ensure that you include all the chunks here as otherwise you might end > up overwriting the live db. > > On both the source database and destination set the tape dev to STDIO. > In the ONCONFIG of the target ensure that the rootdbs is pointing to the > root chunk of the source (otherwise restore fails) > Assuming you have an env file for the source Informix instance called > src.env and one for the destination Informix instance called dest.env. > If the destination chunks are files, pre-create them by just touching > them and set the appropriate permissions, chmod 0660 informix:Informix > <files> > > Run > $ . src.env > $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to the> file created with the rename details as indicated above>) > > After it finishes the destination will be in quiescent mode. > > BTW, you can use ontape instead of STDIO, but STDIO is faster ;) > You can monitor the progress of the backup using onstat -g arc on the > source and the progress of the restore using onstat -D on the > destination. > > Regards, > Kenneth Penza > Systems Engineer| SMD > MALTA INFORMATION TECHNOLOGY AGENCY > * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : > http://www.mita.gov.mt > * Please read our Legal Notice: http://emailpolicy.mita.gov.mt > P Please consider your environmental responsibility before printing this > e-mail > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > VIKAS HIVARKAR > Sent: 03 February 2009 16:58 > To: ids@iiug.org > Subject: External Restoration [14708] > > Hello, > > IDS 11.10 FC3 on solaris 10. > > Problem: I have instance lt1 on my test server having 25 medium size > databases > (level 0 backup size of about 400 GB using ontape), now I want all these > > databases on the same server in another instance. Currenly the chunks of > lt1 > are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same > server. > > I simply cannot build another instance and restore the level 0 as the > chunk > paths won't be the same and restoration will abort giving me an error. > > What options do I have, OTHER than Export / Import OR HPL OR Archecker? > > Would External Backup and Restore help me in this case? I see the > documents > say that Cold Restoration would allow me to change the chunk path. > > Old path of chunks /dbs/lt1/..... > New path of chunks /ids/lt2/..... > > Can this help me with my requirement? If yes then > > I need help with the restoration process as, what should be the path of > root > dbspaces for the new instance when I want to initialize it for the first > time > so that I have a instance which I can now take down and start the > External > Restoration with the copied chunks from old instance. > Or do i have so simple create a new instance with the chunks in new path > ( in > this case do i have to build all the chunks as that of old instance or > only > rootdbs ). > > Else any suggestions of doing this in a better way will help me! > > Regards, > Vikas > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Yes, actually I was referring to the ROOTPATH, (I could not recall the parameter name). Regards, Kenneth Penza Systems Engineer| SMD MALTA INFORMATION TECHNOLOGY AGENCY * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : http://www.mita.gov.mt * Please read our Legal Notice: http://emailpolicy.mita.gov.mt P Please consider your environmental responsibility before printing this e-mail -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Peter_Logan@spartanstores.com Sent: 04 February 2009 14:25 To: ids@iiug.org Subject: Re: External Restoration [14730] he's talking about the ROOTPATH in the onconfig file ... That has to be set to the original location in the target file ... the rename will then change it .. Peter Logan Senior Database Administrator Phone: 616/878-8309 From: "Art Kagel" <art.kagel@gmail.com> To: ids@iiug.org Date: 02/04/2009 06:51 AM Subject: Re: External Restoration [14728] Sent by: ids-bounces@iiug.org No. I don't know what Kenneth is referring to. Ontape does NOT need to know about the original root db space. You can set that to anything you want as long as you are including a rename clause for that particular chunk. Art On Wed, Feb 4, 2009 at 3:50 AM, VIKAS HIVARKAR <vikas.hivarkar@gmail.com>wrote: > Kenneth, Art. Thanks for the help ! > > one query: > > --- In the ONCONFIG of the target ensure that the rootdbs is pointing to > the > root chunk of the source (otherwise restore fails)---- > > Does it mean, we would be restoring the level 0 backup of one instance to > itself but at new place? > > Regards, > Vikas. > > > ------------------------------------------------------------------------ ------ > > You can indeed use a backup and restore. IDS 11.10 and later allow you to > rename the chunks at restore time. Just make sure that either the original > server is offline, or that the new server has a different SERVERNUM and > SERVERNAME in its ONCONFIG file than the existing one. > > Art > > > ------------------------------------------------------------------------ ------ > Vikas, > > You need to perform an ontape backup with chunk rename. I am > assuming that you have correctly setup the onconfig of the destination. > Here ensure that the servernum of the source and destination are > different. Create a text file with the following structure, called > dest_rename. > <chunk name in source> <chunk offset> <chunk name in destination> <chunk > offset in destination> > > Ensure that you include all the chunks here as otherwise you might end > up overwriting the live db. > > On both the source database and destination set the tape dev to STDIO. > In the ONCONFIG of the target ensure that the rootdbs is pointing to the > root chunk of the source (otherwise restore fails) > Assuming you have an env file for the source Informix instance called > src.env and one for the destination Informix instance called dest.env. > If the destination chunks are files, pre-create them by just touching > them and set the appropriate permissions, chmod 0660 informix:Informix > <files> > > Run > $ . src.env > $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to the > file created with the rename details as indicated above>) > > After it finishes the destination will be in quiescent mode. > > BTW, you can use ontape instead of STDIO, but STDIO is faster ;) > You can monitor the progress of the backup using onstat -g arc on the > source and the progress of the restore using onstat -D on the > destination. > > Regards, > Kenneth Penza > Systems Engineer| SMD > MALTA INFORMATION TECHNOLOGY AGENCY > * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : > http://www.mita.gov.mt > * Please read our Legal Notice: http://emailpolicy.mita.gov.mt > P Please consider your environmental responsibility before printing this > e-mail > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > VIKAS HIVARKAR > Sent: 03 February 2009 16:58 > To: ids@iiug.org > Subject: External Restoration [14708] > > Hello, > > IDS 11.10 FC3 on solaris 10. > > Problem: I have instance lt1 on my test server having 25 medium size > databases > (level 0 backup size of about 400 GB using ontape), now I want all these > > databases on the same server in another instance. Currenly the chunks of > lt1 > are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same > server. > > I simply cannot build another instance and restore the level 0 as the > chunk > paths won't be the same and restoration will abort giving me an error. > > What options do I have, OTHER than Export / Import OR HPL OR Archecker? > > Would External Backup and Restore help me in this case? I see the > documents > say that Cold Restoration would allow me to change the chunk path. > > Old path of chunks /dbs/lt1/..... > New path of chunks /ids/lt2/..... > > Can this help me with my requirement? If yes then > > I need help with the restoration process as, what should be the path of > root > dbspaces for the new instance when I want to initialize it for the first > time > so that I have a instance which I can now take down and start the > External > Restoration with the copied chunks from old instance. > Or do i have so simple create a new instance with the chunks in new path > ( in > this case do i have to build all the chunks as that of old instance or > only > rootdbs ). > > Else any suggestions of doing this in a better way will help me! > > Regards, > Vikas > > > > ************************************************************************ ******* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. --0016361e8252684c2f04621665de ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

Hello, Thanks to all as Restoration with rename went smoothly when I pointed the ROOTPATH to root chunk of original instance, in my case /dbs/lt1/rootdbs. But there is some doubt and please some one could clear it? I used a level 0 backup from UAT instance (on different HOST) which have all the chunk paths exactly same as the chunk paths of LT1 instance on TEST server (I created the new instance on TEST server). ROOTPATH /dbs/lt1/rootdbs for LT1 instance on TEST server. ROOTPATH /dbs/lt1/rootdbs for UAT instance, whose level 0 backup I used for restoration. ROOTPATH /dbs/lt1/rootdbs set on NEW instance (before starting its restoration) was same as ROOTHPATH in onconfig on UAT instance and also on the LT1 instance. But my entry in onconfig for NEW instance was: ROOTPATH /dbs/lt1/rootdbsAND NOT ROOTPATH HOST:/dbs/lt1/rootdbs AT the time of Restoration the ROOTPATH actually pointed to the root chunk of LT1 instance on same server. So what does IDS check? Only the ROOTPATH “entry”, which should be same as onconfig from where the level 0 backup was taken OR does it check the contents of rootdbs. In my restoration it could never read the original rootdbs chunk on UAT instance (as it was on another HOST machine and I did NOT mention HOST: $PATH in onconfig on NEW instance). Thanks, Vikas. ------------------------------------------------------------------------------ Hi, no. There is a general requirement that the ONCONFIG file configuration for the restore be the same as it was at backup time. (Some onconfig parameters are not checked strictly, but others are.) For that reason (among other parameters) the ROOTPATH has to be the same as during the backup. In your case that means it has to point to the chunk of the source IDS instance. [ For your "cloning" scenario, some other parameters in the ONCONFIG for the restore need to be explicitly different, e.g. SERVERNAME. ] TO AVOID OVERWRITING the source IDS instance, you have to use the RENAME functionality during the restore. And here you have to specify a RENAMING FOR ALL CHUNKS, including the chunks of the root dbspace. The restore itself will then change the ONCONFIG file (of the restored instance) to reflect the new ROOTPATH correctly as specified in the renaming. And of course the restore will use these new locations for the restoring of data to the disks, thus not overwriting anything from the source instance. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 04.02.2009 09:50:00: > Kenneth, Art. Thanks for the help ! > > one query: > > --- In the ONCONFIG of the target ensure that the rootdbs is pointing to the > root chunk of the source (otherwise restore fails)---- > > Does it mean, we would be restoring the level 0 backup of one instance to > itself but at new place? > > Regards, > Vikas. > > ------------------------------------------------------------------------------ > > You can indeed use a backup and restore. IDS 11.10 and later allow you to > rename the chunks at restore time. Just make sure that either the original > server is offline, or that the new server has a different SERVERNUM and > SERVERNAME in its ONCONFIG file than the existing one. > > Art > > ------------------------------------------------------------------------------ > Vikas, > > You need to perform an ontape backup with chunk rename. I am > assuming that you have correctly setup the onconfig of the destination. > Here ensure that the servernum of the source and destination are > different. Create a text file with the following structure, called > dest_rename. > <chunk name in source> <chunk offset> <chunk name in destination> <chunk > offset in destination> > > Ensure that you include all the chunks here as otherwise you might end > up overwriting the live db. > > On both the source database and destination set the tape dev to STDIO. > In the ONCONFIG of the target ensure that the rootdbs is pointing to the > root chunk of the source (otherwise restore fails) > Assuming you have an env file for the source Informix instance called > src.env and one for the destination Informix instance called dest.env. > If the destination chunks are files, pre-create them by just touching > them and set the appropriate permissions, chmod 0660 informix:Informix > <files> > > Run > $ . src.env > $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to the> file created with the rename details as indicated above>) > > After it finishes the destination will be in quiescent mode. > > BTW, you can use ontape instead of STDIO, but STDIO is faster ;) > You can monitor the progress of the backup using onstat -g arc on the > source and the progress of the restore using onstat -D on the > destination. > > Regards, > Kenneth Penza > Systems Engineer| SMD > MALTA INFORMATION TECHNOLOGY AGENCY > * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : > http://www.mita.gov.mt > * Please read our Legal Notice: http://emailpolicy.mita.gov.mt > P Please consider your environmental responsibility before printing this > e-mail > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > VIKAS HIVARKAR > Sent: 03 February 2009 16:58 > To: ids@iiug.org > Subject: External Restoration [14708] > > Hello, > > IDS 11.10 FC3 on solaris 10. > > Problem: I have instance lt1 on my test server having 25 medium size > databases > (level 0 backup size of about 400 GB using ontape), now I want all these > > databases on the same server in another instance. Currenly the chunks of > lt1 > are in /dbs/lt1/ and I want the new database chunks in /ids/lt2 on same > server. > > I simply cannot build another instance and restore the level 0 as the > chunk > paths won't be the same and restoration will abort giving me an error. > > What options do I have, OTHER than Export / Import OR HPL OR Archecker? > > Would External Backup and Restore help me in this case? I see the > documents > say that Cold Restoration would allow me to change the chunk path. > > Old path of chunks /dbs/lt1/..... > New path of chunks /ids/lt2/..... > > Can this help me with my requirement? If yes then > > I need help with the restoration process as, what should be the path of > root > dbspaces for the new instance when I want to initialize it for the first > time > so that I have a instance which I can now take down and start the > External > Restoration with the copied chunks from old instance. > Or do i have so simple create a new instance with the chunks in new path > ( in > this case do i have to build all the chunks as tha

Hi, it only checks the value of the ROOTPATH parameter, i.e. the chunk path name. After all, this is a restore, and you can do it with the files still having a size of 0 (zero) bytes. The file (or raw device) has to exist, but it doesn't matter really, what is there. Especially, the restore on one (target) host (UNIX machine) of a backup taken from a different (source) host would never attempt to access any chunk on the source host, not even for any checking. [ There is a check of disk content for the purpose of log salvage. This gives the admin the chance to salvage any logical log files (not yet backed up) that may still be lingering on the disk ... before starting the actual restore (which overwrites such lingering log files). And it also does not depend solely on the ROOTPATH parameter (to search for and find lingering logical logs). Also the "oncfg..." file in $INFORMIXDIR/etc/... is used for this purpose. But this is never done on a different machine/instance. It is done only locally. Because the impending overwrite (by the restore) is only locally, so a possible log salvage is needed only locally. ] Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 06.02.2009 10:03:13: > Hello, > > Thanks to all as Restoration with rename went smoothly when I pointed the > ROOTPATH to root chunk of original instance, in my case /dbs/lt1/rootdbs. > > But there is some doubt and please some one could clear it? > > I used a level 0 backup from UAT instance (on different HOST) which have all > the chunk paths exactly same as the chunk paths of LT1 instance on > TEST server > (I created the new instance on TEST server). > > ROOTPATH /dbs/lt1/rootdbs for LT1 instance on TEST server. > > ROOTPATH /dbs/lt1/rootdbs for UAT instance, whose level 0 backup I used for > restoration. > > ROOTPATH /dbs/lt1/rootdbs set on NEW instance (before starting its > restoration) was same as ROOTHPATH in onconfig on UAT instance and > also on the > LT1 instance. > > But my entry in onconfig for NEW instance was: > ROOTPATH /dbs/lt1/rootdbs> AND NOT > ROOTPATH HOST:/dbs/lt1/rootdbs > > AT the time of Restoration the ROOTPATH actually pointed to the rootchunk of > LT1 instance on same server. > > So what does IDS check? Only the ROOTPATH ?entry?, which should be same as > onconfig from where the level 0 backup was taken OR does it check > the contents > of rootdbs. > In my restoration it could never read the original rootdbs chunk on UAT > instance (as it was on another HOST machine and I did NOT mention HOST: $PATH > in onconfig on NEW instance). > > Thanks, > Vikas. > > ------------------------------------------------------------------------------ > Hi, > > no. > > There is a general requirement that the ONCONFIG file configuration > for the restore be the same as it was at backup time. (Some > onconfig parameters are not checked strictly, but others are.) > For that reason (among other parameters) the ROOTPATH > has to be the same as during the backup. In your case that means > it has to point to the chunk of the source IDS instance. > > [ For your "cloning" scenario, some other parameters in the > > ONCONFIG for the restore need to be explicitly different, > > e.g. SERVERNAME. ] > > TO AVOID OVERWRITING the source IDS instance, you have to > use the RENAME functionality during the restore. And here you > have to specify a RENAMING FOR ALL CHUNKS, including the > chunks of the root dbspace. The restore itself will then change > the ONCONFIG file (of the restored instance) to reflect the new > ROOTPATH correctly as specified in the renaming. > And of course the restore will use these new locations for > the restoring of data to the disks, thus not overwriting anything > from the source instance. > > Regards, > Martin > -- > Martin Fuerderer > IBM Informix Development Munich, Germany > Information Management > > IBM Deutschland Research & Development GmbH > Chairman of the Supervisory Board: Martin Jetter > Board of Management: Erich Baier > Corporate Seat: Boeblingen, Germany > Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 > > ids-bounces@iiug.org wrote on 04.02.2009 09:50:00: > > > Kenneth, Art. Thanks for the help ! > > > > one query: > > > > --- In the ONCONFIG of the target ensure that the rootdbs is pointing to > the > > root chunk of the source (otherwise restore fails)---- > > > > Does it mean, we would be restoring the level 0 backup of one instance > to > > itself but at new place? > > > > Regards, > > Vikas. > > > > > ------------------------------------------------------------------------------ > > > > You can indeed use a backup and restore. IDS 11.10 and later allow you > to > > rename the chunks at restore time. Just make sure that either the > original > > server is offline, or that the new server has a different SERVERNUM and > > SERVERNAME in its ONCONFIG file than the existing one. > > > > Art > > > > > ------------------------------------------------------------------------------ > > Vikas, > > > > You need to perform an ontape backup with chunk rename. I am > > assuming that you have correctly setup the onconfig of the destination. > > Here ensure that the servernum of the source and destination are > > different. Create a text file with the following structure, called > > dest_rename. > > <chunk name in source> <chunk offset> <chunk name in destination> <chunk > > > offset in destination> > > > > Ensure that you include all the chunks here as otherwise you might end > > up overwriting the live db. > > > > On both the source database and destination set the tape dev to STDIO. > > In the ONCONFIG of the target ensure that the rootdbs is pointing to the > > > root chunk of the source (otherwise restore fails) > > Assuming you have an env file for the source Informix instance called > > src.env and one for the destination Informix instance called dest.env. > > If the destination chunks are files, pre-create them by just touching > > them and set the appropriate permissions, chmod 0660 informix:Informix > > <files> > > > > Run > > $ . src.env > > $ ontape -s -L 0 | (. dest.env; ontape -r -rename -f <full path to the > > file created with the rename details as indicated above>) > > > > After it finishes the destination will be in quiescent mode. > > > > BTW, you can use ontape instead of STDIO, but STDIO is faster ;) > > You can monitor the progress of the backup using onstat -g arc on the > > source and the progress of the restore using onstat -D on the > > destination. > > > > Regards, > > Kenneth

Thank you Martin !