Relocate Informix database from Raw slices to filesystem

Is there any way I can relocate my IDS 7.31 database from its raw slices to the local filesystem...? I can 'dd' the slices to files easily, but I need a way of telling Informix the new location of the chunks. This seems straigtforward for the rootdbs (which is defined in onconfig), but what about the other chunks..? I want to avoid unloading and reloading the data. All I want to do is move the physical chunks.. onstat -d: Informix Dynamic Server Version 7.31.UC5 -- On-Line -- Up 2 days 14:38:28 -- 40768 Kbytes Dbspaces address number flags fchunk nchunks flags owner name c04a150 1 1 1 1 N informix rootdbs c04a618 2 1 2 1 N informix logicdbs c04a6d8 3 1 3 1 N informix procdbs 3 active, 2047 maximum Chunks address chk/dbs offset size free bpages flags pathname c04a210 1 1 50 400000 278361 PO- /dev/rdsk/c1t6d0s4 c04a458 2 2 50 200000 134867 PO- /dev/rdsk/c1t6d0s5 c04a538 3 3 50 400000 347171 PO- /dev/rdsk/c1t6d0s6 Any help appreciated... Matt

mccmx@hotmail.com wrote: > Is there any way I can relocate my IDS 7.31 database from its raw > slices to the local filesystem...? > > I can 'dd' the slices to files easily, but I need a way of telling > Informix the new location of the chunks. > > This seems straigtforward for the rootdbs (which is defined in > onconfig), > but what about the other chunks..? Matt, This is why I always recommend that one use links for chunks paths and NEVER use the actual device or file paths! If you had done so, you would just have to shutdown, copy the chunks, relink the links and poof! However, that said, WHY would you want to move your data from fast safe RAW chunks into far slower (25-40% slower) and fumble finger accessible FS files? This I also recommend against! Art S. Kagel > I want to avoid unloading and reloading the data. All I want to do is > move the physical chunks.. > > onstat -d:> > Informix Dynamic Server Version 7.31.UC5 -- On-Line -- Up 2 days > 14:38:28 -- > 40768 Kbytes > > Dbspaces > address number flags fchunk nchunks flags owner name > c04a150 1 1 1 1 N informix rootdbs > c04a618 2 1 2 1 N informix logicdbs > c04a6d8 3 1 3 1 N informix procdbs > 3 active, 2047 maximum > > Chunks > address chk/dbs offset size free bpages flags pathname > c04a210 1 1 50 400000 278361 PO- /dev/rdsk/c1t6d0s4 > c04a458 2 2 50 200000 134867 PO- /dev/rdsk/c1t6d0s5 > c04a538 3 3 50 400000 347171 PO- /dev/rdsk/c1t6d0s6 > > Any help appreciated... > > Matt >

> This is why I always recommend that one use links for chunks paths and NEVER > use the actual device or file paths! If you had done so, you would just > have to shutdown, copy the chunks, relink the links and poof! I wish someone had actually done this, life would be so much easier.....! > However, that said, WHY would you want to move your data from fast safe RAW > chunks into far slower (25-40% slower) and fumble finger accessible FS > files? This I also recommend against! I don't neccesarily need to move them off raw slices, but I do need to move them to different slices. This is because I am moving the database from SAN storage to internal disks... So ultimately /dev/rdsk/c1d6d0s4 (and s5 and s6) wont exist anymore. So I need a way of relocating the data to a new slice or a filesystem file. I suspect the process will be the same either way. Is it possible without using onunload/onload...? Cheers Matt

mccmx@hotmail.com wrote: >>This is why I always recommend that one use links for chunks paths and NEVER >>use the actual device or file paths! If you had done so, you would just >>have to shutdown, copy the chunks, relink the links and poof! > > > I wish someone had actually done this, life would be so much > easier.....! > > >>However, that said, WHY would you want to move your data from fast safe RAW >>chunks into far slower (25-40% slower) and fumble finger accessible FS >>files? This I also recommend against! > > > I don't neccesarily need to move them off raw slices, but I do need to > move them to different slices. This is because I am moving the > database from SAN storage to internal disks... So ultimately > /dev/rdsk/c1d6d0s4 (and s5 and s6) wont exist anymore. > > So I need a way of relocating the data to a new slice or a filesystem > file. I suspect the process will be the same either way. > > Is it possible without using onunload/onload...? > > Cheers > > Matt > mirroring ?

Mirroring ..? Can you clarify what you mean...? At what level..? Matt

mccmx@hotmail.com wrote: > > I don't neccesarily need to move them off raw slices, but I do need to > move them to different slices. This is because I am moving the > database from SAN storage to internal disks... So ultimately > /dev/rdsk/c1d6d0s4 (and s5 and s6) wont exist anymore. > > So I need a way of relocating the data to a new slice or a filesystem > file. I suspect the process will be t > You can, in an unsupported environment, binary edit the rootdbs as the path to the other chunks is held there

I suspect from your answer that there isn't a supported way of doing this in Informix...is there??? This is a production server so I don't fancy giving this a try.. Cheers Matt

mccmx@hotmail.com wrote: > Mirroring ..? > > Can you clarify what you mean...? At what level..? > > Matt Use informix mirroring. create the new device to which you wish to migrate (and use links this time) as a mirror of your device and then break the old link later. Dualta.

Clive Eisen wrote: > mccmx@hotmail.com wrote: > >> >> I don't neccesarily need to move them off raw slices, but I do need to >> move them to different slices. This is because I am moving the >> database from SAN storage to internal disks... So ultimately >> /dev/rdsk/c1d6d0s4 (and s5 and s6) wont exist anymore. >> >> So I need a way of relocating the data to a new slice or a filesystem >> file. I suspect the process will be t >> > You can, in an unsupported environment, binary edit the rootdbs > as the path to the other chunks is held there But the new paths would need to have the same length... That's why you should never use physical names. Always use symbolic links to the real devices... In this circunstances I don't see how an unload/reload can be avoided... Regards.

Do you mean through onspaces..? Matt

mccmx@hotmail.com wrote: > Do you mean through onspaces..? > > Matt > Yup.

Do you mean through onspaces..? Matt

Thats sounds promising. So effectively add a mirrored chunk to each dbspace using onspaces and then drop the original chunk. Can you do this for the rootdbs dbspace too...? Matt

<mccmx@hotmail.com> wrote in message news:1129561344.240798.314750@g49g2000cwa.googlegroups.com... > Thats sounds promising. > > So effectively add a mirrored chunk to each dbspace using onspaces and > then drop the original chunk. > > Can you do this for the rootdbs dbspace too...? > > Matt > If it's a production system you might be better off paying someone who knows what they're doing to do this for you. -- Neil Truby t:01932 724027 Director m:07798 811708 Ardenta Limited e:neil.truby@ardenta.com

mccmx@hotmail.com wrote: > Thats sounds promising. > > So effectively add a mirrored chunk to each dbspace using onspaces and > then drop the original chunk. > > Can you do this for the rootdbs dbspace too...? > > Matt > Should do. The only thing you might not want is references left to the dropped mirrors and if you want to turn on mirroring for devices at a later date then you might want to tidy that up. This can be fixed by bouncing the server and swapping the references to the chunks when the server is down so that you can drop the reference cleanly Note Neil's warning though about production servers. It can be easy to make a mistake when you are not familiar with this stuff. A misplaced chunk name and you could easily mess things up. Good fun though. Dualta.

> > But the new paths would need to have the same length... > That's why you should never use physical names. Always use symbolic > links to the real devices... Never heard of that, but there is a limitation in max. lenght of chrakters in pathname.