However, the problem with Niemich' book is that it contains incorrect information which will lead you to wrong conclusions and down paths you shouldn't tread. For instance, on page 7 at the bottom, it's stated that if you raise the buffer cache hit ratio from 94 or 97 (or whatever) then you can triple your throughput. That's of course absolutely wrong and misleading at the same time. A high bchr is a rather sure sign that you have grossly inefficient SQL running - and there's no direct link between bchr and performance, by the way. Now, that kind of advise would send a lot of people out hunting for high hit ratios when in fact their problems lie somewhere else. And so on and so forth. The list is very long of grave errors or misleading statements in that book. Sorry about that. I haven't met Niemich himself so far, but I'm sure he's a very nice guy like everybody else out there in Oracle land. His "others will need oxygen" attitude, however, might mean something else to the rest of us than intended...
The technique for estimating db_block_buffers is just as flawed. We see way too high db_block_buffers practically everywhere we go.
Interpreting the bstat/estat stuff is probably correct as such, but if you don't use time-based measurement methods there is NO way to find the correct bottlenecks, estimate their impact, prioritize, etc. IBM found that out in the mid-80's and instrumented their mainframe environments. Oracle instrumented the kernel in V7.0. It's about time people stop using this checklist tuning thing, which is such a waste of time and energy - and most often will end up with the wrong conclusions for you.
Cary Millsap has published a very nice paper called "Why a 99% buffer cache hit ratio is NOT ok". Check it out. Cool stuff. Most SQL statements that perform badly have an extremly high cache hit ratio, by the way... The very same myth about the need for a high bchr is, interestingly enough, alive and well among SQL Server instructors, DBA's and writers. Perhaps that fact alone can get people to stop focusing on this nonsense in the Oracle world :-))).
Bjorn Engsig's paper on interpreting StatsPack can be downloaded from, among other places, Anjo's OraPerf.com site - and that paper effectively explains how little you need to know in order to interpret the bstat/estat or StatsPack output. You'll be surprised.
And then there's this YAPP paper from Anjo. It just might be available on OraPerf - you never know :-))).
The best thing to do with regard to using the wait interface (the only way to go) is to find one of the many scripts that collect the correct information (or use Bjorn Engsigs paper about StatsPack), then ask questions about the output on this list, for instance. You'll also find, that if you type the full wait event name in between double quotes on Google.com you'll usually find good information about it.
Best regards,
Mogens
K Gopalakrishnan wrote:
Samir,
I cannot resist anymore. I was the one who raised this issue in this list and few other discussion groups…in which few of Rich’s colleagues also participate. It is one of the incorrect irrelevant books in the Oracle Performance Tuning. I can find ludicrous errors in every chapter (well.. some times in every page) .. Not typo errors but also conceptual errors. Even the one you are mentioning (using X$BH table to monitor buffer use). It is another immature recommendation (in case if you are mentioning the one explained as “TIP” in page 607. It is a bunch of printed papers nicely bound as a book sometime I use it to keep my laptop to adjust the height while working with the docking station.
I had written to Rich long back (when he published the book) pointing all these errors and got a reply from Rich saying “It is my first book. It will be corrected in my next edition”. We have discussed this in a big way in this list (Me, Yong Huang, and few others). If you have time you can search those mails in the archives of the lists…
Let me see whether those mails are still with me. If I find them I will forward that to you.
Best Regards,
K Gopalakrishnan
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of SARKAR, Samir
Sent: Friday, February 01, 2002 2:25 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Oracle Tunning
Well Mogens, Niemiec's book does have its plus points as well. What we basically want from Oracle
is improved response times and faster performance........which is all about how many hits we r getting
and improving the hit ratio is something any DBA will try to attain.
There is a wonderful technique in his book about how to estimate the size of the db_block_buffers
by mythically raising it by a certain amount and checking the hit ratio or decreasing it and checking
the impact. This way, we can arrive at an optimum value for the db_block_buffers.
How to interpret the UTLESTAT/UTLBSTAT statistics r very clearly and lucidly explained as r the various
join methods, improper use of indexes including index suppression, using the x$bh table to monitor buffer use,
a very clear explanation of the Explain Plan, new tips for Oracle 8/8i, how to use PL/SQL for better performance etc.
The best part is the book has lots of very useful queries and screen reprints to help us understand the
scenario better.
Am not saying that it is the best tuning book in the market but the techniques of tuning r very clearly explained
in it.
Tuning by wait events is still very arcane and not explained clearly exactly how to do it in many books though
I haven't read the 101 book. I still find it difficult to properly interpret all the various wait events and latch contention
and how to go about tuning them And until Steve Adams comes out with his advanced performance tuning book,
we will all have to wait.
Samir
Samir Sarkar
Oracle DBA - Lennon Team
Schlumberger S ema
Email : [EMAIL PROTECTED]
[EMAIL PROTECTED]
Phone : +44 (0) 115 - 957 6217
EPABX : +44 (0) 115 - 957 6418 Ext. 76217
Fax : +44 (0) 115 - 957 6018-----Original Message-----
From: Mogens Nørgaard [mailto:[EMAIL PROTECTED]]
Sent: 31 January 2002 18:39
To: Multiple recipients of list ORACLE-L
Subject: Re: Oracle TunningCommit; :-)
In my opinion, you shouldn't spend your money on buying the Niemich book. It's full of errors (increase the buffer cache hit ratio, for instance) and the wrong approach (no time-based measurement method, just checklist after checklist).
Buy 101 by Gaja. Then buy Tom Kyte's One-On-One book for general fantastic advise on anything. Then go to oraperf.com (Anjo), hotsos.com (Millsap), ixora.com.au (Steve Adams) and Jonathan Lewis' website (can never remember the adresse). Or go to MiracleAS.dk and find all these links, including the book links.
Mogens
Miracle A/S
Denmark
Farnsworth, Dave wrote:
Binay,
I totally agree with this recommendation from Jared for a tuning book.
Read the first three chapters, stop and re-read them. And if you play
your cards right you can even get a question answered by an author on
this list. Cool, eh.
Dave
-----Original Message-----
Sent: Tuesday, January 29, 2002 3:05 PM
To: Multiple recipients of list ORACLE-L
Start with 'Oracle Performance Tuning 101', available at an
amazon.com near you.
Jared
On Tuesday 29 January 2002 09:10, BINAY.KUMAR@p onl.com wrote:Hi Everyone
Can anyone suggest me some very good book on Oracle Tunning.Please onlymention those books which you think is really worth purchasing
Binay Kumar
Oracle Cerified DBA
London
-------------------------------------------------------------------
The contents of this e-mail are confidential to the ordinary user
of the e-mail address to which it was addressed and may also be
privileged. If you are not the addressee of this e-mail you should
not copy, forward, disclose or otherwise use it or any part of it
in any form whatsoever. If you have received this e-mail in error
please notify us by telephone or e-mail the sender by replying to
this message, and then delete this e-mail and other copies of it
from your computer system. Thank you.
We reserve the right to monitor all e-mail communications through
our network.
___________________________________________________________________________
This email is confidential and intended solely for the use of the
individual to whom it is addressed. Any views or opinions presented are
solely those of the author and do not necessarily represent those of
SchlumbergerSema.
If you are not the intended recipient, be advised that you have received this
email in error and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited.
If you have received this email in error please notify the SchlumbergerSema Helpdesk by telephone on +44 (0) 121 627 5600.
___________________________________________________________________________
