From: sfc@tpghq.com (Steve Caswell)
Subject: Re: Transaction Log File
Organization: Palmer & Associates, Inc., Norcross, GA
Date: Fri, 8 Jan 1993 14:48:37 GMT

In article <C0J1q9.FvG@rivm.nl> jwd@rivm.nl (Jan Diesel) writes:
>David Kaplan (djk@sei.cmu.edu) wrote:
>: 
>: 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.
>
>The transaction logfile is used not only by inserts, updates and deletes but
>by selects as well. The obvious solution to your problem seems increasing the

Unless something drastic has changed, selects ARE NOT LOGGED to the log file.

>size of the transaction logfile or decreasing the size of your transactions.
>The latter can be done by setting autocommit on (thereby causing each statement
>to be treated as a singleton transaction). If this won't help and you don't
>want to increase the transaction logfile you'll have to split up your statements.
>
Setting autocommit on is not a good thing to do in normal application
situations.  This command is in INGRES primarily as a conversion tool to allow 
converted release 5 applications to behave under 6 as they did in 5.  Using 
set autocommit on in a production 6 application is not a good idea for three 
reasons:

   1.  It is NOT ANSI standard.  It in fact makes transaction semantics behave
       exactly opposite of ANSI standard.  If someone comes in later to
       maintain your code, and is not aware that set autocommit on has been
       executed, and is expecting ANSI transaction semantic behavior, they will
       be in for a rude surprise.

   2.  Because set autocommit on is a conversion feature, there is no guarantee
       that is will be supported in the future when Ingres decides that everyone
       has converted and they remove the command.


   3.  You lose rollback capability.  Unless EVERY statement in an application 
       is a single statement transaction, you are giving up a lot.  Even if
       every statement is a single statement, the incremental cost of putting
       in a commit statement is minor.
>: 
>: 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
>
>Regards,
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Jan Diesel                                       |          jwd@rivm.nl
>Informatics Service Centre                       |  tel. ++31 30 742067
>P.O.Box 1, 3720 BA  BILTHOVEN, the Netherlands   |  fax. ++31 30 282316
>RIVM - National Institute of Public Health and Environmental Protection


-- 

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."
Newsgroups: comp.databases.ingres