IDS Forum

Re: Changes dbspace path without having to dro....

Posted By: Jack Parker
Date: Tuesday, 13 May 2014, at 4:29 p.m.

In Response To: Re: Changes dbspace path without having to dro.... (Art Kagel)

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 Secondary using "ontape -p" won't =
have the=20
>> same storage layout and I'm transitioning from RAW disk to cooked=20
>> file-system=20
>> (EXT2) on my new secondary. Then the new secondary will be converted =
to the=20
>> HDR Primary and the old Primary will be shut-down and retired. =
Changing=20
>> dbspace chunks to symbolic links on the old HDR primary would be a =
big=20
>> help.=20
>>=20
>> Will this work in your experience / opinion?=20
>>=20
>> TIA for any insight.=20
>>=20
>> V/r,=20
>>=20
>> Jonathan B. Smaby=20
>> Pomona College=20
>> (909) 621-8506=20
>> --=20
>> "If people stop bringing you problems, you've stopped leading." - LTG=20=

>> Jeffrey=20
>> W. Talley, US Army Reserve=20
>>=20
>>=20
>>=20
>>=20
> =
**************************************************************************=
*****=20
>> Forum Note: Use "Reply" to post a response in the discussion forum.=20=

>>=20
>>=20
>>=20
>>=20
> =
**************************************************************************=
*****=20
>> Forum Note: Use "Reply" to post a response in the discussion forum.=20=

>>=20
>>=20
>=20
> --001a11346ddee0a5e004f94dc53e=20
>=20
>=20
> =
**************************************************************************=
*****=20
> Forum Note: Use "Reply" to post a response in the discussion forum.=20=

>=20

Messages In This Thread

• Changes dbspace path without having to drop & re-a
  Jonathan Smaby -- Tuesday, 13 May 2014, at 2:38 p.m.
  • Re: Changes dbspace path without having to drop &
    Marcus Haarmann -- Tuesday, 13 May 2014, at 3:49 p.m.
    • Re: Changes dbspace path without having to dro....
      Art Kagel -- Tuesday, 13 May 2014, at 4:19 p.m.
      • Re: Changes dbspace path without having to dro....
        Jack Parker -- Tuesday, 13 May 2014, at 4:29 p.m.
  • Re: Changes dbspace path without having to drop &
    Art Kagel -- Tuesday, 13 May 2014, at 4:11 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.