Re: oraenv ownership in RAC
Date: Thu, 22 May 2014 08:33:29 -0600
Message-ID: <537E0AB9.1040202_at_gmail.com>
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 <mailto: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.**
>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu May 22 2014 - 16:33:29 CEST