Re: Adjusting to DB2

Comments embedded.
Mark A wrote:
> <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.
>

And I'm certain you can prove that with code sections from both DB2 and Oracle.

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

Thus presuming the problem is related to SQL, not some other aspect of the database or server configuration, which is yet another false assumption on your part. I have personally seen, and tuned, systems where the SQL was fine, yet the system performed poorly; it was tuned by access to the Oracle Wait Interface and by session tracing, as well as Statspack reports run at regular intervals. Your explain function can't assess network issues, disk problems or improper file location, all problems which can, and do, affect real production systems.

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

I'm sorry for you that IBM can't provide a suite of utilities to trace and tune DB2 databases without resorting to extra-cost add-ins. Not all problems can be solved with an explain plan.

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

As I read this post I realise you're also part of that contingent if all you do to 'tune' a database is validate the SQL runs properly. I shall state again there are more problem areas in a relational database than just the SQL statements. Apparently you don't care to assess anything except poor coding by the developers, which proves that you are doing but half of the job.

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

Again, you presume all of your problems will be related to the SQL statements. And, again, this is, simply put, not true.

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

And, of course, your idea of 'problems' only involves SQL statements, as you've stated quite clearly in this post. And, as I have stated herein problem areas do not always coincide with simple SQL tuning, a concept you, apparently, fail to grasp. The Oracle Wait Interface, session tracing, explain plan utility and Statspack reports are far from 'idiot tools'. You must be confusing these with an outdated copy of Enterprise Manager, or, horror of horrors, Server Manager. Such a statement only indicates your ignorance of the wealth of information provided by such utilities, apparently because you've yet to muster the courage or wherewithall to use them. I suggest you stop trying to join into conversations where your knowledge of the subject is lacking.

David Fitzjarrell Received on Tue Oct 25 2005 - 23:14:37 CDT