home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / 5740 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!sdd.hp.com!mips!mips!munnari.oz.au!metro!extro.ucc.su.OZ.AU!rjmartin
  2. From: rjmartin@extro.ucc.su.OZ.AU (Trilogy Business Systems)
  3. Newsgroups: comp.databases
  4. Subject: Re: Sybase and Interactive woes
  5. Message-ID: <rjmartin.711764896@extro.ucc.su.OZ.AU>
  6. Date: 22 Jul 92 00:28:16 GMT
  7. References: <1992Jul16.173500.1075@asc386>
  8. Sender: news@ucc.su.OZ.AU
  9. Organization: Sydney University Computing Service, Sydney, NSW, Australia
  10. Lines: 37
  11. Nntp-Posting-Host: extro.ucc.su.oz.au
  12.  
  13. mosmith@asc386 (Matt Smith) writes:
  14.  
  15. >We are currently using version 3.2 of Interactive and
  16. >version 4.2 of Sybase.  As the subject implies, we seems to be having
  17. >great difficulty keeping the Sybase server up.  If there is anybody
  18. >out there using this configuration or could suggest a better one, I would
  19. >really like to hear from you.
  20.  
  21. We are currently running 4.2 on SCO ODT 1.1 and SCO Unix 3.2., and while we 
  22. have had our fair share of problems, the system is up around 99%+ of the time.
  23. Our local sybase people are fairly helpful, although when we get really
  24. hairy problems they are referred back to the U.S.
  25.  
  26. Something to be really careful about is the number of streams parameters 
  27. configured in the kernal. The first set of release notes were ** WRONG ** 
  28. about how many to set up (I think they just thought of some numbers that
  29. would never be exceeded). You can use the crash command, and then use strstat
  30. to see how these are going, also make sure you have a good reliable maths 
  31. co-processor (387 compatable), apparently this can cause problems. One last
  32. thing to look at is the amount of available free ram, and if all else fails,
  33. try dumping the database, re-install, and start from scratch. We had some 
  34. problems with a demo machine that used unix files as the database devices,
  35. and occasionally it wouldn't be able to open the log device, thereby marking
  36. the associated database as being hopelessly corrupt. I then manually changed
  37. the database status. This happened a few times, and although DBCC came up
  38. reporting no problems, we finally got to the point where the server would
  39. crash at the least excuse. I re-installed with BCP'd data and re-loaded the
  40. triggers etc, and no more problems. We ** think ** that the reason it was
  41. crashing in the first place was because we were running NFS, or, that
  42. we had changed NOFILES from 60, which is a bit of a No No in that release of
  43. SCO ODT
  44.  
  45. Hope this helps.
  46.  
  47. John Martin
  48. Software Manager
  49. Trilogy Business Systems 
  50.