Backup/Restore Question

Hi all, Is there backup/restore system in Informix Online DS where I can restore an individual table, not complete dbspace? Thanks in advance.

Rather than using the ontape, onbar or onarchive utilities, you may want to focus your attention on using onunload to a disk or tape file. ontape and onbar wont allow you to restore a single table, unless, of course, the table resides in its own dbspace ( in which case onbar will do okay ). As for onarchive, I can't say, I've never used it ( I'm chicken !! ) Well, have you seen it work ?? Anyway, using onunload allows you to be selective. If you have already archived the table using ontape, onbar or onarchive then may the force be with you !! onunload is NOT an archiving tool but can be used as part of the whole archive process if the database or tables are onunloaded first THEN either a tar or cpio archive is performed on the onunloaded data. This allows the data to be restored first before inserting into the database. Hope this helps Sean gquian wrote in message <916215813.443771@proxy.inode.es>... >Hi all, > >Is there backup/restore system in Informix Online DS where I can restore an >individual table, not complete dbspace? > > Thanks in advance. > >

gquian wrote: > > Hi all, > > Is there backup/restore system in Informix Online DS where I can restore an > individual table, not complete dbspace? If what you are asking is: Is there a backup/restore strategy I can use going forward that will allow me to recover a single table if I need to?" Then Sean has posted the answer: onunload/onload. If you are asking: "I have lost/trashed a table is there anyway to recover that table from my last archive?" Then the answer is "it depends". Iff you use ontape and iff you can live with the table's status as of the last level 0 archive then get the Arcunload utility from the "Special Software" section of the IIUG Software Repository. It can extract a single table (per run) from a level 0 ontape archive and unload it to an onunload file that you can reload using onload. If the various warnings and caviats on the Arcunload intro page frighten you as much as they did me, then also get my on_to_unload package from the repository which will read the unload format file and write an ASCII delimited file that can be reloaded safely by dbload or dbaccess' LOAD command. You can then even edit the file to filter the records that you need. Art S. Kagel

Art S. Kagel wrote: > If what you are asking is: Is there a backup/restore strategy I can use > going forward that will allow me to recover a single table if I need > to?" Then Sean has posted the answer: onunload/onload. > > If you are asking: "I have lost/trashed a table is there anyway to > recover that table from my last archive?" Then the answer is "it > depends". Iff you use ontape and iff you can live with the table's > status as of the last level 0 archive then get the Arcunload utility > from the "Special Software" section of the IIUG Software Repository. > It can extract a single table (per run) from a level 0 ontape archive > and unload it to an onunload file that you can reload using onload. If > the various warnings and caviats on the Arcunload intro page frighten > you as much as they did me, Well, that's just me, spreading fear and paranoia. If you trust onunload/onload, then you can trust Arcunload, since Arcunload simply produces an onunload file, and you use onload to load the data back in. The reason for all the caveats is that I have, under certain circumstances, seen onload crash OnLine and leave part of the unsuccessfully loaded table behind, in such a manner that I couldn't clean it up (at least, not easily, and not without using a bunch of utilities the average DBA wouldn't have access to). The specific circumstances where I saw this was when I used a different version of Arcunload from the version of OnLine, e.g. Arcunload for 5.0 against a 7.12 database (I think), and maybe 7.20 Arcunload against a 7.23 database. And you'll get the same thing if you try to load a tbunload file from 5.0 into a 7.12 database. (If you now feel compelled to try this yourself, please please please do it in a test instance.) But I don't have a warm fuzzy feeling that you couldn't crash OnLine or leave pieces of a table behind in other circumstances, if you tried hard enough. Hence the advice to load back into a test instance (which certainly couldn't hurt, no matter what.) Anyway, I always think a good, healthy amount of paranoia is something that should be encouraged in DBA's and Sys Admins, don't you? Certainly makes life a lot easier for the folks in Informix Customer Service. June -- june_t@hotmail.com Grounded in Palo Alto, living on Oreo's

June Tong wrote: > Art S. Kagel wrote: [SNIP] > Well, that's just me, spreading fear and paranoia. If you trust onunload/onload, > then you can trust Arcunload, since Arcunload simply produces an onunload file, > and you use onload to load the data back in. The reason for all the caveats is > that I have, under certain circumstances, seen onload crash OnLine and leave part > of the unsuccessfully loaded table behind, in such a manner that I couldn't clean > it up (at least, not easily, and not without using a bunch of utilities the > average DBA wouldn't have access to). The specific circumstances where I saw > this was when I used a different version of Arcunload from the version of OnLine, > e.g. Arcunload for 5.0 against a 7.12 database (I think), and maybe 7.20 > Arcunload against a 7.23 database. And you'll get the same thing if you try to > load a tbunload file from 5.0 into a 7.12 database. (If you now feel compelled > to try this yourself, please please please do it in a test instance.) But I > don't have a warm fuzzy feeling that you couldn't crash OnLine or leave pieces of > a table behind in other circumstances, if you tried hard enough. Hence the > advice to load back into a test instance (which certainly couldn't hurt, no > matter what.) > Anyway, I always think a good, healthy amount of paranoia is something that > should be encouraged in DBA's and Sys Admins, don't you? Certainly makes life a > lot easier for the folks in Informix Customer Service. I agree, and when the author of a utility is paranoid, how much more so should a user like me be? Hence the development of on_to_unload.c to get me a SAFE load file. Actually the original impetous for on_to_unload was the ability to edit the file before unloading and to be able to depend on dbload to throw deuplicate rows away since the application group had begun recovery of the table by hand before calling me and did not want to lose what they had done. June, I trust arcunload, I tested it extensively myself even to verifying that the onunload file it generates is equivalent to the file that onunload creates from the same table, but if you have doubts about the safety of onloading, I do too because I also trust your judgement. Art S. Kagel