RE: OFA and Linux FHS (or other unix standards)

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Wed, 20 Aug 2014 13:13:48 -0400
Message-ID: <048f01cfbc9a$1bd84ee0$5388eca0$_at_rsiz.com>

Hans makes several good points. The Optimal Flexible Architecture as created by Cary back when physical mount points were tiny, machines completely dedicated to Oracle were uncommon rather than the rule, and every UNIX system administrator seemed to have a personal and idiosyncratic naming convention for her (or his) [note the possessive pronoun intentionally used]. Even back then an argument could be made for an Optimal Static Architecture (which I published in conjunction with an early proofread of Cary's OFA - which I found delightful) for machines actually dedicated to be Oracle RDBMS servers. I'm not even sure I have a copy of that and it was never particularly popular. Essentially it was OFA, but compress
/u01/app/oracle/product

to
/ora

and mount everything needed for the Oracle infrastructure on /ora [except the canonical bits like /var and /opt that Oracle uses] using the same token pattern Cary used.

Then you also had to decide whether you were even considering having both software and data components on the same drives. (Which is a nice way to slow down production while you are even loading a patch onto disk, let alone applying it). And whether databases would share drives or be independent. Which was an argument of sharing i/o bandwidth where different peak load times could be predicted for different databases versus recoverability segregation. With a very small amount of variability all these cases could be easily handled, and you could find everything just by looking at /ora.

I also advised that a readme file exist in /ora listing anything NOT mounted on /ora that was required for the Oracle infrastructure to work.

If you add up the amount of memory string length (especially in java land) this compresses out, you will be surprised. It also made things like datafile reports print much less wide, which could be a big deal in the era of not really being able to clearly read screens of the day wider than 132.

Anyway, the main point of OFA is being able to find everything routinely. Usually now you don't even need physical mount points under /ora, so using Hans' pattern if oracle_base is /ofa, then all the versions and other things just go under there.

And you might have either /grid or /ofa/grid, depending on your preference.

Sigh. Short is good. Understandable is mandatory.

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Hans Forbrich
Sent: Wednesday, August 20, 2014 10:59 AM To: oracle-l_at_freelists.org
Subject: Re: OFA and Linux FHS (or other unix standards)

On 20/08/2014 7:30 AM, Jeremy Schneider wrote:

> Should OFA still be used together with outside unix standards (like
> FHS) today or has the literal "/u##/app" manifestation of OFA become 
> so ubiquitous now that it has become its own standard?
>
> -Jeremy

Another nice summary for FHS is at
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

I'd attempted a reconciliation several years ago, but came to the conclusion that no one would use it. Roughly along the same lines as: the doc says you can use any usename to own the oracle s/w, the doc examples all use 'oracle:oinstall', and creating local standards will simply cause difficulty for anyone attempting to hire dbas.

I've had customers hire consultants and contractors who literally could not handle 'non-standard' (read, not in the documented examples) variants in username and directory structure. Indeed, one very 'senior' consultant setting the architecture for a high availability, high security project did not understand how one could administer the database without logging on as user oracle. (Politically, I lost, and the project ended up with millions in cost overruns, and missing all HA and security goals.)

Most DBAs I know aren't even aware that the /u01/app/oracle represents
/u01/app/*username* and think the 'oracle' means the app.

For a number of years some of us, including Oracle U, used /opt/oracle as ORACLE_BASE (but again a lot of people thought the "oracle" referred to the app) and some even tried putting files under /var/opt/oracle - /data, /logs,
/fra, etc. but that got shut down with Oracle's other use of
/var/opt/oracle

Once Oracle moved stuff into diag, I personally gave up and acknowledged that Oracle provides a pretty much self-contained ecosystem, and now pretty much just stick with the docs.

I do have a variant, that I try to stick to, in the Oracle tree:
/u01/app/oracle/product actually has a layer for product under it ( /oms,
/oma, /rdbms, /wls, /ofm (fusion middleware, generic), /bi, etc) so I can
keep some semblance of consistency, as I get the impression the middleware guys don't seem to have a sense of order yet.

And at the bottom of the tree, I also divide out the standard edition and the enterprise edition ORACLE_HOMEs explicitly as a reminder to 'watch it' when applying those wonderful patches that change edition and feature sets.

In effect, the OFA recommends
/u01/app/oracle/product/12.0.1/db

but, to account for other products, I have
/u01/app/oracle/product/oms/12.1.0.4
/u01/app/oracle/product/oma/12.1.0.4
/u01/app/oracle/product/rdbms/12.1.0/se/db1
/u01/app/oracle/product/rdbms/12.1.0/ee/db1
/u01/app/oracle/product/rdbms/11.2.0/ee/db1
/u01/app/oracle/product/wls/12.1.0

and
/u01/app/grid/product/ ...

Bottom line - it's easier to go with the flow ... but please understand the flow and the implications. ;-) /Hans

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l

Received on Wed Aug 20 2014 - 19:13:48 CEST