Re: Why a long transaction cannot rollback?? (2)

miroslav.lorenc@ssa.co.uk wrote in article <861110092.15487@dejanews.com>... > In article <01bc4418$a31e3120$LocalHost@madeline>, > "Madeline Wu" <madeline@ms1.hinet.net> wrote: > > > > [...] > > > > I set LTXHWM=50 & LTXEHWM=60. When logical logs > > used 60%, this transaction began rollback. When > > rollback used the last logical log, many > > checkpoint happend. When the last logical log > > used 100%, "The logical logs are full---Backup > > is need." showed on the sys log file. No matter > > I used Auto-Backup or Continue-Backup, I still > > couldn't backup all full logical fogs. The > > Online 5.0 cannot work anymore. > > > > I thought this Online 5.0 got some problems with > > the AIX UNIX 3.2.5. So I test again on SCO UNIX > > whit Online 5.0, the same thing happen. Why???? > > It is a bug on Online 5.0? Or I cannot test like > > that? How can I test a long trancation and > > rollback normally? > > > > -- > > > > Madeline Wu from Taiwan....... > > [...] > > Is your OnLine version bellow 5.6? In versions up to 5.6. is a bug - I > forgot its number - OnLine tries to do checkpoint and writes info about > CKPT to logical log, but this checkpoint is not properly executed and is > repeated again and again resulting in filling logical logs with CKPOINT > records. It happens in most cases by my opinion. > > [...] > > Miroslav Lorenc > SSA Czech Republic > > -------------------==== Posted via Deja News ====----------------------- > http://www.dejanews.com/ Search, Read, Post to Usenet > Let me just add my experience with this problem: while single long transaction usually rolls back normaly, this checkpoingt trashing problem occurs almost whenever there are other open transactions pending. In several cases our customers simply brought the server down (that is usual panic reaction, but again, what could one do?). The results were one of the folloving: 1) Everithing OK, offending transaction and other ones open when the engine went down rolled back. 2) As above, but some of indices on affected tables corrupted, neccesitating rebuild (no big deal, if you have time). 3) As 1, but server leaving shared memory and semaphores behind; ipcrm was neccesary in order to bring the server up; thereupon, all OK. 4) In one case, when long transaction was alter table (this was my fault), a transient table that was to become the altered one was left behind. It was neccesary to change its name in systables (it began with blank), and simply drop it. Crude as this method of bringing the server down might be, it is still better than waiting for logs to completely fill up, in which case one should better have good understanding of Informix internals, in order to be able to save the day the way Miroslav did. In other words, have enough logs! -- Dragi Raos 4-MATE Information Engineering (http://www.4mate.hr) Zagreb, Croatia