Re: SQL Server to Oracel

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.

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

> > Jeez, makes me
> > nostalgic.
>
> see a doctor; perhaps the rags slipped! got the OMLET treatment or
> both!
>

We have been getting the OMLET treatment, from its creator, and it's not been pleasant nor fruitful. It's been juvenile, sophomoric, obscene, degrading and useless. If you cannot behave as an adult, then leave. You originally attacked Howard J. Rogers, then myself, then Daniel Morgan, then Joel Gary and, finally, Mladen Gogala. Any post any member of this group of individuals makes you see fit to insult, in a crude and inappropriate manner. This needs to stop, now.  The regulars in comp.databases.oracle.server, and any other Oracle newsgroup, will thank you for it.

> >
> > Note to all Oracle professionals: re-read the manuals for new
> > versions, and pay attention to people who point out errors.
>
> I guess Oracle profs are capable of do that by themselves. Do not
> insult them or their intel. with your crab.
>

Joel didn't insult anyone; it's you who's insulting. And, if anyone is posting crap to this newsgroup, it's you, Amjad. No one else has stooped to your level of attack, as we all know better. Never argue with an idiot; he brings you down to his level then beats you with experience. You're trying just that, Amjad, and no one is taking the bait. Leave now, while you still have a shred (at most) of decency left. You have no reputation, as you killed that with your continued harassment of the newsgroup members.

David Fitzjarrell

> >
> > jg
Received on Tue Jun 29 2004 - 23:55:24 CDT