Re: Relocate Informix database from Raw slices to filesystem
Posted in 2005
Topics: Backup & Restore, Storage & Space Management, Platform-Specific Issues, Versions, Editions & End-of-Life
True there are issues but it's a easy solution to the problem, gets round
the 'can not rename chunks' issue, no need to hassle about mirroring etc
But the original post said going to internal disks so there will not be a
name clash.
On 10/17/05, Paul Watson <pwatson@irace.com> wrote:
>
> On 17 Oct 2005 15:26:36 -0700, david@smooth1.co.uk <david@smooth1.co.uk>
> wrote:
> >
> >
> > Paul Watson wrote:
> > > If the device is 'not going to exist anymore' why not dd the data from
> > the
> > > old slice to the internal disk and then
> > > just link the 'not going to exist anymore device' to the new location
> > >
> > >
> >
> >
> > I'm guess this a Solaris platform..and then someone runs devfsadm that
> > rebuilds /dev and removes your links!
> >
> > Or someone adds a new device and Solaris wants to use that name!
> >
> > Bad idea to store stuff under /dev. That directory is for the OS
> > to control not you.
> >
> > If you are running on IDS 9.40 or IDS 10 then ontape has the ability to
> > rename chunks during a restore.
> >
> > http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0405fan/
> >
> >
> >
>
>
> --
> Paul Watson
> Tel: +44 7818 003457
> Fax: +44 1436 678693
>
--
Paul Watson
Tel: +44 7818 003457
Fax: +44 1436 678693
sending to informix-list
Funnily enough, your idea to create a soft link in /dev from the old device to the new device/location is exactly what I was planning to do if I couldn't find a 'better' solution. Based on this thread, I may well have to go down that route... My Informix knowledge is very limited....!?! What I will probably do is: 1. create the soft link from /dev to get informix up and running on a different machine. 2. On this new machine: Add a mirror chunk to each dbspace and drop the original mirror to effectively relocate the databse to the filesystem. If I have no joy with step 2, I will run with the soft link from /dev. This will have to be documented well so that if someone destroys /dev (through devfsadm or similar) then the links can be recreated easily. Its not ideal but its preferable to unloading and reloading the whole database, which has its own risks. Thanks for the advice.. Matt
Funnily enough, your idea to create a soft link in /dev from the old device to the new device/location is exactly what I was planning to do if I couldn't find a 'better' solution. Based on this thread, I may well have to go down that route... My Informix knowledge is very limited....!?! What I will probably do is: 1. create the soft link from /dev to get informix up and running on a different machine. 2. On this new machine: Add a mirror chunk to each dbspace and drop the original mirror to effectively relocate the databse to the filesystem. If I have no joy with step 2, I will run with the soft link from /dev. This will have to be documented well so that if someone destroys /dev (through devfsadm or similar) then the links can be recreated easily. Its not ideal but its preferable to unloading and reloading the whole database, which has its own risks. Thanks for the advice.. Matt
Funnily enough, your idea to create a soft link in /dev from the old device to the new device/location is exactly what I was planning to do if I couldn't find a 'better' solution. Based on this thread, I may well have to go down that route... My Informix knowledge is very limited....!?! What I will probably do is: 1. create the soft link from /dev to get informix up and running on a different machine. 2. On this new machine: Add a mirror chunk to each dbspace and drop the original mirror to effectively relocate the databse to the filesystem. If I have no joy with step 2, I will run with the soft link from /dev. This will have to be documented well so that if someone destroys /dev (through devfsadm or similar) then the links can be recreated easily. Its not ideal but its preferable to unloading and reloading the whole database, which has its own risks. Thanks for the advice.. Matt