Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Oracle's relationships with expert DBAs (and the rest of us mere mortals)

Re: Oracle's relationships with expert DBAs (and the rest of us mere mortals)

From: Nuno Souto <>
Date: Fri, 02 Jun 2006 20:13:21 +1000
Message-ID: <>

MVE wrote,on my timestamp of 2/06/2006 1:28 AM:

> I have been working for a Sun/Solaris shop for the last 5 years (they have been
> in business for the last 12) and I have seen ZERO evidence of "Sun kept
> changing their hardware/software". We made good initial investment and ran on
> the same boxes for 7 years! And when the time came to switch to new
> hardware/os it was a simple backup/restore/relink -- not a single patch had to
> be applied on the ORACLE/APPS side!

Well, just on the chapter of changing hardware/software: I do recall a painful time with an E10K where Sun couldn't get it to stop crashing until they patched the OS to keep one of the 64 CPUs busy all the time in a tight loop. Ie, it became a 63 CPU box. I know it is fixed now, this was in 2000. But how do you reckon it got fixed? Without a hardware change? Right...

> Well you are running ORACLE aren't you!!??

No. We ran Oracle AS WELL. There is a major difference right there.

 > So why would you choose an OS
> platform that requires the most amount of work?

It doesn't. Like I said: it's a once only exercise. Do it once, can it into a tarball then clone it across IBM or Dell blades, INtel or AMD CPUs. I'd love to see Solaris cloned that way across different architectures. Unfortunately, our sole remaining Sun box can't even be upgraded past 2.6 because the later levels of Solaris don't support its older Sparc CPU... Ah yes: it's 7 years old.

> As I said when we switched
> from older Sun/Solaris boxes/os to newer:
> [DB] E6500/2.6 -> V890/2.9
> [MT] E420R/2.6 -> V210/2.9
> all that had to be done was a relink!

Funny. We didn't even have to do that between RHEL3upd3 and RHEL3upd5. In fact, all I had to do was change the OS and reboot.
But then again, that might be complicated?

> This is NOT only initial cost YOU have to jump through the same hoops every
> time Linux changes their os which is more often than Solaris (we ran on the
> same boxes same os for 7 years).

Where did you get the quaint notion that the OS MUST be changed everytime there is a new release of Linux? Nothing could be further from reality, in fact. Last time I looked, our boxes are humming along on RH3upd5 even though RH can be had in much later versions.

Of course - unlike other companies that shall remain nameless - RH doesn't have an "upgrade or else"policy. Which means we can get all bug fixes we need for BOTH RH4 and RH3! I'd like to see much larger companies get anywhere NEAR that sort of flexibility...

> And again you are running ORACLE why would you choose the worst possible
> hardware/os for it?

Your claiming it is doesn't make it so.

> This is an ORACLE list after all where we collaborate on
> the best practices of running ORACLE. ORACLE/Linux is not the best practice.

This is an Oracle list indeed. As to what we collaborate on, I leave it to the list owners. But I've got a funny feeling they don't give a hoot about any claim that Oracle/Linux is not "the" best practice and that only best practices of Oracle are alowed here. The two things are not even related.

> NOT getting the BEST hardware/os for an ORACLE shop is like buying inferior
> tools for you construction crew -- it will ALWAYS cost you in the long run and
> eventually you have to replace all this crap anyway.

Which is what we did with Sun and their hardware. Relaced by blades and a cost-effective OS.

> If your shop can't afford NEW hardware then buy it used (there's plenty out
> there after the crash). Build up the business and then switch to new
> boxes. You'll be better off in the long run.

That's what we did. We bought second hand Suns, then switched to proper hardware.

BTW, the document you quoted in another answer about how many problems there are with Linux/Oracle installs and how many there aren't with Sun/Oracle installs?
It is completely incorrect.

The document you should be quoting is this: 169706.1 Look it up in Metalink. Note the date of last update: barely 15 days old. And it paints a real picture about installs of various versions of Oracle in just about all the supported Linux and Unix hardware and OS version platforms.

Far from squeaky clean as you claim, Solaris/Oracle installs are just bout par with all the others and nothing to write home about in terms of ease.

So the argument about the pretended superiority of the Solaris "best practice" is, I'm afraid, essentially dead.

Nuno Souto
in sunny Sydney, Australia
Received on Fri Jun 02 2006 - 05:13:21 CDT

Original text of this message