renaming chunks with ontape?

I would like to replace a drive with a larger drive (with larger chunks). Is it legal to create larger chunks on the new drive, and then use the rename option of ontape to do a cold restore, and use the new and larger chunks, in place of the former chunks? Is it legal to combine several smaller chunks into a single larger chunk by renaming several of the old (smaller) chunks to a single new chunk name (thus "pouring" all the old chunks into a single new chunk during the restore)? Summary: I want to combine several existing small chunks into a single large new chunk, and wonder if I can use ontape to do it. (As opposed to the much more time consuming sequence of: 1)dbexport, 2)create new storage regime, 3)dbimport. Thank you. DG

Sorry... Informix 12.10 Solaris 10 DG

Original post: I would like to replace a drive with a larger drive (with larger chunks). Is it legal to create larger chunks on the new drive, and then use the rename option of ontape to do a cold restore, and use the new and larger chunks, in place of the former chunks? Is it legal to combine several smaller chunks into a single larger chunk by renaming several of the old (smaller) chunks to a single new chunk name (thus "pouring" all the old chunks into a single new chunk during the restore)? Summary: I want to combine several existing small chunks into a single large new chunk, and wonder if I can use ontape to do it. (As opposed to the much more time consuming sequence of: 1)dbexport, 2)create new storage regime, 3)dbimport. Thank you. DG Response: No, I don't believe renaming chunks is going to do what you would like it to do. When you rename chunks, you have to have the exact same number of chunks of the exact same size. So if you have 10 small chunks that you want to put into 1 big chunk, that won't work. You could have 10 small chunks on 10 different devices, and use rename to move those chunks onto 1 bigger device but using offsets to fit them all there...but you would still have to have 10 chunks as far as the Informix instance is concerned. Jacques Renaut IBM Informix Advanced Support

Thank you. I thought as much, but figured it couldn't hurt to ask... maybe I was (I was hoping) totally wrong in my thinking. So, does that leave dbexport/dbimport as the only tools Informix has to reconfigure storage? (That is, to reorganize a dbspace or sbspace from one that has many small chunks to one that has [very] few large chunks, and to place the new chunks on different drives from the original ones?) DG

Original post: Thank you. I thought as much, but figured it couldn't hurt to ask... maybe I was (I was hoping) totally wrong in my thinking. So, does that leave dbexport/dbimport as the only tools Informix has to reconfigure storage? (That is, to reorganize a dbspace or sbspace from one that has many small chunks to one that has [very] few large chunks, and to place the new chunks on different drives from the original ones?) DG Response: Well, dbexport would be the tool to use to do it all at once. You could however, add the larger dbspace, and then create new tables in the new space with slightly different names, and then manually do insert into newtab select * from oldtab, and once the insert is done, rename the oldtab and the newtab so your newly created table is the old table name and you start using that area. So you could manually do this a table at a time, and once the new table is created, drop the old tables and once the old dbspaces were cleared out, drop the dbspaces. You could also use hpl jobs to unload/reload, or external tables for unloading/reloading, rather then dbexport or insert into select * from syntax. Anything other then dbexport/dbimport would be a more manual approach, but would possibly/likely be faster, but dbexport/dbimport would be the simplest, less hands on approach. If that makes sense. I'm not aware if there might be 3rd party options that might help in re-orging tables as well, but the Informix options would basically be the dbexport/dbimport 1 and done type option, or a more manually approach of some sort of unload/load options using the various options to achieve that (like hpl/external tables/insert into select * from operating on a table at a time). Jacques Renaut IBM Informix Advanced Support

You could also use ALTER FRAGMENT ....... INIT IN ........ to move tables into the new space. Keith On 29 September 2016 at 20:56, JACQUES RENAUT <jrenaut@us.ibm.com> wrote: > Original post: > > Thank you. > > I thought as much, but figured it couldn't hurt to ask... maybe I was (I > was > hoping) totally wrong in my thinking. > > So, does that leave dbexport/dbimport as the only tools Informix has to > reconfigure storage? (That is, to reorganize a dbspace or sbspace from one > that has many small chunks to one that has [very] few large chunks, and to > place the new chunks on different drives from the original ones?) > > DG > > Response: > > Well, dbexport would be the tool to use to do it all at once. You could > however, add the larger dbspace, and then create new tables in the new > space > with slightly different names, and then manually do insert into newtab > select > * from oldtab, and once the insert is done, rename the oldtab and the > newtab > so your newly created table is the old table name and you start using that > area. So you could manually do this a table at a time, and once the new > table > is created, drop the old tables and once the old dbspaces were cleared out, > drop the dbspaces. You could also use hpl jobs to unload/reload, or > external > tables for unloading/reloading, rather then dbexport or insert into select > * > from syntax. Anything other then dbexport/dbimport would be a more manual > approach, but would possibly/likely be faster, but dbexport/dbimport would > be > the simplest, less hands on approach. If that makes sense. I'm not aware if > there might be 3rd party options that might help in re-orging tables as > well, > but the Informix options would basically be the dbexport/dbimport 1 and > done > type option, or a more manually approach of some sort of unload/load > options > using the various options to achieve that (like hpl/external tables/insert > into select * from operating on a table at a time). > > Jacques Renaut > IBM Informix Advanced Support > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0149416227fa51053e069af8

EIther that or just create a new dbspace on the new drives and move all the tables from the original dbspaces and drop it once it is empty. That will work for any dbspaces except those containing the database catalog tables. To move the database catalog itself you will have to export then import. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Sep 29, 2016 at 12:15 PM, DAVID GROVE <david.grove@alaska.gov> wrote: > Thank you. > > I thought as much, but figured it couldn't hurt to ask... maybe I was (I > was > hoping) totally wrong in my thinking. > > So, does that leave dbexport/dbimport as the only tools Informix has to > reconfigure storage? (That is, to reorganize a dbspace or sbspace from one > that has many small chunks to one that has [very] few large chunks, and to > place the new chunks on different drives from the original ones?) > > DG > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --94eb2c1943486b7fed053e131340