Changes dbspace path without having to drop & re-a

Good afternoon, I've got a situation where I need to use symbolic-links to DB spaces instead of a hard-path on a Linux based Informix server. Will onspaces allow me to gracefully re-point a DBspace chunk from /dev/mapper/lvXXX raw volume to a symbolic-link in /opt/Informix/dev/XXXXX file? I have the following on my IDS server: CHUNKS FOR root Chunk Chunk Pages Pages Full Pathname of Chunk Status Id Offset In Chunk Used 1 0 4194304 34982 /dev/mapper/vg02-lvroot.1 PO-B 1 0 4194304 4194304 /dev/mapper/vg01-lvroot.1m MO-B I want to change the chunk to point to /opt/Informix/dev/rootdbs --> /dev/mapper/vg02-lvroot.1 My reason for this is a new HDR Secondary using "ontape -p" won't have the same storage layout and I'm transitioning from RAW disk to cooked file-system (EXT2) on my new secondary. Then the new secondary will be converted to the HDR Primary and the old Primary will be shut-down and retired. Changing dbspace chunks to symbolic links on the old HDR primary would be a big help. Will this work in your experience / opinion? TIA for any insight. V/r, Jonathan B. Smaby Pomona College (909) 621-8506 -- "If people stop bringing you problems, you've stopped leading." - LTG Jeffrey W. Talley, US Army Reserve

