Re: SQL Server to Oracel

fitzjarrell_at_cox.net (David Fitzjarrell) wrote in message news:<9711ade0.0406301657.256dcc85_at_posting.google.com>...
> 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.

Once a Big Texas Cockroach caught an Antz by the corner and said see my oversized cock and think ?!.

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

There is no problem! Do you want to invent one?! Can happen when doing full table scans. Let me tell you about the ticketing and price forcasting database
you are very aware of: We moved it to a Starfire 10K with many StoreEdge storage systems; build with VxFS: One physical read to a database could read an entire partition; would skew hit ratios; but as you mentioned:

Over-generalizing: a LOW ratio is worth investigating for a dba; If you are the analyst issueing ad hoc queries or you created an index during development; I would give you lots of ram; because I hate to see you wait for few days just to see the fruits of your work.

The antz won't wait! you big jumble of ......; wake up; take a fresh look at the world; and you may keep you job this time if the indorians leave.

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

Please open a TAR with Oracle Support before setting _trace_event_public or any undocumented params. Please leave this to profs. You need to be qualified before Oracle would even allow you to do this.

Of course; you can ignore Oracle's advice; and then salvage your data from indexes as happened to USAirways. The choice is yours. I hope you are not giving Embarcadero such nonsense.

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

You are far from honesty and your are wrong. OMLET allows you to detect what's wrong quickly; as it displays all waits on visual flows and many drill-down menu's.

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

I seriously doubt you really know the difference. If you know answer the following questions:

what is fuzzy checkpointing? and does it relate to TIDs or how does Oracle maintaine consistent reads when sharing cursors? Or how Oracle maintains lock free space; ..... etc!?

for each correct answer move to the next grade?! I remember you are in the 2nd grade so far.

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

Again I wonder if you know why days are different from nights to ANtz and Cockroaches and why certain functions are allowed during a time window and are not allowed at another?!

Get a clue and then get a grip and leave these issues to production DBAs; Go to sleep or write books about SQL trace events; By the time you read anything from udump; you probably would find that the problem has escalated to your VP; and he starts handing pink slips to dumbs and dumbers in sight;

I understand where you come from: Gaja was on a SWAT team before he ever wrote a 101 tuning book. and he knows slightly more than you MR. Fitz; Let me share with you one thing: For every OMLET someone downloads; His company loses 15K; I have a personal agenda after all.

To purchase OEM for Sabre required about $15M; to buy Gaja's solutions would have required $1B. However; the solution is not scripts for everyone; and certainly is not trace events. Light thin jdbc (mostly inactive) connections go a long way of allowing a Texas cockroach the pleasure of monitoring an instance in Tulsa while courting an ANtz .......... on his PDA. See the first two lines for context.

> By inference, if a LOW db buffer
> cache hit ratio is BAD then a HIGH db buffer cache hit ratio MUST be
> GOOD,
a small dick up your ass is BAD but a BIG dick up your ass is certainly NOT Good. How many times, do I have to give you this advice? Ask your mother please?! And save me the R-rated stuff; Or please read this post when are past the legal brain age. See the last few lines for context.

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

Take it like a ....; you caused so much trouble to so many nice decent hard working people.

>
> > > 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 people to use undocumented params; and deny them documented params ?!? you really are so twisted!

(Well if overlook that this started as a post that is look-a-like spam).

That is why I shall execuse you insulting Oracle and not OMLET. Do not ever insult someone's party, dick or OMLET. see http://www.omlet.org/images.jpg for a clue and then get a grip.

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

what tuning methodology?! All I did is slam few customizable SQL queries with a pretty picture which you can replace it like any other skin. No tuning nothing! I would not even give a tuning methodology for your Tonka truck. You create your own tuning metho.. yourself.

> and
> you're also more than willing to attempt to discredit any and all who
> tell you that you're wrong.

For the record; guilty as charged! I was wrong about nothing; set CURSOR sharing to what ever you like exact; force; similar as you like; it hardly matters.

Most dumb dba's like you set shared pool to mind boggling numbers and then they get 2 transactions per century.

>
> > > You originally attacked Howard J. Rogers, then myself,
> > > then Daniel Morgan, then Joel Gary and, finally, Mladen Gogala. Any
> >

the Antz mother-kickers gang! See the first two lines for context.

> >
> > > post any member of this group of individuals makes you see fit to
> > > insult, in a crude and inappropriate manner.

Check it out Antz; and then think? See my first two lines for context.

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

Did you ever work for AMR?
Am I talking to the wrong gal?

I really have to check your DNA; please send me blood sample? DO you take drugs?
Have you changed your bones?

>
> 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 am trying to improve it. Will you cooperate with this broken bad egg catastrophe -- you pathatic Antz!

Look and think? see my first two lines for context.

If you are reading so far; this thread is tiring and must be halted!

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

Oracle metalink and Quest's pipeline are moderated. Be the moderator for this newsgroup and post a sign in Tulsa "NO OMLETs ARE ALLOWED".

Now SON; please get up and have an OMLET with broken eggs and forget about Oracle and tuning; I am concerned

PS. All typos are the trademarks of their respective dictionaries. None however is delibrate! Few Antz around made a mess. Received on Thu Jul 01 2004 - 18:58:14 CDT