Re: Adjusting to DB2

Comments embedded.
Mark A wrote:
> <fitzjarrell_at_cox.net> wrote in message
> news:1130184163.777172.30390_at_g49g2000cwa.googlegroups.com...
> >
> > It was mentioned because YOU mentioned in one of your posts in this
> > thread that such instrumentation DOES exist. So, a correction to your
> > misinformation regarding instrumentation in DB2 was in order. And it's
> > interesting that you now claim the DBAs have nothing to learn with
> > regard to DB2 instrumentation, when before you claimed a robust set of
> > tools that somehow vanished between your post quoted by Mr. Wedemeijer
> > and Mr. Wedemeijer's response. As Mr, Wedemeijer stated:
> >
> > "This typically shows that Mark does not now what he is talking about,
> > ..."
> > After reading your posts in this newsgroup I would agree with this
> > assessment.
> > David Fitzjarrell
> >
> I initially admitted that I did not exactly know what was meant by
> "instrumentation". My answer was based on my best guess as to what it was,
> which was apparently wrong, but it was not an attempt to be misleading.
>

Yet you responnded anyway, in a rather authoritative fashion, that the claim was false. If you do NOT know about that which is being discussed, is it not better to not respond at all?

> I have worked with DB2 for z/OS extensively since 1987 (version 1.2). I have
> taught many DB2 for z/OS classes and I am quite knowledgeable about DB2
> performance tuning. I am currently IBM certified DBA on DB2 V7 for z/OS. I
> am not familiar with the instrumentation feature that Bjarke mentioned.

Which proves DB2 is not a single code base, but many, depending upon the platform. And that you are unfamiliar with many of the DB2 releases. It is even more interesting that Oracle IS a single code base, and that features found in Standard Edition on Linux are also found in Standard Edition for Windows, Standard Edition for Unix and Standard Edition for OS/X. The same applies to the Enterprise Edition of Oracle.

> If
> he means trace records, then I don't use them for performance tuning and I
> don't think that most DBA's use them.

Interesting. Why do you not use them? And are you claiming familiarity with the legion of DB2 DBAs, so much so that you can speak for them in their absence? You've tried commenting on things you know little about in a prior post, and you were proven incorrect. I think I'd be a bit more cautious when attempting to make sweeping generalisations.

> I make extensive use of the explain
> function. I suppose this is a matter of personal preference as to whether
> instrumentation is used by DBA's (and also matter of whether one purchases a
> product like DB2 PM to read the trace records). In fact, although the better
> DBA's do performance tuning, the majority of DBA's (DB2 and Oracle) either
> don't do performance tuning or don't do it very well, even for home grown
> applications.
>

You may speak for the DB2 community (and I'd be hesitant to make such claims were I you with your history in this newsgroup and, in particular, this thread) however the Oracle community has been quite active in promoting proper tuning methodologies and techniques, and in providing workable tools to assist in this endeavour. Do NOT claim to speak for any group of DBAs outside of your limited circle of reference, since even within said circle you are prone to error.

> In this particular thread (an Oracle DBA wants to know how hard it would be
> to learn how to support a DB2 application), since DB2 for Linux, UNIX, and
> Windows does not have this "instrumentation" feature, then obviously a DBA
> working on that DB2 platform does not need to know about it (since it does
> not exist). That seems fairly logical to me.

Again, your 'logic' is seriously flawed, as the absence of such tools and instrumentation IS of concern to those who are adding yet another DBMS to their scope of knowledge. Not having utilities one has grown accustomed to in a different, respected DBMS is of vital interest to those in need of learning how to manage and tune it. Your cavalier 'the tools don't exist, so don't concern yourself with their absence' attitude is clearly irresponsible, especially when no substitute techniques have been offered. Yes, YOU use the explain function and 'tune' accordingly, however those who are accustomed to having trace facilities and the tools to process these files will find your methodology lacking, for good reason. Obviously DB2 can produce usable trace files; that it is an extra-cost option to be able to process such traces should NOT deter you from mentioning such utilities. Then, you don't use the trace files, and I still am wondering why. Would not a closer look at the internal workings of DB2 and it's optimiser provide much clearer insight into many tuning tasks? I would not want to attempt to tune an Oracle instance without some level of session tracing. Then, I prefer to solve the root cause of the performance problem, not simply try to make an end-run around it. In my mind using only the explain function is doing but half of the job. Possibly that's acceptable in your world, it most certainly is not in mine.

David Fitzjarrell Received on Tue Oct 25 2005 - 10:30:29 CDT