moving the rootdbs chunk

Does ROOTPATH point to the chunk itself, or a link to the chunk? If it points directly to it, I don't believe you can move the rootdbs chunk except by scrapping the server, re-building it and re-loading the databases. If a link, you can break the link, move the data with dd, then create the link to the new location. Neil wisse wrote in message <36F82434.68DA8EFA@kabelfoon.nl>... What is the best way to move the rootdbs chunk. I want to move the rootdbs chunk, it has only one chunk. What is the best, safest way to do this. Recreating the Inormix instance and restoring the databases is not an option because that takes to long. Dumping the volume (disk partition) of the chunk and restoring to another volume and renaming the volumes is an option but I am a little bit concerned about the risks like tape can't be read

wisse wrote: > > What is the best way to move the rootdbs chunk. > > I want to move the rootdbs chunk, it has only one chunk. What is the > best, safest way to do this. Recreating the Inormix instance and > restoring the databases is not an option because that takes to long. > Dumping the volume (disk partition) of the chunk and restoring to > another volume and renaming the volumes is an option but I am a > little bit concerned about the risks like tape can't be read > > It should be nice to be able to create a second Informix instance and > to copy the dbspaces, ... information from the first Informix instance > to the second Informix instance. Testing the new instance and if oke > killing the first instance. If the root chunk is a link, break the link, copy the disk to a new disk, recreate the link to point to the new disk, restart the engine. If the root chunk is a hard device/file then shame on you, you did not read the manual ;-) Anyway, rename the device/file, copy the data to the new disk, create a link pointing to the new disk but named after the old disk. Depending on your OS you may have to place the commands to rename the device and create the link into the rc scripts. Many UNIXes, for example DGUX, create the device files everytime the system boots which will overwrite the link. Did I mention you should backup the engine and shut it down before you do anything else? Consider it mentioned. Art S. Kagel

What is the best way to move the rootdbs chunk. I want to move the rootdbs chunk, it has only one chunk. What is the best, safest way to do this. Recreating the Inormix instance and restoring the databases is not an option because that takes to long. Dumping the volume (disk partition) of the chunk and restoring to another volume and renaming the volumes is an option but I am a little bit concerned about the risks like tape can't be read It should be nice to be able to create a second Informix instance and to copy the dbspaces, ... information from the first Informix instance to the second Informix instance. Testing the new instance and if oke killing the first instance. Albert H. Wisse

Art, I have read the manual and the root chunk isn't a hard device. It is a volume created with a volume manager. The volume manager keeps the volumes consistent with the hard devices, even after /dev is reorganized. I will close this discussion from my site now. I have enough input to move the root chunk safely. I thank all persons contributed to this. Regards, Albert Wisse "Art S. Kagel" wrote: > wisse wrote: > > > > What is the best way to move the rootdbs chunk. > > > > I want to move the rootdbs chunk, it has only one chunk. What is the > > best, safest way to do this. Recreating the Inormix instance and > > restoring the databases is not an option because that takes to long. > > Dumping the volume (disk partition) of the chunk and restoring to > > another volume and renaming the volumes is an option but I am a > > little bit concerned about the risks like tape can't be read > > > > It should be nice to be able to create a second Informix instance and > > to copy the dbspaces, ... information from the first Informix instance > > to the second Informix instance. Testing the new instance and if oke > > killing the first instance. > > If the root chunk is a link, break the link, copy the disk to a new > disk, recreate the link to point to the new disk, restart the engine. > > If the root chunk is a hard device/file then shame on you, you did not > read the manual ;-) Anyway, rename the device/file, copy the data to > the new disk, create a link pointing to the new disk but named after > the old disk. Depending on your OS you may have to place the commands > to rename the device and create the link into the rc scripts. Many > UNIXes, for example DGUX, create the device files everytime the system > boots which will overwrite the link. > > Did I mention you should backup the engine and shut it down before you > do anything else? Consider it mentioned. > > Art S. Kagel

Neil Truby wrote in message <7d8d2s$kdb$1@taliesin.netcom.net.uk>... >If a link, you can break the link, move the data with dd, then create the >link to the new location. > QUESTION: If you use unix dd to move the data, won't it be moved as a disk image, that is byte by byte? If that is so, wouldn't the partition table (tablespace tablespace) be corrupted? Why? Because the first page of the tablespace tablespace is the bitmap page for the tablespace tablespace itself. The partition pages for all other tablespaces (one for each) immediately follow. The first of these partition pages (second page of tablespace tablespace) is the partition page for the tablespace tablespace itself. All partition pages point to the bitmap page of their respective tablespace. Thus, the second page in the tablespace tablespace (being the partition page for the tablespace tablespace itself) points to the first page in the tablespace tablespace (being the bitmap page for the tablespace tablespace). Now if I move the entire tablespace tablespace to another location without changing the contents of its partition page, won't it (the partition page) still be pointing to the location that was originally the bitmap page (before the move)? So, the partition page (of the tablespace tablespace) would no longer be pointing to the bitmap page (of the tablespace tablespace). Is there an error in my thinking? If it is correct, wouldn't there be a big problem doing a byte image copy of any tablespace tablespace (and thus in particular the rootdbs)? Look forward to corrections or comments. David Grove

On Thu, 1 Apr 1999 16:25:48 -0900, "David Grove" <david_grove@health.state.ak.us> wrote: >QUESTION: If you use unix dd to move the data, won't it be moved as a disk >image, that is byte by byte? If that is so, wouldn't the partition table >(tablespace tablespace) be corrupted? Why? Because the first page of the >tablespace tablespace is the bitmap page for the tablespace tablespace >itself. The partition pages for all other tablespaces (one for each) >immediately follow. The first of these partition pages (second page of >tablespace tablespace) is the partition page for the tablespace tablespace >itself. All partition pages point to the bitmap page of their respective >tablespace. Thus, the second page in the tablespace tablespace (being the >partition page for the tablespace tablespace itself) points to the first >page in the tablespace tablespace (being the bitmap page for the tablespace >tablespace). Now if I move the entire tablespace tablespace to another >location without changing the contents of its partition page, won't it (the >partition page) still be pointing to the location that was originally the >bitmap page (before the move)? So, the partition page (of the tablespace >tablespace) would no longer be pointing to the bitmap page (of the >tablespace tablespace). > >Is there an error in my thinking? If it is correct, wouldn't there be a big >problem doing a byte image copy of any tablespace tablespace (and thus in >particular the rootdbs)? There is an error in your thinking. Using dd, you'd move the entire contents of the chunk, not just the tblspace tblspace. All the references mentioned are based upon the relative position of the page in the chunk. So the 5th page in the chunk, for example, is still the same after the dd. It happens to be on a different device, but that doesn't matter because it is the relative location that matters. So your example partition page is pointing to the Xth page in the chunk, which was copied over along with the rest of the data. Dave