SQL Server to Oracel

omlet_at_omlet.org wrote in message news:<dc6c1ff0.0406300739.5001ae2a_at_posting.google.com>...
> fitzjarrell_at_cox.net (David Fitzjarrell) wrote in message news:<9711ade0.0406292055.4bfaa4fe_at_posting.google.com>...
> > omlet_at_omlet.org wrote in message news:<dc6c1ff0.0406291431.ef3d9f8_at_posting.google.com>...
> > > joel-garry_at_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. Yet you contend
this magical db buffer cache hit ratio is the be-all and end-all of tuning
expertise one would ever need, no matter the type of application an Oracle database is built to support. By inference, if a LOW db buffer cache hit ratio is BAD then a HIGH db buffer cache hit ratio MUST be GOOD,
an assessment that flies in the face of the current knowledge clearly stating
such a logical leap is a false step toward performance tuning. This is, sadly, the premise you base OMLET upon, and it's incorrect. Again you find yourself standing upon thin ice, scrambling to save yourself before the platform beneath you collapses from the weight.

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

And, again, nothing techincally relevant in your 'discussions', only rude
remarks delivered with the intent to inflame the recipient. I, for one, will
not descend to the depths you frequent as your statements say more about your
lack of character than they will ever say about me.

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

Anyone who writes an application that requires cursor_sharing be set to FORCE
so it will be easier on queries against two views is clearly in need of an
education. You ask what you can do to improve your OMLET, yet you rudely
and loudly insult those who attempt to give you such input. It appears you're
not willing to admit you're mistaken in your tuning methodology, and you're also more than willing to attempt to discredit any and all who tell you that you're wrong.

> > You originally attacked Howard J. Rogers, then myself,
> > then Daniel Morgan, then Joel Gary and, finally, Mladen Gogala. Any
>
> the Soprano's mother-kickers gang!
>
> > post any member of this group of individuals makes you see fit to
> > insult, in a crude and inappropriate manner.
>
> The posts are hardly anything compared to what you hear around the
> corner in north Dallas. Try Irvine?!
>
> Well yea! you worked in A.Carter buildings and you were not in Sabre
> in South Lake. Are you really getting that old. I should pay you some
> respect.

You cannot pay anyone any respect, as your account is woefully overdrawn
by your own arrogance. I seriously doubt you know HOW to pay anyone any
respect, since you clearly do not respect differing opinion or facts that
indicate your thought process is less than ideal. You've alienated this
entire newsgroup, which is a feat unto itself. I wouldn't expect any glowing
recommendations for your broken egg catastrophe. Besides, if OMLET is so good,
why are the links to it all of your own creation? I can find no independent
review of it anywhere, no disinterested third-party assessment of its merits,
quite possibly because it has none. Which, of course, has been reported here by more than one poster; apparently your own light shines so brightly in your own mind that it obscures the truth and paints it as fiction.

David Fitzjarrell Received on Wed Jun 30 2004 - 19:57:28 CDT