Re: Dbspace recovery

Oh, to your question about the sizes and number of dbspaces and chunks: Each chunk path must exist. Although you can use ontape's chunk rename feature to restore to different chunks even with different offsets there must be a one-to-one relationship between the original chunks and the new ones and they must be at least as large as the original chunk files or devices. You CAN map say two 1GB chunks to different offsets of the same 2GB or larger file or device, but that's still two chunks mapping to two chunks. Get it? You only have to make sure that the chunks for the ROOTDB dbspace and the dbspaces which you want to restore exist. Any chunks belonging only to dbspaces which you will not be restoring do not have to exist, the engine will be marking them down/offline anyway. You will have to set ONDBSPACEDOWN appropriately to permit the engine to remain online with some chunks marked down, though. The dbspaces will be the same as the originals when the restore is complete, at least those dbspaces which you choose to restore will be. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) See you at the 2010 IIUG Informix Conference April 25-28, 2010 Overland Park (Kansas City), KS www.iiug.org/conf Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, 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 Sat, Feb 27, 2010 at 8:23 PM, Art Kagel <art.kagel@gmail.com> wrote: > NO! the INFORMIXSERVER name is completely irrelevant. Ok here are the > important points: > > > - In order to restore a single dbspace other than the ROOTDB space, > called a warm restore, the ROOTDB space must exist. > - If you are restoring a no-ROOTDB dbspace to the same > machine/instance, say after a few chunks' disks failed that belong to that > one dbspace (or a few dbspaces for that matter), then the ROOTDB dbspace is > already in place (assuming that the ROOTDB dbspace's chunks did not fail of > course) and you ONLY have to restore the non-ROOTDB dbspace(s) that you need > to restore. > - If, on the other hand, you want to restore just one dbspace to > another machine so that you can, for example, try to extract rows that some > fumble fingered DBA "accidentally" deleted, you CAN do that, but first you > have to perform a cold restore of the ROOTDB dbspace. Once that's > accomplished you can perform a warm restore any other single dbspace(s). > > > Note that if you intent is to recover deleted data or a dropped table, it > is probably faster to use the archecker utility's ability to extract the > table's data directly from the archive and insert it into any table you want > - the original table or a structural copy of the table you can use to stage > the data and filter it for rows you want to recover. > > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > IIUG Board of Directors (art@iiug.org) > > > See you at the 2010 IIUG Informix Conference > April 25-28, 2010 > Overland Park (Kansas City), KS > www.iiug.org/conf > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Advanced DataTools, 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 Sat, Feb 27, 2010 at 1:26 PM, pow43 <faber_38@yahoo.no> wrote: > >> On 26 Feb, 19:26, Art Kagel <art.ka...@gmail.com> wrote: >> > You cannot restore a single dbspace to a new location. You can only >> restore >> > a single dbspace to the same existing instance from which it was >> archived. >> > You can only restore an entire instance on a new server. >> > >> > Art >> > >> > Art S. Kagel >> > Advanced DataTools (www.advancedatatools.com) >> > IIUG Board of Directors (a...@iiug.org) >> > >> > See you at the 2010 IIUG Informix Conference >> > April 25-28, 2010 >> > Overland Park (Kansas City), KSwww.iiug.org/conf >> > >> > Disclaimer: Please keep in mind that my own opinions are my own opinions >> and >> > do not reflect on my employer, Advanced DataTools, 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 Fri, Feb 26, 2010 at 10:45 AM, pow43 <faber...@yahoo.no> wrote: >> > > Hi, >> > >> > > I have started testing revovery of a singe dbspace or all. The senario >> > > is that the server that the IDS was running on is completely gone and >> > > we have to restore a backup from the backupsystem (we use Veritas >> > > NetBackup) to a new server/host running the same IDS version (for time >> > > being 11.50.FC5 64-bits). On this new server I wanted to restore the >> > > db_tables dbspace after creating it with same size. I created the >> > > dbspace and started a ontape -r db_tables using the fullbackup (ontape >> > > -s -L 0) from the old "gone" instance, but it failed with error : >> > >> > > Spaces to restore:1 >> > > [db_tables >> > > ] >> > > Physical restore failed - DBspace db_tables can not be restored; not >> > > in DBspace table. >> > >> > > A full resore of all the dbspaces failed also with error: >> > >> > > Spaces to restore:1 >> > > [db_rootdbs >> > > ] >> > > 2 >> > > [db_loglog >> > > ] >> > > 3 >> > > [db_physlog >> > > ] >> > > 4 >> > > [db_temp >> > > ] >> > > 5 >> > > [db_tables >> > > ] >> > > 6 >> > > [db_indices >> > > ] >> > > Physical restore failed - >> > > [db_rootdbs >> > > ] >> > > Invalid DBspace list >> > >> > > Program over. >> > >> > > After a bit of research I understod that the dbspaces has to be made >> > > excatly with the not only the same names, but also the dbspace number. >> > > So I reInitialized the rootdbs (it was named something else on the new >> > > server) and all the abow dbspaces in the same order. Still it failes: >> > >> > > -bash-3.00$ ontape -r -D db_tables>> > >> > > Please mount tape 1 on /opt/informix/data/LEVEL_0_backup and press >> > > Return to continue