Restore to different chunk-paths?

We have several informix-instances on the same machinie, our (raw) chunks (links) are placed in different places for each instance in $INFORMIXDIR/idb_xxx -The name of dbspaces are the same. Now I would like to restore my level-0 (ontape) archive from a instance using $INFORMIXDIR/idb_prod to a instance using $INFORMIXDIR/idb_tst1 as chunk-path ontape -r gives me a list of dbscapces to be restored, specifying chunks with idb_prod... Neither ontape nor onarchie seems to have options for dbspace/chunk redirection, and dbexport is probably a little to slow for my use (14GB database, to be copied frequently). Is onload/onunload the best bet or is dbimport/export ok? onload should be faster, but it corrupts fragmented indexes so we must drop them and then it's probably as slow as dbexport/import? Thomas

The overall answer is NO you cannot do what you are asking. However, if you were to have used relative link paths in your initial setup you would be able to accomplish a very quick copy of your database instance. The following will only work if you use relative links, because the chunk path is stored in the informix reserve pages, which are stored in rootdbs. Now I will try to explain this: First there is a bug in onspaces that will not allow you to enter chunks with relative spaces names so you will have to use onmonitor. Yeah, yeah, I know no one uses onmonitor, but the benefit far outweighs its use. 1. create your links in a directory ln -l /dev/volgrp1/fdsk_01 /informixlinks/inst01/chunk_01 ln -l /dev/volgrp1/fdsk_02 /informixlinks/inst01/chunk_02 ...and so on 2. cd to your link directory /informixlinks/inst01 3. setup your instance using only the chunk name not the full path rootdbs chunk_01 4. initialize the engine (you must be in the your device directory; in this example /informixlinks/inst01/ 5. use onmonitor to setup the rest of you dbspaces (again pwd is /informixlinks/inst01) use only the chunk name not the full path Note: you must cd to your device directory (/informixlinks/inst01/) to start up the engine Now, if you want to duplicate the engine 1. create your links in a directory ln -l /dev/volgrp1/fdsk_01 /informixlinks/inst02/chunk_01 ln -l /dev/volgrp1/fdsk_02 /informixlinks/inst02/chunk_02 ...and so on 2. either stop the inst01 instance or onmode -c block 3. use dd to copy the raw disks from inst01 to the raw disks of inst02 4. bring up inst01 or omode -c unblock 5. copy onconfig from inst01 to inst02 changing one the DBSERVERNAME DBSERVERALIASES SERVERNUM Note: other parmeters may need to be changed if the size of the instance needs to be different you will also need to add the new instance to sqlhosts 6. cd to /informixlinks/inst02/ 7 bring up inst02 This is not just theory I am using this in pratice and is works great. Hopefully this provides some idea on how you can copy and instance without using backups and tapes. Greg Thomas Parsli wrote: > We have several informix-instances on the same machinie, our (raw) chunks (links) > are placed in different places for each instance in $INFORMIXDIR/idb_xxx > -The name of dbspaces are the same. > > Now I would like to restore my level-0 (ontape) archive from a instance > using $INFORMIXDIR/idb_prod to a instance using $INFORMIXDIR/idb_tst1 as chunk-path > > ontape -r gives me a list of dbscapces to be restored, specifying chunks with idb_prod...> > Neither ontape nor onarchie seems to have options for dbspace/chunk redirection, > and dbexport is probably a little to slow for my use (14GB database, to be copied > frequently). > > Is onload/onunload the best bet or is dbimport/export ok? > onload should be faster, but it corrupts fragmented indexes so we must drop them > and then it's probably as slow as dbexport/import? > > Thomas

You must use onunload/onload or dbexport/dbimport as you guessed. Either that or build the database in the new server manually and copy the data directly from instance to instance using something like my dbcopy.ec utility. BTW relative pathname for chunks is a really attractive and a really bad idea. There are more worms in that can than can. Art S. Kagel Thomas Parsli wrote: > > We have several informix-instances on the same machinie, our (raw) chunks (links) > are placed in different places for each instance in $INFORMIXDIR/idb_xxx > -The name of dbspaces are the same. > > Now I would like to restore my level-0 (ontape) archive from a instance > using $INFORMIXDIR/idb_prod to a instance using $INFORMIXDIR/idb_tst1 as chunk-path > > ontape -r gives me a list of dbscapces to be restored, specifying chunks with idb_prod...> > Neither ontape nor onarchie seems to have options for dbspace/chunk redirection, > and dbexport is probably a little to slow for my use (14GB database, to be copied > frequently). > > Is onload/onunload the best bet or is dbimport/export ok? > onload should be faster, but it corrupts fragmented indexes so we must drop them > and then it's probably as slow as dbexport/import? > > Thomas

Can I return to one of my moans about Informix? I can't understand why the chunks to which one restores should necessarily have the same names. This seems an unnecessary restriction. From what I know of the internal architecture, it should be a comparatively simple change to the system software to allow a restore to alternatively-named chunks of equal size and number. I post this opinion about once a year, and am always rewarded with a reply, redolent of Nigel Tufnell discussing the amplifier in "This is Spinal Tap", along the lines of "But you have to restore to the same chunk names". No-one's every explained why.

Neil Truby wrote: > > Can I return to one of my moans about Informix? > > I can't understand why the chunks to which one restores should necessarily > have the same names. This seems an unnecessary restriction. From what I > know of the internal architecture, it should be a comparatively simple > change to the system software to allow a restore to alternatively-named > chunks of equal size and number. Ahh, that's because one of the things that are restored before anything else are the reserved pages which contain, amoung others, the chunk table as it was on the source machine. Once the reserved pages have been manually written to the rootchunk (also as recorded on the tape!) then ontape starts the engine with 'oninit -r' and let connects to the engine starting an ontape thread and an onarchive thread which perform all the remaining disk I/O while the ontape just reads the tape and passes pages to the threads. I suppose Informix could give us an option to recreate the chunk list using some file containing the new chunks (commandline is not practical I have servers with 350 chunks), but anyway there is the reason. Art S. Kagel

"Art S. Kagel" <kagel@bloomberg.net> writes: > You must use onunload/onload or dbexport/dbimport as you guessed. onunload corrupts deteched indexes and dbexport has a 2G limit -oh what fun! > Either > that or build the database in the new server manually and copy the data > directly from instance to instance using something like my dbcopy.ec > utility. Ah... been there, done that:) > BTW relative pathname for chunks is a really attractive and a really bad > idea. There are more worms in that can than can. Can you explain some more on those worms? Thomas

