Re: Where is Oracle’s Grid ?

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Tue, 30 Dec 2003 10:55:54 -0800
Message-ID: <1072810464.715634@yasure>

Noons wrote:

> "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1072796803.85192_at_yasure...
>

>>And if it doesn't how can the database tools be used to tune it?

>
> Very simply: if the SQL can be found in the SGA and I can dynamically
> tune it like 10g allows me to (the actual mechanism is irrelevant here),
> then the toolset that 10g is providing me with allows me to tune very
> bad SQL. Which is what I want to do.

Then it is possible 10g will help. Provided, and it is a big "provided" the vendors don't refuse support if you upgrade.

>>How many no. But how badly yes. Do you think a database engine should be
>>able to tune a Cartesian join?

>
> If the CBO forces a CJ when one wasn't needed, then I should be able to
> change it back to something the db can deal with.

Agreed.

   The CBO does this CJ
> replacement often enough when join columns are of different data types, as
> you likely are aware of.

I was referring to the garbage code written into many of these third-party product's front-ends.

> Of course, if the statement was coded initially as a CJ and nothing I
> do in tuning can change that (missing join conditions), then my only
> resort is to go back to the 3rd-party maker and get them to send me a patch.

Granted my example was extreme. But I've looked at a lot of what is generated in these product's front-ends and it is horrible.

> Guess which type of app is developed nowadays? How relevant is RAC gonna
> be for them? Any wonder why RAC's been received with lukewarm enthusiasm
> from the 3rd-party users?

I'd guess because most products are not using TAF and not trapping commits and not written by people that understand how to write for fail-over. It is absolutely Oracle's fault that this includes Oracle Forms, Reports, and Apps. It is not their fault that other vendors similarly have refused to rewrite their code for fail-over.

> Same goes for all the other stuff. It's not the features, it's how well
> they fit the existing market. The production DBAs can do nothing with them
> if they are essentially useless in their environment. No matter how much
> they might be interested in using them.

Provided one insists on purchasing garbage from vendors that don't leverage these abilities. One of the reasons for Amazon's success is that they have written all of their own apps and all of their own APIs. It is the difference between good management and bad.

>>Then if you didn't know this before let me be the first to tell you. The
>>products we are talking about are full of lead ingots. I've seen their
>>internals. They were written by people that know nothing about PL/SQL
>>or, if they did, forgot it when the coded these product lines.

>
> They were essentially COBOL-mainframe products that were "ported" to other
> environments by a bunch of ignoramus idiots with NO IDEA whatsoever how
> to spell UNIX, let alone Oracle or PL/SQL or anything else. As for their
> knowledge of SQL, it was mostly based on very old versions of mainframe
> DB2 and that defines it all. Yes, I know EXACTLY what you're talking about.
> I even know the calibre of the people supporting one of those in Australia.
> From a long time ago...

Exactly. So what's Oracle supposed to do? Send the software police to lock up incompetent developers? How about managers that buy projector-ware rather than listending to their own DBAs?

> Don't need to. All I want is to be able to tune the SQL when I find
> a moronic one or one that the CBO has taken to a moronic level.
> Without having to change the source code. That is only possible in 10g.
> That's what should have been there ages ago and was asked for ages ago.
> That's what the previous stuff is essentially useless for.

Now I understand what you want. Hmmmm. I think it would be far easier to just buy good software in the first place ... or write it yourself.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)

Received on Tue Dec 30 2003 - 12:55:54 CST