Re: Problem with long transactions

In article <1993Jan13.211431.61948@evolving.com> bpk@evolving.com (Brad Knotwell) writes: > >We currently are having a problem with "aborting long transactions." When >this occurs our logical logs (we have 6 @ 500 pages/log) fill up and tbtape >(running continuously) is unable to back them up. This situation fills >turbo.log with countless "Logical logs are full. . .etc." > >We are able to recover okay but it is annoying (at the least). We are >going to increase the number of logs to ten in the future. > >QUESTIONS: > > 1) Does anyone think increasing the number of logical logs will help? > > 2) Does anyone have any reasons why aborting a long transaction > would fill up the logs? Consensus around here is that for some > reason Informix is unable to rollback the transaction quickly > enough and other concurrent transactions fill the logs. If this > is the case why doesn't the database eventually "catch up?" > >Thanks in advance. > > >Brad Knotwell bpk@evolving.com >Evolving Systems, Inc. >Denver, CO > > > What is a long transaction? Well, let's see... A long transaction is one which starts (issues a BEGIN WORK) meanwhile other transactions BEGIN and COMMIT, BEGIN/COMMIT, etc. Logs fill... Many logs fill... 90% of the log space fills... Informix cannot backup the logs (even the COMMITED transactions) until all tranactions in the log(s) are COMMITED or ROLLEDBACK. What happens to "protect" you is that Online senses that this tranaction is still going, logs are 90% full, and it begins to roll the transaction back. That is what a long transaction is. So... The answer to question 1 is "maybe". You need to add enough logs so the transaction will complete. The answer to question 2 is when the ROLLBACK of the long transaction occurs, the logs fill up. The best answer to the question maybe that the offending transaction be looked at and if possible maybe in can be "shortened". To tie up data for the length of a "long transaction" is usually not a good idea (NOTE: all my experience is in "real time" environments and thus data availablity is paramount). Hope this helps. -- ------------------------------------------------------------------------------- Mike Reetz boulder.colorado.edu!morse!reetz UNIX(tm) Operations Manager or reetz@ncar.ucar.edu (<== BEST) NCAR - National Center For Atmospheric Research