Re: oraenv ownership in RAC

Funny how Oracle still ships a version of oraenv and oratab that just don't quite do the job for RAC installs "out of the box". And things like bug 3497341...

Good for a chuckle.

On Thu, May 22, 2014 at 9:33 AM, Hans Forbrich <fuzzy.graybeard_at_gmail.com>wrote:

> Personally, I make sure these are owned by the oracle (DB) s/w owner,
> not GI. As well as oratab. The reason is that they tie closely to DBCA,
> whereas the interaction with ASM is effectively a once-only. And I believe
> they should be only updated when the newest DB patchset is applied, and
> then ... only if you have not customized them.
>
> Leads to the larger question - what are *you* using oraenv for?
>
> One use is to support dbstart/dbshut - however, in RAC environment, those
> are pretty much replaced by CRS.
>
> Since it sets ORACLE_SID/BASE/HOME for an instance (and cleans the PATH,
> it is very useful when the context is an INSTANCE. But my experience is
> that RAC interaction tends to be evenly spread between INSTANCE and DB at
> the command line, and programs should be normally access by SERVICE instead
> of either SID or DBNAME.
>
> Top of head, I can not remember whether oratab stores SID or DBNAME *in a
> RAC environment*, but I've pretty much had to go fiddle with oratab every
> RAC install to make oraenv useful. Eventually I gave up, which is sad
> because I believe oraenv is a powerful tool.
>
> /Hans
>
>
> On 22/05/2014 7:48 AM, Ruel, Chris wrote:
>
> Cluster details:
>
>
>
> GI 11.2.0.3
>
> DB 11.2.0.3
>
>
>
> 2 node cluster on OEL with RH compatible kernel.
>
>
>
> 2 owner install: grid owns GI, oracle owns DB
>
>
>
> Question: When the DB software is installed, running root.sh gives you
> the option of overwriting the files in /usr/local/bin. Should I leave them
> as the grid root.sh put them there or should the DB software overwrite
> them? What is considered “correct” or “best practice”? They seem to be
> quite different. For example, currently, on the cluster on which I am
> working, it seems on one node, the scripts were overwritten and on the
> other they were not (I did not do the installs):
>
>
>
> Node 1:
>
>
>
> [oracle_at_nc2tldb04c ~]$ cd /usr/local/bin
>
> [oracle_at_nc2tldb04c bin]$ ls -l
>
> total 64
>
> -rwxr-xr-x 1 grid root 5778 Jun 4 2013 coraenv
>
> -rwxr-xr-x 1 grid root 2415 Jun 4 2013 dbhome
>
> ...
>
> -rwxr-xr-x 1 grid root 6183 Jun 4 2013 oraenv
>
> ...
>
> [oracle_at_nc2tldb04c bin]$
>
>
>
> Node 2:
>
>
>
> [oracle_at_nc2tldb03c bin]$ ls -l
>
> total 64
>
> -rwxr-xr-x 1 oracle root 4143 Aug 5 2013 coraenv
>
> -rwxr-xr-x 1 oracle root 2415 Aug 5 2013 dbhome
>
> ...
>
> -rwxr-xr-x 1 oracle root 4785 Aug 5 2013 oraenv
>
> ...
>
> [oraloads_at_nc2tldb03c bin]$
>
>
>
> I am actually running into an issue where I have a user which runs our ETL
> jobs can’t successfully execute oraenv where it is owned by grid:
>
>
>
> [oraloads_at_nc2tldb04c ~]$ export ORACLE_BASE=/u01/app/oracle
>
> [oraloads_at_nc2tldb04c ~]$ . oraenv
>
> ORACLE_SID = [oraloads] ? por09r2
>
> ORACLE_BASE environment variable is not being set since this
>
> information is not available for the current user ID oraloads.
>
> You can set ORACLE_BASE manually if it is required.
>
>
>
> You can see, I actually am setting ORACLE_BASE manually, but, I still get
> the error. This works fine on the node where oraenv is owned by the oracle
> user.
>
>
>
> FWIW, the connect still works after running oraenv and getting the error,
> but, I want to make things consistent, right, and clean as possible.
>
>
>
> Thanks for any insight!
>
>
>
> Chris Ruel..
>
>
>
>
>
>
>
>
>
> Chris Ruel * Oracle Database Administrator
>
> cruel_at_lfg.com * Desk:317.759.2172 * Cell 317.523.8482
>
>
>
> Notice of Confidentiality: **This E-mail and any of its attachments may
> contain
> Lincoln National Corporation proprietary information, which is privileged,
> confidential,
> or subject to copyright belonging to the Lincoln National Corporation
> family of
> companies. This E-mail is intended solely for the use of the individual or
> entity to
> which it is addressed. If you are not the intended recipient of this
> E-mail, you are
> hereby notified that any dissemination, distribution, copying, or action
> taken in
> relation to the contents of and attachments to this E-mail is strictly
> prohibited
> and may be unlawful. If you have received this E-mail in error, please
> notify the
> sender immediately and permanently delete the original and any copy of
> this E-mail
> and any printout. Thank You.**
>
>
>

-- 
Charles Schultz

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