Re: Infinite Recovery Help Needed (Online 5.0)

From article <226qq6INNs28@emory.mathcs.emory.edu>, by inf_bb@hermes1.sps.mot.com (informix users bb): >>> This is a problem which we've experienced on out project several >>> times. Informix technical support can abort your long transaction >>> by logging into your system and running a utility called tbzero. >>> >>> As I said, we've had this done several times. Perhaps someone from >>> Informix will explain why they will not release this utility. >>> >>> Cheers, >>> Coty > > coty, > > first, informix shouldnt release tbzero as a general utility. the fact that > you get long transactions suggest that you do not have enough logical logs > (or logical logs which are too small) or you should examine the transactions > you are running. tbzero alters the online instance and sets the active > transaction flag to be 0. so when you fire up online again, it does not > rollback any transactions. this potentially leaves your database in an > inconsistent state. informix suggests that you tbcheck your database > tables for any problems. for instance, if you were building an index on > a table when this situation occured, your hosed. the index is partially > built and in some cases you cannot drop the index/table. if indeed you > encounter problems after running tbzero, your on your own as far as support. > Well, this should be at the user's discretion. Since the current alternative is to drop the database anyway (if you can't let Informix on the system), having tbzero is a positive-sum proposition, rather than the current negative- sum situation of not having it. > the magic number of 61) or by tbinit'ing with larger logical logs. > [increase the number of logical logs, up to] Actually not in the general case: you have no way of knowing, a priori, the maximum size of any arbitrary query; therefore you can never guarantee that some user will not crash the system. Another suggestion was to lower the high-water parameters by 10 from the current default values. However, it appears that this also does not solve the general case; if the offending transaction spans too long a period, the logs can fill with other traffic, which if they are also committing or rolling back when the high-water mark is reached, might occupy the space needed to rollback the offending transaction. You should be able to add another logical log during recovery mode, so that the stupid thing at least has some place to rollback in. Some people have suggested, BTW, that you can toggle the mirror flag (if you weren't using mirroring) to convince online that all is well. Andrew Shaw AT&T Bell Labs andrew.shaw@att.com apache!shaw@att.com