Re: tbzero, logs, high water marks
In article <2net3r$s4l@emory.mathcs.emory.edu>, cwakins@rmc.com says: ... some lines deleted from each of these postings... > >> > >> 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, 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.) > > 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 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 We have never had a system crash that Informix could not deal with (at least not in living memory.) We are running around 13 instances of OnLine on 7 machines, 6 of them DEC System 5000/250's running Ultrix and 1 Alpha running OSF/1. These systems have been in place for around 3 years. My question is: how often do you have to use tbzero? It seems to me that your platform is very unstable (at least compared to ours) if you keep losing time and having to restore from archives. Are there some system level parameters that are causing these crashes? (memory, disk offsets, semaphores, whatever) Is this behavior *normal* for other installations like yours? Does Informix track this, did they tell you of any other similar situations? With such a large database, are you running into any O/S limitations? We are I/O bound, by a very large margin, and you must be even more so. If tbzero isn't causing you any problems, then good deal. A thorough under- standing of what transactions are open doing what to the data at the time of a system crash would let you judge the ramifications of using it. It looks like you have a good idea of what indexes to rebuild. I don't really have any concrete suggestions. (I'm doing good to come up with concrete questions! ;-)) but just the knowledge that maybe there's a better way might help. Good luck, __________________________________________________________________ | Clem Akins Standard Disclaimers Apply | | Reynolds Metals Co. "Climb High, Cave Deep!" | | Alloys Plant (MS #59) | | 3509 East 2nd St Internet: cwa@leia.rmc.com | | Muscle Shoals, Al Telephone: (205) 386-6783 | | USA 35661-1256 Facsimile: (205) 386-6831 | |________________________________________________________________|