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

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Hardware / OS recommendation

Re: Hardware / OS recommendation

From: Mogens Nørgaard <mln_at_miracleas.dk>
Date: Fri, 19 Mar 2004 23:34:19 +0100
Message-ID: <405B756B.8020109@miracleas.dk>


And I think there never, ever can be enough testing. If anything goes wrong, or if anything behaves worse than what we want or expect, we can always - always - say: "Ah, they should have tested it (more)". But this is NOT the case, in my opinion. It's just an easy way out for all of us. A way to blame someone else, when we don't know what to do ourselves anyway.

[This is not an easy shot at you, Pete. But I've been wondering about tests for a while. I think they're not worth much, to put in mildly :)].

If a test should be of any value, it should prove something. But can it ever prove that your environment - your combination of online ad-hoc, planned batch and ad-hoc batch - can run on a given combination of thingies? No, it can't.

You can test and measure and judge and guess that your system can sustain the IO workload the system can handle. You can pray that serialisation (latches, locks, enqueues, etc.) won't get in the way. But can you control batch in a Unix/Windows world? No, you can't. Can you direct certain services/stuff to dedicated CPU's? Yes, but with great, great difficulty.

In the words of my old friend Ole (sorry, that's his name. So Ole' Ole sounds pretty cool...): "Benchmarks are always in-conclusive."

They are. They might serve the purpose of making the bosses happy and feeling good in their stomach. But they will never be able to mimick the real load on the system.

In the managed mainframe world they can usually predict fairly precisely what will happen to application A if X happens and what will happen to app B if Y happens.

No way to do that in our world. Or to be more provocative: If there really was a systematic way of doing this, I would have thought it would have been standardized a long time ago.

So lean back, Pete, and tell me what you would test before putting a mixed online/batch environment into production? How the Hell are you going to emulate an ad-hoc environment without "just" doing the "Yes! We've done this, we've done that" routine in the benchmark?

I'm a bit rough on you right now, and that's not what I meant. You're a rather cool man who knows his stuff.

Mogens

Pete Sharman wrote:

> Well, he did say "have to field user complaints for weeks after each move, despite testing."  That immediately implies there hasn't been sufficient testing to me.  :)
> 
>  
> Pete
>  
> "Controlling developers is like herding cats."
> Kevin Loney, Oracle DBA Handbook
>  
> "Oh no, it's not.  It's much harder than that!"
> Bruce Pihlamae, long-term Oracle DBA
> 
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mogens Nørgaard
> Sent: Saturday, 20 March 2004 6:01 AM
> To: oracle-l_at_freelists.org
> Subject: Re: Hardware / OS recommendation
> 
> Of what?
> 
> Pete Sharman wrote:
> 
> 

>>More testing? :)
>>
>>
>>Pete
>>
>>"Controlling developers is like herding cats."
>>Kevin Loney, Oracle DBA Handbook
>>
>>"Oh no, it's not. It's much harder than that!"
>>Bruce Pihlamae, long-term Oracle DBA
>>
>>-----Original Message-----
>>From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of John Flack
>>Sent: Saturday, 20 March 2004 12:54 AM
>>To: oracle-l_at_freelists.org
>>Subject: Hardware / OS recommendation
>>
>>We are currently running 8.1.7 databases on a 4 year old Dell Pentium
>>machine, under SCO UnixWare. This is the last supported version of
>>Oracle under UnixWare, and since the hardware is getting old in internet
>>years, we're thinking of getting new hardware running a supported OS for
>>Oracle 9i R2 or 10g. I'm the official DBA, but my system administrator
>>has been wearing an Asst. DBA hat doing much of the day to day work.
>>
>>The SA wants to get a low-end Sun SPARC machine running Solaris, since
>>the price of these has come down to around the same price as the sort of
>>high end Intel or AMD machine that we would normally use as a server. I
>>would normally vote for the Intel/AMD solution running Red Hat or SUSE
>>Linux, since we already run several of those. And maybe there are some
>>low-end machines from HP or IBM (or someone else) that we should
>>consider.
>>
>>One thing I'd definitely like is an OS that Oracle will support for a
>>long time. We started on old SCO Unix, moved to SCO Openserver when
>>Oracle stopped supporting it, moved to UnixWare when Oracle stopped
>>supporting Openserver, and now have to move again. Oracle is Oracle,
>>and we've never had much of a problem with the database stuff - an
>>export and an import, and we've been good to go. But the shell scripts,
>>COBOL and C programs have required tweaking every time we moved.
>>Nothing major, but just enough to have to field user complaints for
>>weeks after each move, despite testing.
>>
>>Suggestions, anyone?
>>----------------------------------------------------------------
>>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>>----------------------------------------------------------------
>>To unsubscribe send email to: oracle-l-request_at_freelists.org
>>put 'unsubscribe' in the subject line.
>>--
>>Archives are at http://www.freelists.org/archives/oracle-l/
>>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
>>-----------------------------------------------------------------
>>
>>----------------------------------------------------------------
>>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>>----------------------------------------------------------------
>>To unsubscribe send email to: oracle-l-request_at_freelists.org
>>put 'unsubscribe' in the subject line.
>>--
>>Archives are at http://www.freelists.org/archives/oracle-l/
>>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
>>-----------------------------------------------------------------
>>
> 
> 
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
> 
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
> 

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Fri Mar 19 2004 - 16:31:53 CST

Original text of this message

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