Re: On-Archie or OnBar ??

Tim Schaefer wrote: > > 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. Do all new Informix innovations get attributed to departing execs, or is this just one exec all along? :-) > 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. I couldn't agree more. > 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. My point was that this is also true for OnTape and OnArchive. > 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. Unless you are performing a warm restore of course. > 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 ) Are you saying OnBar works differently for IDS-EPO? I don't have any experience of that engine. > 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. Yes, I believe a lot of IDS-EPO sites use HPL for archive and 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. Well Informix doesn't have a table level restore, so yes, yet again you are right. ;-) But I take your point, what works for IDS doesn't necessarily work for IDS-EPO, or even IDS-UDO. Different strokes for different folks. It's good to hear some real-world feedback, thanks. 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"!|/ ////////| +----------------------+-----------------------------------+-----------+

> "Mark D. Stock" wrote: > > > Tim Schaefer wrote: <snipped> > > 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. > > Unless you are performing a warm restore of course. > As I recall, not having done a restore in the past 30 days, you still have to bounce the engine. This is an interruption that is completely unnecessary. > > 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 ) > > Are you saying OnBar works differently for IDS-EPO? I don't have any > experience of that engine. > I'm saying Mark that onbar should have the functionality one would expect in a recovery mechanism. The constraints that onbar puts on recovery are too limiting to be useful. For example, a user drops a table. They gasp, and ask you to restore it. Hmmmmm, ok, onbar. You restore it, if you're lucky and it is the only one in a dbspace, and this makes it easy. Then the logs come along at the end of the restore and drop it again. This is silly. There should be an option to recover a dbspace into a good dbspace without the logs. Sure, issue warnings about consistency, who cares, I want the last backed up dbspace. We insert data once a week into this table, what possible inconsistencies could exist? The other problem is that let's say you have 10 tables, and three need to be restored, but 7 do not need to be. These 10 tables live in a single dbspace. With onbar you're forced to recover the whole dbspace back into the engine. Maybe I'd like to restore one or more tables out to disk, or some back into the dbspace. Incremental restoration may be required due to some kind of hardware and or environmental constraint as well. In the course of the real world, onbar is not flexible enough or fast enough. It needs to be improved. A complete truth table of recovery should be designed into the next release of onbar to cover all the angles. > > 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. > > Yes, I believe a lot of IDS-EPO sites use HPL for archive and restore. > This is accepted practice, yes. DW breaks a lot of conventional thought, but consider that disks are cheaper now, as well as memory. The idea that a data base has to be a nightmare to backup and restore should be thrown out. The smallest unit of the data base should be recoverable as well as being able to be backed up, even if the "consistency" factor is a question. If you're ever in a situation where you need to recover the data, and the recovery software ties your hands, you will then know what I'm talking about. There is nothing more frustrating that being forced to recover a whole instance when all I need is a table. > > 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. > > Well Informix doesn't have a table level restore, so yes, yet again you > are right. ;-) > Mark I appreciate a back-handed compliment/insult from time to time, but seriously I challenge you and every DBA out there to actually go through the restore sequence on a test box. Run through a series of restore requirements and see if onbar actually meets your needs. You might be surprised at what you find out, and how little most DBAs know about actually recovering a data base. I was there right along with you until I ran a suite of tests. Drop a data base, try to recover it. Drop a table, drop a couple of dbspaces, try to do the point in time restore. Once you've completed the tests you will then begin to see better ways of designing systems with recovery in mind. You will then see how limited onbar is. Thanks, Tim > But I take your point, what works for IDS doesn't necessarily work for > IDS-EPO, or even IDS-UDO. Different strokes for different folks. It's > good to hear some real-world feedback, thanks. > > 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://www.inxutil.com -- -