home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / database / sybase / 729 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  4.3 KB

  1. Path: sparky!uunet!olivea!sgigate!odin!bondo.corp.sgi.com!lmcgee
  2. From: lmcgee@bondo.corp.sgi.com (Lee McGee)
  3. Newsgroups: comp.databases.sybase
  4. Subject: Re: syslogs
  5. Message-ID: <1993Jan23.000958.26732@odin.corp.sgi.com>
  6. Date: 23 Jan 93 00:09:58 GMT
  7. References: <C0wL3t.460@cmptrc.lonestar.org> <28244@sybase.sybase.com> <1993Jan22.180412.8847@odin.corp.sgi.com> <1993Jan22.192334.16373@sunova.ssc.gov>
  8. Sender: news@odin.corp.sgi.com (Net News)
  9. Reply-To: lmcgee@sgi.com
  10. Organization: Silicon Graphics, Inc., Mountain View, CA, USA
  11. Lines: 64
  12. Nntp-Posting-Host: bondo.corp.sgi.com
  13.  
  14. In article <1993Jan22.192334.16373@sunova.ssc.gov>, jbaron@higgs.ssc.gov (Jeff Baron) writes:
  15.  
  16. (Re:  the topic, what's in a syslog...)
  17.  
  18. |> Oh sure.  Do we think that the log is a valuable part of the Sybase
  19. |> product?  Do we think that Sybase itself has some vested interest in
  20. |> protecting its product?  Do *other* companies give out data structure
  21. |> definitions (and source code?) for their products?
  22.  
  23.  
  24. Yes. Yes.  and Yes.  Check Apple Macintosh.  Unix.  Open systems in general.
  25.  
  26. But anyway, we as application users really have no interest in what the data structures _actually_ are or how they are implemented.  That is stuff for the engineer.  We _do_ have an interest in what gets into the log from a transaction (ever had one fill up on you?).  And an interest in running the utilities to give us a formatted printout, or interpretation, of the log.  If the vendor has something proprietary to hide, they can always hide it in the interpretation.
  27.  
  28. |> How do you expect it to provide you with information about performance 
  29. |> analysis in the case of your 10-update example?  
  30.  
  31. Here is exactly how.  I will say no more.
  32.  
  33. The SYBASE transaction log seems to contain a row for each physical data page
  34. or index page IO performed in the database(s) by a transaction.  It also shows the spid and sometimes the suid that dperformed the transaction.  Useful stuff.
  35.  
  36. Some of the "generic" types of log records available available are:
  37.  
  38.     begin tran
  39.     .
  40.     .
  41.     table insert
  42.     table delete
  43.     index insert
  44.     index delete
  45.     .
  46.     .
  47.     (note that an UPDATE is really a delete and an insert!)    
  48.     .
  49.     .
  50.     etc.
  51.  
  52. There are lots of types of log records in Sybase 4.0.1.  An analysis of
  53. a transaction, start to finish, by reading through the formatted transacttion log is both interesting and sometimes useful ("aahhhh.  Everytime I update a row it moves off-page and I get <nnn> index inserts and <nnn> index deletes for 1 update!  No wonder it is slow!"). Stuff like that.  
  54.  
  55. Then the DBA recommends a different index strategy to cut down on the index 
  56. insert and delete processing that goes on internally, And the application runs much faster.  
  57.  
  58. So give us poor DBAs a break!  We're just doing a job here!  When tech support,
  59. or a sales technical rep, reads us a script or command on the telephone, or performs it in front of our eyes in the process of solving a problem for us, then surely they must realize that the "inside information" has _just_ become public knowledge.  And that it has been written down or recorded on the users' systems for later use.  Lots of users have this information.  We have seen "dbcc log (param, param,...param)" run.  We have seen its output.  We know what is possible.  
  60.  
  61. While that might arguably be a Sybase internal security, or
  62. trade secret, problem, should it be our concern as users of the product?  If the contract says something to that effect, then yes, I stand corrected and chastised.  Yet, I think not.  And I've never felt a need to "not repeat" something learned from a Sybase technical rep in the process of solving a 
  63. problem or making a system run better.  After all, Sybase, when tuned right, has some of be the fastest and most consistent performance out there in the DBMS marketplace and that is the true trade secret.  
  64.  
  65. Some "insider information" has even appeared in this newsgroup from time to time (not from here, from other sources!), and we have learned heretofore unimaginable techniques from our other colleagues who post to the newsgroups.  
  66.  
  67. Next topics? - Special recovery techniques, trace flags, data page patching?  
  68.         Special "set <blah blah> on" SQL commands? It's all there
  69.             in the tech support bag of tricks.  Listen and learn.  
  70.     
  71.     
  72. -- 
  73. Your Data Base Administrator:  LEE MCGEE
  74.               --    safe       -- 
  75.                 --  reliable     --         
  76.                --  courteous    --    
  77.            -- flameproof    --
  78.