From: lmcgee@bondo.corp.sgi.com (Lee McGee)
Newsgroups: comp.databases.sybase
Subject: Re: syslogs
Date: 23 Jan 93 00:09:58 GMT
Reply-To: lmcgee@sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA, USA

In article <1993Jan22.192334.16373@sunova.ssc.gov>, jbaron@higgs.ssc.gov (Jeff Baron) writes:

(Re:  the topic, what's in a syslog...)

|> Oh sure.  Do we think that the log is a valuable part of the Sybase
|> product?  Do we think that Sybase itself has some vested interest in
|> protecting its product?  Do *other* companies give out data structure
|> definitions (and source code?) for their products?


Yes. Yes.  and Yes.  Check Apple Macintosh.  Unix.  Open systems in general.

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.

|> How do you expect it to provide you with information about performance 
|> analysis in the case of your 10-update example?  

Here is exactly how.  I will say no more.

The SYBASE transaction log seems to contain a row for each physical data page
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.

Some of the "generic" types of log records available available are:

	begin tran
	.
	.
	table insert
	table delete
	index insert
	index delete
	.
	.
	(note that an UPDATE is really a delete and an insert!)	
	.
	.
	etc.

There are lots of types of log records in Sybase 4.0.1.  An analysis of
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.  

Then the DBA recommends a different index strategy to cut down on the index 
insert and delete processing that goes on internally, And the application runs much faster.  

So give us poor DBAs a break!  We're just doing a job here!  When tech support,
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.  

While that might arguably be a Sybase internal security, or
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 
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.  

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.  

Next topics? - Special recovery techniques, trace flags, data page patching?  
		Special "set <blah blah> on" SQL commands? It's all there
	        in the tech support bag of tricks.  Listen and learn.  
	
	
-- 
Your Data Base Administrator:  LEE MCGEE
	   	   --    safe       -- 
 	           --  reliable     -- 		
	           --  courteous    --	
		   -- flameproof    --