Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Where is Oracle’s Grid ?

Re: Where is Oracle’s Grid ?

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Mon, 29 Dec 2003 19:16:39 -0800
Message-ID: <1072754108.418011@yasure>


Comments in-line.

Noons wrote:

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

>>Short of purchasing PeopleSoft, SAP, Siebel, Baan, etc. how?
>>Specifically how can Oracle do that?

>
> Dunno. Maybe look at what DB2 has done and learn? They don't seem
> to have the same problems, I wonder why...

I can think of lots of reasons why this might be true. But from personal experience I can't say I've found SAP or Siebel better against DB2.

>>question Ford is responsible for the quality of care. And I would argue
>>that this is analogous to buying the Oracle database and putting Oracle
>>Apps on top of it. In that case Oracle is wholly responsible.

>
> Let's not go there.

No lets go there.

Oracle Apps have been guilty of plenty of horror
> performance stories over the years. Not to mention clear violations of
> 1st-normal-form of relational design...

And as I've said when Oracle screws up Oracle deserves to be taken to task. One inexcusable example being the fact that Oracle Apps are certified on RAC because Oracle's never bothered to make Oracle Forms fail-over with RAC.

But not once has this thread been about Oracle's own apps and it would be wrong to introduce that as the issue this late in the thread.

>>But what you are suggesting is more like I buy a Ford and take it to the
>>Texaco station down the street. The mechanic there buys a carburator
>>from a parts-house and does a lousy job of installing it on my car.
>>Therefore Ford is responsible for the quality of the part my mechanic
>>purchased and installed?

>
> I don't agree with this analogy at all. When you buy a 3rd party app,
> you are NOT modifying Oracle in any way, shape or format.

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.

   What you
> are doing is using it in its capacity to use applications against it.
> When you stick in a carby, you ARE modifying the beast. THEN it's
> your problem!

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

If you think you can separate the designer of the schema and the objects from the back-end in a manner different from a carburator from a Ford by all means do so. I gave great thought to the analogy to make it relevant and would like to see where you think the line should be drawn?

> A better analogy is that when I buy a Ford truck and put a load on it,
> I darn well expect it to be able to carry the weight. Or else stop
> calling it a truck.

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?

The load on Oracle created by third-party apps is not of Oracle's making. And based on my work at AT&T Wireless and knowledge of what goes 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.

Provided I designed the schema and wrote the code.

I've no doubt I could similarly write a simple stored procedure that could bring down any database.

BEGIN
    LOOP

       INSERT INTO obj$
       SELECT * FROM obj$;
       COMMIT;

    END LOOP;
END;
/

Would you blame this failure on Oracle too? Want to see me write it for DB2? Informix? Sybase? Ingress? SQL Server? It isn't the database vendor's fault that people write bad code.

>>How can you hold Oracle responsible for the horrible design, coding, and
>>deployment of someone that only builds after-market bolt-on parts?

>
> I don't. But when Oracle claims its tuning toolset is capable of
> doing so and it clearly isn't, there is something wrong...

I disagree. It is. I've used it successfully many times. But Oracle's tools can't tune garbage ... garbage needs to be rewritten. And tools can't be used to tune what was written in C or C++ by people whose knowledge of SQL seemingly consists of being able to spell it.

Why do you think you should be able to use back-end tools to tune what has been coded into the front-end?

>>What Oracle sells does fix things. But only if someone bothers to read
>>the documentation, learn how to use it, and then deploys it in an
>>appropriate manner.

>
> Nope. Sorry, it doesn't. Maybe in 10g and that is still to be proven

Nonsense. Going all the way back to 7.3.4 and before there were tools that could have been used to make those third-party apps run better. The problem was that you can't tune what you can't change.

> in the conditions of the "coal face" out there. Don't forget: it is NOT
> yet released!

You won't like it either. Because you still seem to think that a tool intended for PL/SQL should be able to modify compiled code written in C++.

>>I understand yours and other people's angst. I have had more than my
>>share of run-ins with Siebel and other app vendors. I've even had
>>run-ins with accounting firms that incorrectly installed Oracle's own
>>applications.

>
> Bingo! Yet, do you hear Oracle for ONCE putting some of those accounting
> firms' nose out of joint? No way Josay!

I think they should ... but you are changing the subject.

>>But before you pull the trigger I'd suggest taking more careful aim.
>>Oracle has made plenty of mistakes: Metalink is full of them. But you
>>should not blame Oracle for the mistake your firm made buying that
>>after-market carburator and having your next door neighbor's teenage son
>>install it.

>
> And maybe Oracle should not make the mistake of blaming the poor sods
> who have to cop the crud dished out by these makers: the production DBAs
> out there. Who have over the years put up with the rubbish from EVERYONE
> including Oracle and are now being pushed out of a job by Oracle's marketing.

Oracle's marketing is not pushing anyone out of a job but you are correct that a lot of people will probably lose their jobs in the next ten years. Same thing happened to all those that bet their careers on COBOL, RPT, ALGOL, shall I go on? You need to modify your skill set.

> And being blamed left right and centre as the root of all evil. It's not
> that they don't know what to do or don't want to do it. It's that they are
> NOT allowed to do it.

And that is Oracle's responsibility? How so?

> Maybe Oracle should start encouraging vendors to let DBAs do their job
> instead of just acting as trained monkeys? I know this will stuff their
> marketing plan to sell trained monkeys at a premium. But that's a plan that
> WILL backfire badly.

It isn't Oracle's responsibility. I think the root of this entire thread is that you'd rather complain about that which you can not change rather than change the things you can. Were I in your shoes, and I've been there a few times, I'd:

  1. Update my resume
  2. Find a job where I had the control I desired

And that is exactly why I am doing what I am doing and enjoying every minute of it.

And yes I know the market is rotten and that in Oz it may be worse than other places. But there are jobs to be had for those that have the skills and put in the effort.

-- 
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 Mon Dec 29 2003 - 21:16:39 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US