home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.databases.ingres
- Path: sparky!uunet!tpghq!sfc
- From: sfc@tpghq.com (Steve Caswell)
- Subject: Re: Transaction Log File
- Message-ID: <1993Jan8.144157.9086@tpghq.com>
- Organization: Palmer & Associates, Inc., Norcross, GA
- References: <1993Jan7.145532.4404@sei.cmu.edu>
- Date: Fri, 8 Jan 1993 14:41:57 GMT
- Lines: 63
-
- In article <1993Jan7.145532.4404@sei.cmu.edu> djk@sei.cmu.edu (David Kaplan) writes:
- >
- >I'm having some intermittent problems with the Trasaction Log File. Or,
- >rather, it's having trouble with me? In either case, the following error
- >occurs when running a rather long set of queries:
- >
- >**** ERROR: E_US1262 Your transaction has been aborted due to the transaction
- > log file having reached one of the limits set by the system administrator.
- > These limits are log_full, force_abort, and 90 percent of force_abort
- > when using the fast_commit option to start DBMS servers.
- > (Thu Jan 7 12:21:39 1993)
- >
- >What's this all about. I mentioned intermittent because some days I get the
- >error, and other days I don't?! There are commits after each query (all
- >creation and insertion commands), and the queries are broken up just about as
- >far as we can get them.
- >
- >Could this error be an indicator that something else is wrong? The fact that
- >it is intermittant EVEN when the data being used has not change is what really
- >has me puzzled.
- >
- >Any clues appreciated ;-)
- >
- >Thanks,
- >
- >-Dave.
- >
- >
- >---------------------------------------------------------------------------
- >David J. Kaplan djk@sei.cmu.edu
- >Software Engineering Institute dk3g+@andrew.cmu.edu
- >Carnegie Mellon University (412) 268-7736
-
- This message basically means you have exceeded the capacity of the transaction
- log file. This can occur because of several factors, or combination of factors.
- Basically, you need enough log file to hold all currently executing transactions
- plus all unjournalled committed transactions. If a transaction needs more room
- in the log file, you will get this error and that transaction will be rolled
- back. If the archiver cannot drain committed transaction to the journal, you
- will also get this message as the space being used for active transactions
- approaches the space being used to hold unjournalled committed transactions.
- Check the frequency of consistency point and archiver wakeup. The larger
- your log file, the more frequent you should take a consistency point (even
- as often as 1% of log file used). Your archiver wakeup should be no more than
- 20% of log file used.
-
- Another condition that can cause the log file to "fill up" is the hanging around
- of an inactive transaction. For example, if someone connects to isql and makes
- a change to data, and does not commit, that transaction is being held in the
- log file. Because the archiver cannot drain any transactions past this open
- one, the open transaction acts as a roadblock to the archiver. Eventually,
- as other transaction consume log file, it will "fill up" and you will get this
- error.
-
- This is a hard forum to explain log file and archiver functionality in detail,
- but hopefully this gives you some things to look at. Feel free to e-mail
- follow-up questions.
-
- --
-
- Steve Caswell | (404) 448-7727 | "The opinions expressed are my
- Principal Consultant | sfc@tpghq.com | own. They may not be perfect,
- The Palmer Group | uunet!tpghq!sfc | but they're all I've got."
-