Re: Adjusting to DB2

<fitzjarrell_at_cox.net> wrote in message
news:1130254229.177217.168120_at_z14g2000cwz.googlegroups.com...
>
> 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.
>

DB2 for z/OS and DB2 for Linux, UNIX, and Windows are different products, not just different code bases. But since very few people use Oracle on z/OS for any serious work, then it is basically irrelevent. DB2 for Linux, UNIX, and Windows is MUCH more of single code base on those platforms than Oracle is on the same platforms.

> 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 prefer to tune all the SQL before it goes into production. There are many ways to determine problems in production without using real-time instrumentation. In the case of DB2, few of shops I worked at had DB2 PM to read the data (it costs extra).

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

I don't speak for anyone but myself. However, my experience with all DBA's (regardless of DBMS) is that most are not very good at performance tuning. That does not necessarily include the people who answer questions on this forum, but includes the entire populaton of DBA's worldwide. Most means more than 50%.

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

As I said earlier, I don't speak for others, but neither should you. There are ways to get the same information in DB2 with a Statement Snapshot to determine which SQL is not performing well. It is not real-time, but that has not been a concern for me since I can always pinpoint the problem SQL statements via the Snapshot.

If you like or need instrumentation, then I am very happy for you. I don't. I find Oracle instrumentation (never heard it called that before) is basically an idiot tool that does only a superficial job of identifying problems. Received on Tue Oct 25 2005 - 20:38:27 CDT