RE: Oracle support for RHEL 6

From: Martin Brown <martinfbrown_at_hotmail.com>
Date: Sat, 13 Nov 2010 09:33:13 -0500 (EST)
Message-ID: <SNT107-W75162D3B167EDE3CA0BA3C2740_at_phx.gbl>


I just recently tried to put 11.2.0.1 client on OEL 6 in a virtualbox. Had a heck of a time with packages. It ended up going in, very unstable and is really OEL 5. So my experiment is over for now until I see it certified.  

Date: Wed, 27 Apr 2011 22:10:00 +0530
Subject: Re: Oracle support for RHEL 6
From: oracle.tutorials_at_gmail.com
To: mwf_at_rsiz.com
CC: oracle-l_at_freelists.org

Thanks to all for your valuable comments.

Mark,

Our product (application server) is supported on both distributed as well as combo (same physical server) setup. Hence we have to consider various compatibility options.

Something a little off topic I want to discuss.

Having Oracle Linux (OL) which is binary compatible with corresponding RHEL OS, is it a good idea to adopt OL for non-Oracle environments as well?

Do you see any downsides to it? If there is no downside to using OL then in which scenarios one must go with RHEL?

Deepak

On Wed, Apr 27, 2011 at 4:20 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:

Other folks have answered your actual question. I’m curious about something else: Is your licensing such that it makes sense to use cycles on the same server? Or did I over interpret “same OS platform/server” and you just mean having the machine the application server is on be the same release and OS as another machine that is the db server?  

Since the advent of relatively cheap and truly impressive LAN cards the early 1990’s need to place chatty application servers on the database server has been reduced by several orders of magnitude. Combined with per cpu (or core, or thread, or socket, or whatever term someone has invented in the last 15 minutes) license costs, it is probably unwise to use database server cpu cycles on application servers.  

Anyway, I would urge you to de-couple this artificial linkage when the encapsulation is a network link. From a purely a priori position it seems likely over time that there will be some OS revision that vastly improves (usually meaning removes bugs) either the application server you’re using or the database you’re using but is ahead of its counterpart in certifications. You really only need to validate the communications protocols between the two. As long as there is in house expertise, this frees you to even go with a different OS and/or manufacturer for the application server and database server. Over time there have often been sizeable cost/performance differences between who was the winner in the application server space versus the database server space. True, if you’re carving up a physical rack into virtual slices you probably want it to be all one manufacturer in a given rack. But otherwise you may gain a lot by removing this restriction.  

Regards,  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of DBA Deepak Sent: Tuesday, April 26, 2011 1:18 PM
To: Oracle-L
Subject: Oracle support for RHEL 6  

Hi Experts,

Need your valuable inputs on the following.

RHEL 6 has been released few months back. As of today Oracle database is not supported on RHEL 6. But it is supported on OEL 6 (which I feel is a customized version of RHEL 6, may be I am completely wrong).

We are planning to use RHEL 6 for application server (for some reason) and as per our architecture the database and the application server should reside on the same OS platform/server.

Hence will it be a prudent idea to install Oracle database on RHEL 6 in a production environment. I know many experts would say NO, but would like to know from your experiences whether people do sometimes go for similar setups where database is not supported on the exact OS platform.

Looking forward to all your valuable comments.
--

Regards,

Deepak
Oracle DBA

--

Regards,

Deepak
Oracle DBA                                                

--
http://www.freelists.org/webpage/oracle-l
Received on Sat Nov 13 2010 - 08:33:13 CST

Original text of this message