RE: Hardware / OS recommendation
- From: Pete Sharman <peter.sharman@xxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Sat, 20 Mar 2004 09:54:09 +1100
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Mogens Nørgaard
Sent: Saturday, 20 March 2004 9:34 AM
To: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
> Behalf Of Mogens Nørgaard
> Sent: Saturday, 20 March 2004 6:01 AM
> To: oracle-l@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
>>Behalf Of John Flack
>>Sent: Saturday, 20 March 2004 12:54 AM
>>To: oracle-l@xxxxxxxxxxxxx
>>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@xxxxxxxxxxxxx
>>put 'unsubscribe' in the subject line.
>>--
>>Archives are at //www.freelists.org/archives/oracle-l/
>>FAQ is at //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@xxxxxxxxxxxxx
>>put 'unsubscribe' in the subject line.
>>--
>>Archives are at //www.freelists.org/archives/oracle-l/
>>FAQ is at //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@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //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@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
