home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / informix / 2924 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.5 KB
  1. Path: sparky!uunet!gatech!emory!emory!not-for-mail
  2. From: jparker@hpbs2776.boi.hp.com (Jack Parker)
  3. Newsgroups: comp.databases.informix
  4. Subject: Carl Wuebkers 'recovery' problem.
  5. Date: 11 Jan 1993 15:33:04 -0500
  6. Organization: Mailing List Gateway
  7. Lines: 41
  8. Sender: walt@mathcs.emory.edu
  9. Distribution: world
  10. Message-ID: <1isli0INNfvb@emory.mathcs.emory.edu>
  11. Reply-To: jparker@hpbs2776.boi.hp.com (Jack Parker)
  12. NNTP-Posting-Host: emory.mathcs.emory.edu
  13. X-Informix-List-ID: <list.1771>
  14.  
  15. Folks,
  16.  
  17. After perusing the responses to Carl's problem I realized that no-one
  18. has come up with this answer, so here it is.  
  19.  
  20. We had this problem over and over again and started re-creating it on
  21. purpose to devise a solution.  The solution wound up being to lower the high
  22. water marks by 10%:
  23.  
  24. LTXHWM          70              # Long TX high-water mark (percent)
  25. LTXEHWM         80              # Long TX exclusive high-water mark (percent)
  26.  
  27. I also bumped the log files to incredible sizes, (24 500k logs, we log to disk,
  28. - since this is a development machine I have some free rein on disk - tee hee.
  29.  
  30. Bumping the log files didn't solve it on it's own since no matter how big
  31. your logs are, sooner or later someone is going to do a 
  32. 'LOAD FROM xxx INSERT INTO...' which will throw you into this situation, but
  33. the high water marks made a big difference.
  34.  
  35. I also started educating the users NOT to use 'LOAD FROM...' but rather dbload
  36. instead.  There are a couple of other statements which will really cramp
  37. your style - like updates on a big table which don't lock the table first.
  38. Generally get your users - and yourself - to use common sense and avoid
  39. Loing Transaction situations.  You could even turn off logging for BAD 
  40. transactions.  When you do wind up getting locked up in the logfiles - DON'T
  41. to that kill thing.  Be very careful to check latches and whether the 
  42. transaction has gone 'critical' before shooting it.  On-Line has eventually
  43. killed long transactions for me when I couldn't shoot them myself - but
  44. every time someone has shot a 'critical' transaction we've been in (In
  45. Big George's Words) deep doo-doo.
  46.  
  47. Yeah, I know that most of you already know this but what the hey.
  48.  
  49. j.
  50. _____________________________________________________________________________
  51. Jack Parker - Contractor               | 
  52. Hewlett Packard, BSMC Boise, Idaho, USA|    I forget how much I remember
  53. jparker@hpbs2651.boi.hp.com            |           
  54. (208) 323-5388 (W)  (208) 384-1623 (H) |
  55. _____________________________________________________________________________
  56.