Re: Where is Oracle’s Grid ?

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Tue, 30 Dec 2003 07:08:13 -0800
Message-ID: <1072796803.85192@yasure>

Noons wrote:

>>Aren't you? Who created the tables? Oracle?
>>Who defined the primary key constraints? Oracle?
>>Who created what few referential constraints exist? Oracle?
>>And on and on and on through every single line of executing code in the
>>front-end.

>
> You gotta be kidding! You mean I buy a general purpose RDBMS
> and when I add my app's tables to it I'm modifying the RDBMS?
> What next? I buy a general purpose Sun computer, I run a program
> on it and therefore I'm modifying the system from Sun's specs?

I think you misunderstood my intent (or at least I hope so). When you buy an RDBMS all you are buying is the executables and the data dictionary. What you do in it is out of the control of the manufacturer. The manufacturer has no control over whether you know how to create a relational schema. No control over whether you know what an index is and build them appropriately. And in the case the products we are talking about ... no control over the garbage written in C++ at attached as a front-end.

>>And when SAP, PeopleSoft, Siebel, Baan, etc. create schemas, users,
>>roles they aren't?

>
>
> Of course not. They ARE supposed to create ALL that stuff. That's
> what a general purpose RDBMS is for. If what they create makes sense
> is a different proposition!

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

> Where I said it should be drawn. I can create as many objects in ANY
> database engine as I may need. That's got NOTHING to do with mis-using
> the engine's software capabilities.

How many no. But how badly yes. Do you think a database engine should be able to tune a Cartesian join? Do you think "unbreakable" means you don't use RAC, don't use DataGuard, and write looks with incremental commits? Of course not.

> But if I come up with a design that is so deranged it uses NONE of the
> features of the RDBMS software it runs on, or it needs to create its own
> indexing mechanism, in order to "stay portable" or some other equally
> MORONIC technique or target, then I'll have a serious design problem.
> Which has nothing to do with the engine, backend, frontend or whatever.

Agreed.

>>Ok lets go with your analogy. You just bought a Ford pick up truck. You
>>hook it up using the trailer hitch to a pair of 30 foot trailers loaded
>>with lead ingots.
>>
>>Are you going to blame Ford?

>
>
> Of course not. I'll blame whomever didn't tell me it was a 30 foot
> trailer load of lead I had to carry! In which case I'd have gone for
> a prime mover.

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.

> But if someone tells me that in order to carry ANYTHING in that
> Ford truck it has to obey Ford's packaging dimension, weight, quantity
> and shape specifications or else it just won't fit, I'll be seriously
> worried about Ford!

Oracle is correct. You can carry anything. But you have to add the load correctly. Not stack it all on one side of the trailers.

> Besides, I prefer GM. Ford to me is an acronym for "Failed On Race Day".
> <EG,d&r>

I drive a Jag so ... in a sense ... I drive a Ford. Sends shudders down my spine.

>>on at Amazon.com here in Seattle I can assure you that I could put
>>10,000 times the load on Oracle you've seen at your best and Oracle can
>>handle it.

>
> I know that.

Then obviously Oracle can handle the load. BTW also handles the loads at Visa, MasterCard, and American Express.

> I was also once told I couldn't run a given sequence of batch
> programs in less than 7 solid days of processing. When I was
> done with them, the total runtime was down to 28 hours.
> I couldn't do better because they didn't let me change the EMC
> setup. That was 8ir3.

Then you are well aware that the quality of what developers develop is critical. You don't blame these examples on Oracle.

> I can't tell you what I'm doing with 9ir2 and Forms 9 yet, still
> on-going. But I'm getting some truly amazing results. At least
> the customer thinks they are.

Oracle would be glad to be "blamed" for this.

> Not bad for someone who according to Oracle's marketing
> CANNOT possibly be up-to-date in skills or upgrade his
> skillset... But I'm not a typical case, let's get back to
> reality.

I've never once seen Oracle marketing name either of us in an advertisement. Got a link? ;-)

> What is the COMMON thread in all of the above? I HAD access
> to the code and design and I COULD change it.
> Not ONE of the Oracle tuning toolsets in all those revisions
> would have helped me one bit had I not had this.

How can Oracle give you access to compiled code they didn't write?

> And that is the gist of my claim: the tuning toolset from
> Oracle is USELESS until 10g for anyone WITHOUT access
> to source code or the ability to influence changes in
> said code. Which is 90% of the production DBAs
> out there. Therefore, the existing toolset is useless to
> 90% of the production DBAs.

If you think 10g, or 100z, is going to give you access to compiled code written by another vendor you are begging for disappointment. No product other than a decompiler will do that.

> Has always been. And that Daniel, is the reality of being
> an Oracle production DBA. Like it or not.

I agree. It is part of the job. But it is not the database vendor's fault. You've yet to explain how they can possibly grant you access to something written by another vendor? Keep in mind the executables you are talking about (perhaps ranting about) were written in C++ by Siebel, PeopleSoft, SAP, and/or Baan. That is not Oracle's code.

-- 
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 - 09:08:13 CST