RE: the joy of version numbers

  • From: Don Granaman <DonGranaman@xxxxxxxxxxxxxxx>
  • To: "mwf@xxxxxxxx" <mwf@xxxxxxxx>, "jpatterson@xxxxxxxxxx" <jpatterson@xxxxxxxxxx>, "fuzzy.graybeard@xxxxxxxxx" <fuzzy.graybeard@xxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 22 May 2013 16:01:36 -0500

Amen!

In the late 1990's, I presented a short session on "Misunderstanding OFA" to a 
local user group after encountering far too many semi-educated DBAs who said 
stuff like: "This isn't OFA!  You used /ora01/, /ora02/, etc. instead of /u01/, 
/u02/, etc."!

It seems that the intent of a once great idea has since been completely lost in 
the details.  Some of the Oracle documentation now says "for example /u01/" and 
some says, essentially "THE MOUNT POINTS MUST BE /u01/, /u02/, etc."!  Many 
support techs also seem to think that '/u01/' is somehow sacred.

Now, even with ASM for all the datafiles and such, I sometimes run across 
someone who still insists on creating /u01/, /u02/, /u03/, ad nauseum - and 
leaving them empty - simply to appease the (quite misunderstood) OFA gods.

Don Granaman | Ph: 402-361-3073 | Cell: 402-960-6955  | Solutionary - Relevant 
| Intelligent | Security

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Mark W. Farnham
Sent: Wednesday, May 22, 2013 2:16 PM
To: jpatterson@xxxxxxxxxx; fuzzy.graybeard@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: the joy of version numbers

IF you've got a single mount point big enough to be reserved for /orasoft (as 
is mostly true these days) in place of the pre-oracle-dominance and much 
smaller /u01, /u02, /u03... allocations of often less than a gig back when Cary 
first wrote out OFA, THEN why bother with .../app/oracle/product/... ?

 

(If you read actual original OFA, those are replaceable tokens. Since you've 
already named your mount point orasoft, that means app, oracle, and
product.)

 

/ora/p/<version>/<dbhome> 

 

seems sufficient and shorter. This actually does translate into lots of saved 
memory. Your /orasoft would eliminate the need for the /p, but I like to allow 
the possibility of file systems database files, especially for little test 
databases, so they can be /ora/d/<dbname>/.

 

Anyway, that's my 2 cents on the issue: short is good as long as it is clear. 
IF you've got $ORACLE_BASE and $ORACLE_HOME defined you've got a succinct 
roadmap.

 

mwf

 

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Patterson, Joel
Sent: Wednesday, May 22, 2013 2:46 PM
To: fuzzy.graybeard@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: the joy of version numbers

 

After 11.2.0.2.0, (I think that's it), all updates will be self contained, 
(contain everything needed), so out of line patching becomes best practice.

 

So I've move forward, and as of yet have not ensured that in my version of
the OFA will be easier for patching.   There is a five digit oracle version
in my new OFA  -- because there is a new directory for each install/patch.

 

/orasoft/app/oracle/product/11.2.0.3.0/dbhome

/orasoft/app/oracle/product/11.2.0.3.3/dbhome

 

I never had use for dbhome until someone, (I think Dunbar), uses it to 
distinguish between Standard edition and Enterprise edition...  dbhome_se 
dbhome_ee for example.

 

The self cleanup of the diag can be configured.   The app_server for EM 10g
was ridiculous but I got it done -- OFA but not every txt went away, apache,
webCache, on and on with each one doing it their own way.   With persistence
I got every one -- with over a year on the SR(s).   Now we are going to go
to 12c.   The only thing constant is change.

 

On a high note:  I like the external table idea!   I have one standard on
every database.   I run a job (could be EM), but use my own and get all the
alert info in one file, (if you want it all).   The job pipes and filters
out most of what I don't need to see).  So 40 or 50 databases in one file
gives you a glimpse of something new and exciting.   I open it with VIM.
(The alert logs start over each week helping out.  I keep a month or two around 
for posterity).

 

 

Joel Patterson

Database Administrator

904 928-2790

 

 

 

--

Joel Patterson

Sr. Database Administrator | Enterprise Integration

Phone: 904-928-2790 | Fax: 904-733-4916

 <http://www.entint.com/> http://www.entint.com/

 

 <http://www.entint.com/> http://www.entint.com/

 

 <http://www.facebook.com/pages/Enterprise-Integration/212351215444231>
http://www.facebook.com/pages/Enterprise-Integration/212351215444231
<http://twitter.com/#!/entint> http://twitter.com/#!/entint 
<http://www.linkedin.com/company/18276?trk=tyah>
http://www.linkedin.com/company/18276?trk=tyah
<http://www.youtube.com/user/ValueofIT>
http://www.youtube.com/user/ValueofIT

 

This message (and any associated files) is intended only for the use of the 
addressee and may contain information that is confidential, subject to 
copyright or constitutes a trade secret. If you are not the intended recipient, 
you are hereby notified that any dissemination, copying or distribution of this 
message, or files associated with this message, is strictly prohibited. If you 
have received this message in error, please notify us immediately by replying 
to the message and deleting it from your computer. Messages sent to and from us 
may be monitored. Any views or opinions presented are solely those of the 
author and do not necessarily represent those of the company. [v.1.1]

 

From:  <mailto:oracle-l-bounce@xxxxxxxxxxxxx> oracle-l-bounce@xxxxxxxxxxxxx [ 
<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Hans Forbrich

Sent: Wednesday, May 22, 2013 11:48 AM

To:  <mailto:oracle-l@xxxxxxxxxxxxx> oracle-l@xxxxxxxxxxxxx

Subject: Re: the joy of version numbers

 

On 22/05/2013 7:13 AM, Patrice sur GMail wrote:

> Oracle version numbers are fun, aren't they?

I've noticed that even Oracle does not understand them.

 

According to the DBA Guide, Chapter 1, there is a known pattern that was 
intended to include the Oracle App Server group - but apparently neither the 
OAS nor the WebLogic Server groups read Database documentation so they created 
their own variants.

 

And then the EM group decided to go on their own, somewhere in left field in 
which 'Releases' are what everyone else calls 'Patch Sets'.  Oh well.

 

Add to that the Marketing Brand (9i, 10g, 11g, 12c ...) which confuses 
everyone, and the consistency between brand and version (WebLogic Server 12c 
(12.1.1), WebLogic Server 11g (10.3.6) as on and we have a lot of wailing and 
gnashing of teeth.

 

I'm sure  interns are not involved - it appears too deliberately disorganized 
to have been accomplished by novices unless perhaps over Tequila Parties ...

 

At least they are using a 'registery' called the Oracle Inventory to hold a 
database of component versions that have been installed. Although that database 
is in XML !?!?? (Perhaps someone should write an External Table.
Like Tom Kyte's External Table mapping on the Alert.log ...)

 

/Hans

--

 <//www.freelists.org/webpage/oracle-l>
//www.freelists.org/webpage/oracle-l

 

 

 

--

 <//www.freelists.org/webpage/oracle-l>
//www.freelists.org/webpage/oracle-l

 



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


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


Other related posts: