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 -----------------------------------------------------------------
