From: jbaron@higgs.ssc.gov (Jeff Baron)
Subject: Re: syslogs
Reply-To: jbaron@higgs.ssc.gov (Jeff Baron)
Organization: Superconducting Super Collider Lab
Date: Mon, 25 Jan 1993 16:48:25 GMT

In article <1993Jan23.000958.26732@odin.corp.sgi.com>, 
				lmcgee@bondo.corp.sgi.com (Lee McGee) writes:
- 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.

I disagree.  To put a database package, such as Sybase or Oracle, or
most *any* canned package, such as Excel, or Windows, and
compare them to operating systems, is like comparing apples to
oranges.   Companies open up their products for one reason- to sell
more of them, or of another product.  Unix evolved in this way
because people wanted an open system before they'd commit to it, for
obvious reasons.  Do people feel the same way about database systems?
I'd feel more sympathy when many people decide that Sybase is 
going to be the standard database engine for the future.  I won't
hold my breath, though.

And exactly how much documentation do Apple and Microsoft provide?
Well, we know about Microsoft, now being involved in the antitrust
suit alleging advantages regarding undocumented calls that in-
house development groups had information about.

This is not to say that an open system would not be better in the
short run for the user.  It's just that the users plans are not
always in the best interest of the software manufacturer.

- 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.

[example deleted]

I understand that you can examine the log and find updates and inserts 
and the like.  But what about select statements?  Do they not count?
I'll agree that a deconstructed log can be a useful tool, but it is 
hardly a panacea.

- 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 t- hat 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.  

Well, you can give someone enough rope, and they'll hang themselves,
I suppose.  Last week, with details posted to this group in an earlier
article, I had to go into a database using the 'dbcc extentzap' command
to drop a corrupt object.  Whould I do that again on my own?  No.
What if extentzap changes from 4.9.1 to 4.9.2 or 5.0, and I don't
know about it?

I think that there is a pretty serious religious issue at stake here.
I think that I'm fairly good at database systems design, and I'm an
okay DBA.  But that doesn't mean that I make use of every single 
dblib call, or that the ones that I do use I use in the most effective
way.  What it *does* mean is that the steps that I take, in both
design and coding, are within the rules, so to speak, and simple. 
My systems can be understood by their design.

While I still work here, the code is simnple and easy to understand, 
and it works all of the time.  And when I leave, my own log table
of database changes, generated from all of those triggers, is going 
to be a lot easier for the next person to understand than some 
program that deciphers a transaction log to provide the same
information

- 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.  

Use it at your own risk, I say.  You want to 'zap' your database?
I'm not one to complain, and I find horror stories, like my own, to
be fascinating in their own way.

--
Jeff Baron
jbaron@gauss.ssc.gov
Newsgroups: comp.databases.sybase