omlet@omlet.org wrote in message news:<dc6c1ff0.0406300739.5001ae2a@posting.google.com>...
> fitzjarrell@cox.net (David Fitzjarrell) wrote in message news:<9711ade0.0406292055.4bfaa4fe@posting.google.com>...
> > omlet@omlet.org wrote in message news:<dc6c1ff0.0406291431.ef3d9f8@posting.google.com>...
> > > joel-garry@home.com (Joel Garry) wrote in message
> > > >
> > > > "In general, if recursive calls is greater than 4 per process, the
> > > > data dictionary should be optimized and segments should be rebuilt
> > > > with storage clauses to have a few large extents. "
> > > > - OraclE 9I Performance Tuning WITH OMLET [
> > >
> > > This is a product for 8i,9i,10g! So your comments are misplaced. Self
> > > tuning; local management, undo segments and db_cache_size are not as
> > > widely used as you think. Of course, you are entitled to your opinion;
> > > you write books that you sell for $100 and as such you better be
> > > giving people their money's worth.
> >
> > If you speak of Howard J. Rogers his books DO provide people with
> > their money's worth, in many cases ten times over. Unlike you, who
> > can only write degrading and obscene verbiage to those who, with good
> > reason, disagree with your misguided methodology.
>
> I seriously doubt it! apart from my misguided tech. many sections of
> Jo Lewis book was taken verbatim from Metalink postings. Before
> writing a book, tell me how many hours you worked as an oncall dba!
> how many production databases you have recovered! how many databases
> you constructed while others are watching, ....etc.
>
> >
> > >
> > > The book is about OMLET and tuning Oracle with OMLET; as such, only
> > > queries that made it into a version are reflected in the book. It is
> > > not targeting general audience.
> > >
> >
> > You're still using unreliable hit ratios;
>
> Back to Gaja's bullshit; A high ratio by itself may hide two large
> qtys when divided; OK! Great; Bigger than Texas!
>
> Publish few papers about this; try CACM as I am an associate editor
> for it! I would publish your great works!
>
> At the end; a bad hit ratio means you have a serious problem. your
> logical reads are low compared to physical reads. Again LOW LOW LOW
> LOW LOW LOW LOW LOW LOW LOW LOW ratio; you get it! you big jumble Q of
> of fat to meat! You must admit that is low ratio; and that is a
> problem; so get off your feet; leave your computer; play a little with
> your tonka; and convince yourself that LOW ratios are really terrible.
> Consult your mother and see what she says?
>

> A 47 years old female like you should be having good days and happy
> nights. You are getting NONE. I forgot; you may converted to a male.
> Anyhow it always help to look for the Butt-neck.
>

> > I wouldn't begin to consider
> > that tuning Oracle. Hit ratios hide information; all ratios do. This
> > percentage, that percentage ... it's all fluff and nonsense. I've
> > seen databases with 99.999% db buffer cache hit ratios and they STILL
> > weren't tuned because the SQL reused in that 99.999% success rate was
> > simply bad to begin with. 99,999 calls to one bad SQL statement
> > doesn't represent tuning to me, it represents poor methodology. Truly
> > the only way to tune Oracle is to determine WHERE the bottleneck is
> > (and this doesn't happen using hit ratios) and correcting that
> > bottleneck, be it SQL*Net to client/SQL*Net from client times to
> > poorly performing queries. Cary Millsap has the correct approach; I'm
> > sorry to say you don't.
> >
> > > > He even thanks Digital!
> > >
> > > I worked for Digital Rdb - the KODA group; and joined Oracle when they
> > > bought the Digital rdbms business and as such I thank Digital for
> > > doing that: having access to the Rdb code; which SQL server borrowed
> > > heavily. I added index only tables to Rdb and later to Oracle kernel.
> > > Of course your mother helped me do that; she s*** nicely!
> > >
> >
> > You joined Oracle because Oracle bought out the division you worked
> > for. So, Oracle didn't choose you from the many to be among the few,
> > you were included in the package price paid for an Oracle acquisition.
> > This is making much more sense now.
>
> Actually half the group joined Microsoft; half stayed and two joined
> Sybase. Those who joined Microsoft hit the gold pot as they released
> Windows 95. I joined Oracle for options and incentives and the chance
> to read the Oracle code.
> OMLET is the fruit;
>

fitzjarrell@cox.net (David Fitzjarrell) wrote in message news:<9711ade0.0406301657.256dcc85@posting.google.com>...
> omlet@omlet.org wrote in message news:<dc6c1ff0.0406300739.5001ae2a@posting.google.com>...
> > fitzjarrell@cox.net (David Fitzjarrell) wrote in message news:<9711ade0.0406292055.4bfaa4fe@posting.google.com>...
> > > omlet@omlet.org wrote in message news:<dc6c1ff0.0406291431.ef3d9f8@posting.google.com>...
> > > > joel-garry@home.com (Joel Garry) wrote in message
> > > > >
> > > > > "In general, if recursive calls is greater than 4 per process, the
> > > > > data dictionary should be optimized and segments should be rebuilt
> > > > > with storage clauses to have a few large extents. "
> > > > > - OraclE 9I Performance Tuning WITH OMLET [
> > > >
> > > > This is a product for 8i,9i,10g! So your comments are misplaced. Self
> > > > tuning; local management, undo segments and db_cache_size are not as
> > > > widely used as you think. Of course, you are entitled to your opinion;
> > > > you write books that you sell for $100 and as such you better be
> > > > giving people their money's worth.
> > >
> > > If you speak of Howard J. Rogers his books DO provide people with
> > > their money's worth, in many cases ten times over. Unlike you, who
> > > can only write degrading and obscene verbiage to those who, with good
> > > reason, disagree with your misguided methodology.
> >
> > I seriously doubt it! apart from my misguided tech. many sections of
> > Jo Lewis book was taken verbatim from Metalink postings. Before
> > writing a book, tell me how many hours you worked as an oncall dba!
> > how many production databases you have recovered! how many databases
> > you constructed while others are watching, ....etc.
> >
> > >
> > > >
> > > > The book is about OMLET and tuning Oracle with OMLET; as such, only
> > > > queries that made it into a version are reflected in the book. It is
> > > > not targeting general audience.
> > > >
> > >
> > > You're still using unreliable hit ratios;
> >
> > Back to Gaja's bullshit; A high ratio by itself may hide two large
> > qtys when divided; OK! Great; Bigger than Texas!
> >
> > Publish few papers about this; try CACM as I am an associate editor
> > for it! I would publish your great works!
> >
> > At the end; a bad hit ratio means you have a serious problem. your
> > logical reads are low compared to physical reads. Again LOW LOW LOW
> > LOW LOW LOW LOW LOW LOW LOW LOW ratio; you get it! you big jumble Q of
> > of fat to meat! You must admit that is low ratio; and that is a
> > problem; so get off your feet; leave your computer; play a little with
> > your tonka; and convince yourself that LOW ratios are really terrible.
> > Consult your mother and see what she says?
> >
>
> You over-generalize and oversimplify with the intent of making your
> solution the only 'correct' one. I am sorry to say you are again
> wrong
> in your assessment.

> An OLAP implementation is far more likely to have
> a LOW db buffer cache hit ratio and show no signs of that being a
> problem.

> Ad hoc queries against a data warehouse will generate a low db bufer
> cache
> hit ratio, yet not provide any evidence indicating the database is not
> tuned properly for performance. What DOES supply evidence is a
> session
> trace by enabling event 10046 at level 8 or at level 12. Such traces
> can,
> and do, provide sufficient evidence to determine IF there is a problem
> and
> WHAT is specifically causing it. Of course, a session trace has
> nothing to
> do with db buffer cache hit ratios, and generating one doesn't rely
> upon
> discovering a LOW db buffer cache hit ratio.

> As I stated earlier a
> low
> db buffer cache hit ratio may NOT be cause for concern. Your
> over-generalizing
> by attributing OLTP performance metrics to any instance designed for a
> purpose
> OTHER than OLTP is, to be honest, wrong.

> OLAP and OLTP applications
> do not
> perform the same function (which should be obvious),

> and should not be
> expected to produce the same db buffer cache hit ratios.