| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Hardware / OS recommendation
Ooohh I like it when you're rough! :)
Actually, given what John responded in a separate email as an example of why there were complaints about lack of testing, I totally agree with you. It's impossible to test for things that are out of scope. In this case, testing to include a script that a user wrote him/herself that you know nothing about just ain't viable. What are needed here are scope boundaries. Like any good project, the testing should define up front what's in scope and what's out of scope. User written scripts that are in the user's login directory and not under change control for the app are clearly out of scope. And if you need ad hoc query capability, then maybe you need the ability to dynamically grow and shrink the computing resources available to you. Heck, maybe you need a grid! :)
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 9:34 AM
To: oracle-l_at_freelists.org
Subject: Re: Hardware / OS recommendation
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
> -----------------------------------------------------------------
>
-- 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:50:46 CST
 |
 |