home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / database / sybase / 737 < prev    next >
Encoding:
Text File  |  1993-01-25  |  3.8 KB  |  82 lines
  1. Newsgroups: comp.databases.sybase
  2. Path: sparky!uunet!shearson.com!newshost!wfinnert
  3. From: wfinnert@larry.shearson.com (Warren Finnerty)
  4. Subject: Re: syslogs
  5. In-Reply-To: lmcgee@bondo.corp.sgi.com's message of 23 Jan 93 00:09:58 GMT
  6. Message-ID: <WFINNERT.93Jan25122704@larry.shearson.com>
  7. Sender: news@shearson.com (News)
  8. Organization: Lehman Brothers
  9. References: <C0wL3t.460@cmptrc.lonestar.org> <28244@sybase.sybase.com>
  10.     <1993Jan22.180412.8847@odin.corp.sgi.com>
  11.     <1993Jan22.192334.16373@sunova.ssc.gov>
  12.     <1993Jan23.000958.26732@odin.corp.sgi.com>
  13. Date: Mon, 25 Jan 1993 17:27:04 GMT
  14. Lines: 66
  15.  
  16. In article <1993Jan23.000958.26732@odin.corp.sgi.com> lmcgee@bondo.corp.sgi.com (Lee McGee) writes:
  17.  
  18. >   In article <1993Jan22.192334.16373@sunova.ssc.gov>, jbaron@higgs.ssc.gov (Jeff Baron) writes:
  19. >
  20. >   (Re:  the topic, what's in a syslog...)
  21. >
  22. >   |> Oh sure.  Do we think that the log is a valuable part of the Sybase
  23. >   |> product?  Do we think that Sybase itself has some vested interest in
  24. >   |> protecting its product?  Do *other* companies give out data structure
  25. >   |> definitions (and source code?) for their products?
  26. >
  27. >
  28. >   Yes. Yes.  and Yes.  Check Apple Macintosh.  Unix.  Open systems in general.
  29. >
  30. >
  31. >   So give us poor DBAs a break!  We're just doing a job here!  When tech support,
  32. >   or a sales technical rep, reads us a script or command on the telephone, or 
  33. >   performs it in front of our eyes in the process of solving a problem for us, 
  34. >   then surely they must realize that the "inside information" has _just_ become 
  35. >   public knowledge.  And that it has been written down or recorded on the users' 
  36. >   systems for later use.  Lots of users have this information.  We have seen 
  37. >   "dbcc log (param, param,...param)" run.  We have seen its output.  We know 
  38. >   what is possible.  
  39. >
  40. >   While that might arguably be a Sybase internal security, or
  41. >   trade secret, problem, should it be our concern as users of the product?  
  42. >   If the contract says something to that effect, then yes, I stand corrected 
  43. >   and chastised.  Yet, I think not.  And I've never felt a need to "not repeat" 
  44. >   something learned from a Sybase technical rep in the process of solving a 
  45. >   problem or making a system run better.  After all, Sybase, when tuned right, 
  46. >   has some of be the fastest and most consistent performance out there in the DBMS 
  47. >   marketplace and that is the true trade secret.  
  48. >
  49. >   Some "insider information" has even appeared in this newsgroup from time to time 
  50. >   (not from here, from other sources!), and we have learned heretofore unimaginable 
  51. >   techniques from our other colleagues who post to the newsgroups.  
  52.  
  53. I suspect that the reason that there is no documentation on these commands 
  54. mostly revolves around not wanting to use the resources to upgrade/cleanup/improve
  55. these commands to the point where they can be supported. Additionally since
  56. persons would be writing software using the command they would have to be
  57. ported to new versions of the server. These commands *can* crash your server
  58. if you make even a small mistake. I would rather SYBASE concentrate on working
  59. on future improvements ( monitor server, etc ) rather than handing out 
  60. dangerous commands to novice users and wasting tech support time fixing
  61. the problems that are created by that. I you do enough heavy-duty server
  62. work you *will* come across these commands much as you have stated.
  63.  
  64. NB: Most SYBASE guru types have signed 10 billion non-disclosures
  65. and are unlikely to post such internal details.
  66.  
  67. Happy hunting
  68.  
  69.  
  70.  
  71. >   -- 
  72. >   Your Data Base Administrator:  LEE MCGEE
  73. >              --    safe       -- 
  74. >              --  reliable     --         
  75. >              --  courteous    --    
  76. >              -- flameproof    --
  77. --
  78. warren finnerty      | 388 Greenwich St.
  79. Lehman Brothers      | NYC NY 10013
  80. "Back off man!"      | wfinnert@shearson.com
  81.  
  82.