home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / ingres / 2212 < prev    next >
Encoding:
Text File  |  1993-01-11  |  5.3 KB  |  113 lines
  1. Newsgroups: comp.databases.ingres
  2. Path: sparky!uunet!mcsun!sun4nl!rivm!jwd
  3. From: jwd@rivm.nl (Jan Diesel)
  4. Subject: Re: Transaction Log File
  5. Message-ID: <C0oo00.BCA@rivm.nl>
  6. Sender: news@rivm.nl
  7. Organization: R.I.V.M.
  8. X-Newsreader: Tin 1.1 PL5
  9. References: <1993Jan8.144837.9232@tpghq.com>
  10. Date: Mon, 11 Jan 1993 09:36:00 GMT
  11. Lines: 100
  12.  
  13. Steve Caswell (sfc@tpghq.com) wrote:
  14. : In article <C0J1q9.FvG@rivm.nl> jwd@rivm.nl (Jan Diesel) writes:
  15. : >David Kaplan (djk@sei.cmu.edu) wrote:
  16. : >: 
  17. : >: I'm having some intermittent problems with the Trasaction Log File.  Or,
  18. : >: rather, it's having trouble with me?  In either case, the following error
  19. : >: occurs when running a rather long set of queries:
  20. : >: 
  21. : >: **** ERROR: E_US1262 Your transaction has been aborted due to the transaction
  22. : >:     log file having reached one of the limits set by the system administrator.
  23. : >:     These limits are log_full, force_abort, and 90 percent of force_abort
  24. : >:     when using the fast_commit option to start DBMS servers.
  25. : >:    (Thu Jan  7 12:21:39 1993)
  26. : >: 
  27. : >: What's this all about.  I mentioned intermittent because some days I get the
  28. : >: error, and other days I don't?!  There are commits after each query (all
  29. : >: creation and insertion commands), and the queries are broken up just about as
  30. : >: far as we can get them.
  31. : >
  32. : >The transaction logfile is used not only by inserts, updates and deletes but
  33. : >by selects as well. The obvious solution to your problem seems increasing the
  34. : 
  35. : Unless something drastic has changed, selects ARE NOT LOGGED to the log file.
  36.  
  37. I don't know where I got this information but you're right and I'm wrong:
  38. selects are not logged (unfortunately I can't find this in the manuals).
  39.  
  40. : 
  41. : >size of the transaction logfile or decreasing the size of your transactions.
  42. : >The latter can be done by setting autocommit on (thereby causing each statement
  43. : >to be treated as a singleton transaction). If this won't help and you don't
  44. : >want to increase the transaction logfile you'll have to split up your statements.
  45. : >
  46. : Setting autocommit on is not a good thing to do in normal application
  47. : situations.  This command is in INGRES primarily as a conversion tool to allow 
  48. : converted release 5 applications to behave under 6 as they did in 5.  Using 
  49. : set autocommit on in a production 6 application is not a good idea for three 
  50. : reasons:
  51. : 
  52. :    1.  It is NOT ANSI standard.  It in fact makes transaction semantics behave
  53. :        exactly opposite of ANSI standard.  If someone comes in later to
  54. :        maintain your code, and is not aware that set autocommit on has been
  55. :        executed, and is expecting ANSI transaction semantic behavior, they will
  56. :        be in for a rude surprise.
  57. : 
  58. :    2.  Because set autocommit on is a conversion feature, there is no guarantee
  59. :        that is will be supported in the future when Ingres decides that everyone
  60. :        has converted and they remove the command.
  61. : 
  62. :    3.  You lose rollback capability.  Unless EVERY statement in an application 
  63. :        is a single statement transaction, you are giving up a lot.  Even if
  64. :        every statement is a single statement, the incremental cost of putting
  65. :        in a commit statement is minor.
  66.  
  67. I agree with you on most points, but I do think that 'autocommit on' is a usefull
  68. ingres-feature. By the enforcement of singleton transactions endusers aren't
  69. bothered with the transaction mechanism anymore. Unless autocommit is set off
  70. most interference with more complex applications (not using singleton transactions)
  71. is no longer a problem.
  72. The only price that has to be paid is setting autocommit off in your applications.
  73. (this also makes sure you won't suffer from removing the autocommit command,
  74. which I hope won't happen).
  75.  
  76. : >: 
  77. : >: Could this error be an indicator that something else is wrong?  The fact that
  78. : >: it is intermittant EVEN when the data being used has not change is what really
  79. : >: has me puzzled.
  80. : >: 
  81. : >: Any clues appreciated ;-)
  82. : >: 
  83. : >: Thanks,
  84. : >: 
  85. : >: -Dave.
  86. : >: 
  87. : >: 
  88. : >: ---------------------------------------------------------------------------
  89. : >: David J. Kaplan                                             djk@sei.cmu.edu
  90. : >: Software Engineering Institute                         dk3g+@andrew.cmu.edu
  91. : >: Carnegie Mellon University                                   (412) 268-7736
  92. : >
  93. : >Regards,
  94. : >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  95. : >Jan Diesel                                       |          jwd@rivm.nl
  96. : >Informatics Service Centre                       |  tel. ++31 30 742067
  97. : >P.O.Box 1, 3720 BA  BILTHOVEN, the Netherlands   |  fax. ++31 30 282316
  98. : >RIVM - National Institute of Public Health and Environmental Protection
  99. : 
  100. : 
  101. : -- 
  102. : 
  103. : Steve Caswell           |   (404) 448-7727    |  "The opinions expressed are my
  104. : Principal Consultant    |   sfc@tpghq.com     |   own.  They may not be perfect,
  105. : The Palmer Group        |   uunet!tpghq!sfc   |   but they're all I've got."
  106.  
  107. --
  108. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  109. Jan Diesel                                       |          jwd@rivm.nl
  110. Informatics Service Centre                       |  tel. ++31 30 742067
  111. P.O.Box 1, 3720 BA  BILTHOVEN, the Netherlands   |  fax. ++31 30 282316
  112. RIVM - National Institute of Public Health and Environmental Protection
  113.