home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / ingres / 2193 < prev    next >
Encoding:
Text File  |  1993-01-08  |  3.4 KB  |  74 lines

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