Hi, you cannot set up a HDR secondary with different chunk layout. The server will not accept this. The reason is that a primary instance of a HDR pair has to add a chunk and the secondary will do this on the other side in the same way (the same path has to exist). Maybe you can try moving the chunks of the old instance using external restore. This might work. You should shut down the instance, make symbolic links to the old devices and start the engine using ontape -p -e -rename -f <mapfile> onmode -m where mapfile contains the mapping for all your chunks to the new location. Then, you could setup a HDR secondary which then has files instead of the links (create using touch, don't forget chown/chmod). Wait til it is in sync and then switch roles as proposed. Try it on a non-productive instance before ... no assurance that this will really work ... Just an idea which I didn't try before. Hope this helps, Marcus Haarmann ----- Ursprüngliche Mail ----- Von: "Jonathan Smaby" <Jonathan.Smaby@pomona.edu> An: ids@iiug.org Gesendet: Dienstag, 13. Mai 2014 20:38:29 Betreff: Changes dbspace path without having to drop & .... [33009] Good afternoon, I've got a situation where I need to use symbolic-links to DB spaces instead of a hard-path on a Linux based Informix server. Will onspaces allow me to gracefully re-point a DBspace chunk from /dev/mapper/lvXXX raw volume to a symbolic-link in /opt/Informix/dev/XXXXX file? I have the following on my IDS server: CHUNKS FOR root Chunk Chunk Pages Pages Full Pathname of Chunk Status Id Offset In Chunk Used 1 0 4194304 34982 /dev/mapper/vg02-lvroot.1 PO-B 1 0 4194304 4194304 /dev/mapper/vg01-lvroot.1m MO-B I want to change the chunk to point to /opt/Informix/dev/rootdbs --> /dev/mapper/vg02-lvroot.1 My reason for this is a new HDR Secondary using "ontape -p" won't have the same storage layout and I'm transitioning from RAW disk to cooked file-system (EXT2) on my new secondary. Then the new secondary will be converted to the HDR Primary and the old Primary will be shut-down and retired. Changing dbspace chunks to symbolic links on the old HDR primary would be a big help. Will this work in your experience / opinion? TIA for any insight. V/r, Jonathan B. Smaby Pomona College (909) 621-8506 -- "If people stop bringing you problems, you've stopped leading." - LTG Jeffrey W. Talley, US Army Reserve ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Jonathan: The only way to do this is to use a redirected restore from ontape or onbar to restore the chunks to different paths than the ones listed in the archive file(s). Step: 1. Take an archive. 2. Bring the server down to single user mode. 3. Force a checkpoint. 4. Archive any logical logs not yet backed up (including the current partial log) 5. Shutdown the engine. 6. Restore the archive with onbar -r -rename or ontape -r -rename Note that if you are renaming the root chunk's path do not change the path in the ONCONFIG file, onbar/ontape will take care of that for you. Art Art S. Kagel, Principal Consultant ASK Database Management Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, May 13, 2014 at 2:38 PM, Jonathan Smaby <Jonathan.Smaby@pomona.edu>wrote: > Good afternoon, > > I've got a situation where I need to use symbolic-links to DB spaces > instead > of a hard-path on a Linux based Informix server. Will onspaces allow me to > gracefully re-point a DBspace chunk from /dev/mapper/lvXXX raw volume to a > symbolic-link in /opt/Informix/dev/XXXXX file? > > I have the following on my IDS server: > > CHUNKS FOR root > > Chunk Chunk Pages Pages Full Pathname of Chunk Status > Id Offset In Chunk Used > > 1 0 4194304 34982 /dev/mapper/vg02-lvroot.1 PO-B > > 1 0 4194304 4194304 /dev/mapper/vg01-lvroot.1m MO-B > > I want to change the chunk to point to /opt/Informix/dev/rootdbs --> > /dev/mapper/vg02-lvroot.1 > > My reason for this is a new HDR Secondary using "ontape -p" won't have the > same storage layout and I'm transitioning from RAW disk to cooked > file-system > (EXT2) on my new secondary. Then the new secondary will be converted to the > HDR Primary and the old Primary will be shut-down and retired. Changing > dbspace chunks to symbolic links on the old HDR primary would be a big > help. > > Will this work in your experience / opinion? > > TIA for any insight. > > V/r, > > Jonathan B. Smaby > Pomona College > (909) 621-8506 > -- > "If people stop bringing you problems, you've stopped leading." - LTG > Jeffrey > W. Talley, US Army Reserve > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0141a9aa72029904f94dacb7

Hmm, interesting Marcus. I hadn't thought to try using external restore with -rename. That would be a timesaver if it works. Art Art S. Kagel, Principal Consultant ASK Database Management Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, May 13, 2014 at 3:49 PM, Marcus Haarmann <marcus.haarmann@midoco.de>wrote: > Hi, > > you cannot set up a HDR secondary with different chunk layout. > The server will not accept this. > The reason is that a primary instance of a HDR pair has to add a > chunk and the secondary will do this on the other side in the same > way (the same path has to exist). > > Maybe you can try moving the chunks of the old instance using external > restore. > This might work. > You should shut down the instance, make symbolic links to the > old devices and start the engine using > ontape -p -e -rename -f <mapfile> > onmode -m> > where mapfile contains the mapping for all your chunks to the new location. > Then, you could setup a HDR secondary which then has files instead of the > links > (create using touch, don't forget chown/chmod). Wait til it is in sync and > then switch > roles as proposed. > > Try it on a non-productive instance before ... no assurance that this will > really work ... > Just an idea which I didn't try before. > > Hope this helps, > > Marcus Haarmann > > ----- Ursprüngliche Mail ----- > > Von: "Jonathan Smaby" <Jonathan.Smaby@pomona.edu> > An: ids@iiug.org > Gesendet: Dienstag, 13. Mai 2014 20:38:29 > Betreff: Changes dbspace path without having to drop & .... [33009] > > Good afternoon, > > I've got a situation where I need to use symbolic-links to DB spaces > instead > of a hard-path on a Linux based Informix server. Will onspaces allow me to > gracefully re-point a DBspace chunk from /dev/mapper/lvXXX raw volume to a > symbolic-link in /opt/Informix/dev/XXXXX file? > > I have the following on my IDS server: > > CHUNKS FOR root > > Chunk Chunk Pages Pages Full Pathname of Chunk Status > Id Offset In Chunk Used > > 1 0 4194304 34982 /dev/mapper/vg02-lvroot.1 PO-B > > 1 0 4194304 4194304 /dev/mapper/vg01-lvroot.1m MO-B > > I want to change the chunk to point to /opt/Informix/dev/rootdbs --> > /dev/mapper/vg02-lvroot.1 > > My reason for this is a new HDR Secondary using "ontape -p" won't have the > same storage layout and I'm transitioning from RAW disk to cooked > file-system > (EXT2) on my new secondary. Then the new secondary will be converted to the > HDR Primary and the old Primary will be shut-down and retired. Changing > dbspace chunks to symbolic links on the old HDR primary would be a big > help. > > Will this work in your experience / opinion? > > TIA for any insight. > > V/r, > > Jonathan B. Smaby > Pomona College > (909) 621-8506 > -- > "If people stop bringing you problems, you've stopped leading." - LTG > Jeffrey > W. Talley, US Army Reserve > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11346ddee0a5e004f94dc53e

