Restoring specific tables and table segments in INFX 7.2

We currently run a Level-0 ONTAPE Backup three time daily, which, in the event of a catastrophe would allow us to recover the full DB quite nicely. However, should a user, program or admin accidentally delete or corrupt a small portion of the database it generally doesn't make sense to restore the entire database. Is there a method or tool that allows for the recovery of a table or table segment? Is it possible to restore the Level-0 backup from a Production DB to it's Development DB "equivalent"? Any help would be appreciated. Thanks.

David Murray wrote: > > We currently run a Level-0 ONTAPE Backup three time daily, which, in the > event of a catastrophe would allow us to recover the full DB quite nicely. > However, should a user, program or admin accidentally delete or corrupt a > small portion of the database it generally doesn't make sense to restore the > entire database. Is there a method or tool that allows for the recovery of a > table or table segment? Is it possible to restore the Level-0 backup from a > Production DB to it's Development DB "equivalent"? > > Any help would be appreciated. Thanks. Only if you can create the same chunk file names for the target engine you are restoring as the source engine had. This basically means that if you want the production engine to remain online (and who does not?) you need to restore to another machine. This, BTW, is one reason that Informix DBAs use symbolic links for chunk names rather than the real file or device names. Here are the steps: 1) On the target machine create the chunk paths as they exist on the engine from which the archive was taken. Make sure each file/device is physically AT LEAST AS LARGE as the chunk on the source that will be restored to it (ie if the chunk on source is 1GB you CAN use a 2GB disk partition as its surrogate but not a 0.99GB partition). 2) Create an ONCONFIG file making sure that all SHARED MEMORY parameters are the same as well as the size and offset of the ROOTDB, these include the sizes of the logs and log buffers but not PDQ parameters. The number of BUFFERS, various processors, LRUS, CLEANERS and other disk and processor related parameters do not need to be the same as on the source so you can bring up a much smaller engine for the restore. 3) Make the required DBSERVERNAME and sqlhosts entry these SHOULD NOT be the same as on the source. Also the SERVERNUM can be different (if you use SERVERNUM 0 for all your engines you may already have one on the target host so you can use SERVERNUM 100 or whatever). The /etc/services entries are needed also and again the service need not be the same as on the source (again a local engine may be using that service causing a conflict, just change it). Truth is all you will need if you only want to UNLOAD/LOAD is a shared memory connection but if you want to use dbcopy.ec or INSERT INTO....SELECT FROM ... you will need a network connection. 4) Start the restore, for ontape just ontape -r. If you are not saving logs, or do not want to restore them (in your example I imagine you do not) answer no to restoring logs and wait for fast recovery to complete. When the engine finishes fast recovery (be patient or you will have to start the restore over) bring the engine ONLINE (onmode -m) before shutting it down or you will have to start over, though I guess you just want it online anyway. 5) Now extract or copy the fumble finger's data back where it belongs and shut down. Art S. Kagel