Re: tbzero, logs, high water marks

In article <2net3r$s4l@emory.mathcs.emory.edu>, cwa@leia (cwakins@rmc.com) says: > >> TBZERO is the only way I know of. >> >> A released, supported tbzero would be very nice. We've needed >> similar from time to time. There really isn't any other way after >> Informix won't come up. >> > >Watch out for that tbzero. johnl wrote a pretty scathing rebuke of the use >of that program. It is truly a tool of last resort, and its use may be worse >than having to restore from an archive. There is no way to guarantee the >state of your data after a tbzero (or something like that.) > >We used to have that problem, but we learned two things: > > re-write deletes/purges to commit every row > > if the logs get filled up, manaully run the auto-backup from > tbmonitor to free them. This works when the tbtape dies, and the > logs fill from regular use (maybe not from a single huge event). > >This saved us a bunch of hassle that we didn't used to know how to deal with. > Yes, it is a tool of last resort. No, we don't use it because our logs fill up. We use it because sometimes after a system crash Informix won't recover. It either recovers for hours, or puts out a message in the Informix turbo log that it can't recover. We can reload our 18GB database and be down for 12-18 hours, causing our entire hotel reservation system to be down for a day, costing us a large amount of money. We can reload our 40GB database and be down for 48 hours, plus rerunning up to 4 days of processing. (An archive on this system takes 36-40 hours, so we run them Mon/Wed/Fri). We'd rather take our chances with tbzero until Informix is changed such that it can ALWAYS recover, no matter what the system is doing. We know that we may have to rebuild indexes after a tbzero. We've never seen any other ill effects. Any suggestions? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Burks jburks@promus.com Database Adminstrator The Promus Companies