I=92ve used the restore -rename quite successfully. There are some = things to watch out for. Hmmm, here is my writeup specific to our = Windows environment, but the same things should apply: Informix backups expect to be restored to the database from which they = were made, however it is possible to rename the backup files as part of = the restore. To accomplish this we need to make a file listing all of = the dataspace files from production that we want to rename during the = restore. This file will look like: D:\\\\IFMXDATA\\\\cvp_db_PRODUCTION\\\\rootdbs_dat.000 0 = E:\\\\IFMXDATA\\\\cvp_db_BACKUP\\\\rootdbs_dat.000 0 D:\\\\IFMXDATA\\\\cvp_db_PRODUCTION\\\\cvp_prim_dat.000 0 = E:\\\\IFMXDATA\\\\cvp_db_BACKUP\\\\cvp_prim_dat.000 0 D:\\\\IFMXDATA\\\\cvp_db_PRODUCTION\\\\sbspace_dat.000 0 = E:\\\\IFMXDATA\\\\cvp_db_BACKUP\\\\sbspace_dat.000 0 D:\\\\ifmxdata\\\\cvp_db_PRODUCTION\\\\cvp_temp_dat.000 0 = E:\\\\ifmxdata\\\\cvp_db_BACKUP\\\\cvp_temp_dat.000 0 D:\\\\ifmxdata\\\\cvp_db_PRODUCTION\\\\cvp_plog_dat.000 0 = E:\\\\ifmxdata\\\\cvp_db_BACKUP\\\\cvp_plog_dat.000 0 D:\\\\ifmxdata\\\\cvp_db_PRODUCTION\\\\cvp_data_dat.000 0 = E:\\\\ifmxdata\\\\cvp_db_BACKUP\\\\cvp_data_dat.000 0 Where the drive letters will match the respective PRODUCTION and BACKUP = servers and where the names PRODUCTION and BACKUP will replaced by the = respective production and backup reporting server names. The full path = where these data files reside is specified in the %INFORMIXDATA% = environment variable on each server. Let us call this file rename.txt = and put it into the same location as the cvp_backup_data file. (Side = note, the "0" after each file name is the offset into the file where the = data starts, it is typically unsused and hence set to 0). Finally, during the restore, Informix will expect to have a = configuration file which points to the data files as listed on the = production server. Therefore we will change the following line in = %INFORMIXDIR%\\\\etc\\\\%ONCONFIG%: From: ROOTPATH E:\\\\IFMXDATA\\\\cvp_db_BACKUP\\\\rootdbs_dat.000 # Path = for device containing root dbspace To: ROOTPATH D:\\\\IFMXDATA\\\\cvp_db_PRODUCTION\\\\rootdbs_dat.000 # Path = for device containing root dbspace Again replacing the words PRODUCTION and BACKUP by the respective = production and backup reporting server names. NOTE: All of these file names are case sensitive. If the case does not = match exactly, there will be an error during the restore that either a = source or destination file could not be located. At this juncture we are ready to perform the actual restore. This procedure involves shutting down the Informix server, performing = the restore, then bringing the server back into multi-user mode. The restore process has a number of options to allow incremental backups = to be restored on top of the restore we have performed or to handle = logical logs either before or after the restore, we will not be doing = any of that. In a Command window (Start->Run->cmd): cd %INFORMIXBACKUP%\\\\cvp_db_backup (Our cvp_backup_data and rename.txt files are here) (Shutdown the Informix server) onmode -yuk (Start the restore) ontape -r -rename -f rename.txt (where rename.txt is the =name of our rename file) The backup file will be read and a series of questions asked - is this = the backup you want to restore? As well as: 1. "y" to continue 2. "n" to backup logs 3. "n" level 1 archive 4. "n" log tapes After the restore is complete the Informix server should be in Quiescent = mode. This can be determined by issuing the following command: onstat - This can be repeated until the server is observed to be in quiescent = mode as which point it can be brought into multi-user mode and made = available to users with the following command: onmode -m At this juncture the engine should be available for use with data as of = the date of the backup which was applied. On May 13, 2014, at 4:19 PM, Art Kagel <art.kagel@gmail.com> wrote: > Hmm, interesting Marcus. I hadn't thought to try using external = restore=20 > with -rename. That would be a timesaver if it works.=20 >=20 > Art=20 >=20 > Art S. Kagel, Principal Consultant=20 > ASK Database Management=20 >=20 > Blog: http://informix-myview.blogspot.com/=20 >=20 > Disclaimer: Please keep in mind that my own opinions are my own = opinions=20 > and do not reflect on the IIUG, nor any other organization with which = I am=20 > associated either explicitly, implicitly, or by inference. Neither do=20= > those opinions reflect those of other individuals affiliated with any=20= > entity with which I am affiliated nor those of the entities = themselves.=20 >=20 > On Tue, May 13, 2014 at 3:49 PM, Marcus Haarmann=20 > <marcus.haarmann@midoco.de>wrote:=20 >=20 >> Hi,=20 >>=20 >> you cannot set up a HDR secondary with different chunk layout.=20 >> The server will not accept this.=20 >> The reason is that a primary instance of a HDR pair has to add a=20 >> chunk and the secondary will do this on the other side in the same=20 >> way (the same path has to exist).=20 >>=20 >> Maybe you can try moving the chunks of the old instance using = external=20 >> restore.=20 >> This might work.=20 >> You should shut down the instance, make symbolic links to the=20 >> old devices and start the engine using=20 >> ontape -p -e -rename -f <mapfile>=20 >> onmode -m=20 >>=20>> where mapfile contains the mapping for all your chunks to the new = location.=20 >> Then, you could setup a HDR secondary which then has files instead of = the=20 >> links=20 >> (create using touch, don't forget chown/chmod). Wait til it is in = sync and=20 >> then switch=20 >> roles as proposed.=20 >>=20 >> Try it on a non-productive instance before ... no assurance that this = will=20 >> really work ...=20 >> Just an idea which I didn't try before.=20 >>=20 >> Hope this helps,=20 >>=20 >> Marcus Haarmann=20 >>=20 >> ----- Urspr=FCngliche Mail -----=20 >>=20 >> Von: "Jonathan Smaby" <Jonathan.Smaby@pomona.edu>=20 >> An: ids@iiug.org=20 >> Gesendet: Dienstag, 13. Mai 2014 20:38:29=20 >> Betreff: Changes dbspace path without having to drop & .... [33009]=20= >>=20 >> Good afternoon,=20 >>=20 >> I've got a situation where I need to use symbolic-links to DB spaces=20= >> instead=20 >> of a hard-path on a Linux based Informix server. Will onspaces allow = me to=20 >> gracefully re-point a DBspace chunk from /dev/mapper/lvXXX raw volume = to a=20 >> symbolic-link in /opt/Informix/dev/XXXXX file?=20 >>=20 >> I have the following on my IDS server:=20 >>=20 >> CHUNKS FOR root=20 >>=20 >> Chunk Chunk Pages Pages Full Pathname of Chunk Status=20 >> Id Offset In Chunk Used=20 >>=20 >> 1 0 4194304 34982 /dev/mapper/vg02-lvroot.1 PO-B=20 >>=20 >> 1 0 4194304 4194304 /dev/mapper/vg01-lvroot.1m MO-B=20 >>=20 >> I want to change the chunk to point to /opt/Informix/dev/rootdbs -->=20= >> /dev/mapper/vg02-lvroot.1=20 >>=20 >> My reason for this is a new HDR Seconda