home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / sybase / 571 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  1.3 KB
  1. Path: sparky!uunet!wupost!spool.mu.edu!agate!ucbvax!mtxinu!sybase!ben
  2. From: ben@sybase.com (Benjamin von Ullrich)
  3. Newsgroups: comp.databases.sybase
  4. Subject: Re: Recovering from a log segment full condition (why model's log can fill up)
  5. Message-ID: <27461@sybase.sybase.com>
  6. Date: 26 Dec 92 15:23:00 GMT
  7. References: <dave.724703604@rincon> <1992Dec21.223620.26626@gtech.com> <WFINNERT.92Dec21194611@larry.shearson.com> <1992Dec22.162739.5049@gtech.com>
  8. Sender: news@Sybase.COM
  9. Organization: sybase, inc., emeryville-across-from-SF, ca
  10. Lines: 17
  11.  
  12. up to release 4.8, sql server stored tempdb's next object_id in the log
  13. of the model database.  i don't remember exactly why this was
  14. necessary, but i think it has something to do with avoiding re-issuance
  15. of object_ids that may be in stored procedures and/or transaction logs
  16. of all server databases.  since model is copied into tempdb at boot
  17. time, it seemed logical to store the next object id in model.  all that
  18. was logged was a 4-byte integer, so it could take months for the log in
  19. model to fill up.
  20.  
  21. this problem was fixed in version 4.8 . the next object id is now stored
  22. elsewhere.
  23.  
  24. --
  25. ..ben
  26. ------
  27. Benjamin von Ullrich         only i do the talking here -- not my employer.
  28. ben@sybase.com                   {pyramid,pacbell,sun,lll-tis}!sybase!ben
  29.