Re: On-Archie or OnBar ??

Mark, It's my understanding talking with ATG folks that a table-level restore may be available soon. Now that a certain exec has left there appear to be new utilities in the works. I have no confirmation about any of it, however, neither did the ATG folks. The arguments made against it for consistency are important I guess for certain situations, but I would argue these situations are more the minority than the majority. If a table needs to be restored work must halt. If it's an OLTP system, then I'd argue for shadow tables in the design to accommodate this. Yes more overhead, more sleep at night as in mirroring. To clarify my last points, which as you confirm are right, onbar is great ( if it works ) for a disaster-recovery mechanism, where the whole instance would need to be recovered. It is impractical in every day use for any kind of realistic restores of any kind. If indeed a disaster recover were performed with onbar it would also take longer than recovering a system incrementally with table-level restores. One other important point about onbar is that it requires moving the engine to off-line, which for the purposes of a table-level restore would be silly. You don't take UNIX to single-user mode to restore a file, neither should the IFMX engine be offline for a simple table or data base restore. There should be a "-force" option to force the overwrite into a perfectly healthy dbspace. There should be a heirarchical restore capability, starting at the data base level, then dbslice, then dbspace, then table. ( dbslice for us who use XPS ) Lastly it is also my real-world experience that it is FASTER (( Hello! )) to reload a table from load files with the high-performance loader than it is to diddle with onbar. I also don't need to move the engine into off-line mode to do this. If the table is soooooo big that it takes a day to recover, so be it. For an OLTP world I'm sure there are design considerations, but I would not risk any of my data to an onbar restore. Until a reasonable recovery mechanism is in place with Informix engines the best way is the best way, table-level recovery via UNIX load files. Thanks, Tim "Mark D. Stock" wrote: > > Tim Schaefer wrote: > > > > Derek, > > > > The onarchive program works fine on a variety of platforms > > with one exception. Have you ever tried to restore what you've > > backed up using onarchive? On some platforms the backup > > is great, the restore doesn't work. > > > > Unless you can restore from your backups, your backups are worthless. > > > > I tend to think that onbar is equally worthless. I've done a > > complete set of tests with it, and find it does not have the > > features necessary for real-world recovery. For example, the > > infamous point-in-time restore applies to the WHOLE INSTANCE > > without the option to restore either a data base , dbspace, > > table, dbslice if you use 8.x, or any combination of these. > > > > Here's a great test for your recovery: A user drops a table. > > Recover the table using onbar. Oh, uhm, fortunately for you > > the table was in its own dbspace. Right. Well, the logs come > > back with the restore and redelete the table for you. Oh, ok > > let's restore using point-in-time. Bring the engine down, > > remove the links to the raw device, bring the engine up, engine > > thinks the dbspace is hosed, marks it offline. Now you can > > restore it using point-in-time restore. Uh, well that applies > > to the whole instance, sorry. What if you didn't want to > > bring the whole damn instance back? The good folks who created > > onbar really don't think like the real world. > > > > You have to really build your system around onbar if you > > choose to use it. I can point to site after site who ignored > > onbar until after they built a system only to find that because > > of onbar the system had to be redesigned around onbar's limited > > feature set, or they abandon onbar because of its limitations. > > > > Unless you can restore from your backups, your backups are worthless. > > > > The only benefit I see to onbar is that it tells the engine > > things are backed up so that new logs can be brought online, > > or other situations where onbar is needed to tell the engine > > things are ok. But as to a backup strategy, I still tell people > > to buy as much disk for table dumps-to-disk as the data base. > > > > We had onbar working great with ADSM and it will continue to work > > great, but what good is it for me to attempt a restore? Only when > > I would want to restore the whole damn instance. This is all its > > good for. > > > > Is this crazy? No, there is no table-level restore in onbar. You > > get all or nothing. And if the last onbar backup is hosed you are hosed. > > You are at the mercy of also needing the logical logs. For shops who > > have onbar working with their heavy OLTP, and can honestly say they > > can restore, these are shops where they have probably been through a > > certain amount of pain getting this to work. > > > > I still challenge anyone out there to tell me that a table level dump > > to disk and UNIX backup is less than onbar. Even on NT using cooked > > files and a tape drive, simply restoring the dbspaces with NT backup > > is better than relying on the limitations of onbar. > > > > Onbar should scare the living daylights out of you for restore. > > Don't pick on OnBar, it has more functionality than the other two > archive utilities put together. What you are saying is that you don't > like Informix's archive & restore policies. And from past experience I > know that you are ALWAYS right Tim, so I won't argue the point. :-) > > But to clarify the policy, all data in a database instance must be in a > consistent state and in the same time zone. Because referential > integrity can be maintained at the application level, the database > server has no way of knowing which tables would need to be restored > together with your lost table in order to maintain integrity. I agree it > would be nice for the DBA to be able to override this guarded approach, > but currently you can't. > > I have a number of customers who would like to restore individual tables > from archives, but that has nothing to do with OnBar as such. I believe > June wrote a utility to restore a single table from an OnTape archive. > But I have not heard of such a utility for either OnArchive or OnBar. > > Cheers, > -- > Mark. > > +----------------------------------------------------------+-----------+ > |Mark D. Stock - Informix SA http://www.informix.com |//////// /| > |mailto:mdstock@informix.com http://www.informix.com/idn |///// / //| > |http://www.iiug.org +-----------------------------------+//// / ///| > | Tel: +27 11 807 0313 |If it's slow, the users complain. |/// / ////| > | Fax: +27 838250 2325 |If it's fast, the users keep quiet.|// / /////| > |Cell: +27 83 250 2325 |Therefore, "No news: travels fast"!|/ ////////| > +----------------------+-----------------------------------+-----------+ -- - -- --- Tim Schaefer ---- tschaefe@mindspring.com --- http://w