Art S. Kagel wrote in message <37F28C5D.377EF0BE@bloomberg.net>... >I suppose Informix could give us an option to recreate the chunk list >using some file containing the new chunks ... Well, quite! But thanks for the reply. Neil

Thomas Parsli wrote: > > "Art S. Kagel" <kagel@bloomberg.net> writes: > > > You must use onunload/onload or dbexport/dbimport as you guessed. > > onunload corrupts deteched indexes and dbexport has a 2G limit -oh > what fun! > > > Either > > that or build the database in the new server manually and copy the data > > directly from instance to instance using something like my dbcopy.ec > > utility. > > Ah... been there, done that:) > > > BTW relative pathname for chunks is a really attractive and a really bad > > idea. There are more worms in that can than can. > > Can you explain some more on those worms? Little pink invertebrates but we're not talking about that right now. ;-) Oh THOSE worms. All soft problems mind you, but annoying enough to want to avoid it. Suppose you place the links for engine instance A in ~informix/A/disks and for instance B in ~informix/B/disks and for convenience and to allow for such neat restores as were suggested you name all those chunks the same way, say root_1, dbs_1_1, dbs_1_2, dbs_2_1, etc. Now you create the dbspaces using relative paths: disks/root_1, disks/dbs_1_1, etc. For this to work you have to start the A engine while ~informix/A is the current directory and the B instance while ~informix/B is current. Suppose one day A crashes and you cd ~/informix/A/disks to check them out eventually restarting the engine. Later, still attached to the A/disks directory you decide to adjust some parameters on the 'test' instance B and bounce it. So you shutdown and restart while still in A. Oops, death! Restore time! That's one scenario. What about that new assistant DBA you asked to up the buffers and bounce the development instance. He spends 3 hours trying to figure out why the engine will not restart and keeps giving errno=2 errors while the programmers twiddle their thumbs. He's too embarrased to ask you why it won't restart, after all didn't he just come back from Admin class? It goes on an on. Most, as I said, soft problems, but not problems you want to have. Basically a can of worms. Art S. Kagel

Thomas Parsli wrote: > We have several informix-instances on the same machinie, our (raw) chunks (links) > are placed in different places for each instance in $INFORMIXDIR/idb_xxx > -The name of dbspaces are the same. > > Now I would like to restore my level-0 (ontape) archive from a instance > using $INFORMIXDIR/idb_prod to a instance using $INFORMIXDIR/idb_tst1 as chunk-path > > ontape -r gives me a list of dbscapces to be restored, specifying chunks with idb_prod...> > Neither ontape nor onarchie seems to have options for dbspace/chunk redirection, > and dbexport is probably a little to slow for my use (14GB database, to be copied > frequently). > > Is onload/onunload the best bet or is dbimport/export ok? > onload should be faster, but it corrupts fragmented indexes so we must drop them > and then it's probably as slow as dbexport/import? > > Thomas Informix has a utiliuty that will rename chunk paths (you have to ask them for it and you may need to have enterprise support to use it). We have done what you are trying to do using this utility. Bill