To see who has "the power", you can use crsctl getperm (and setperm to
change). It's equal to the unix permission method.
For TNS-files, we create a symlink of every ORACLE_HOME to a specific
$ORACLE_BASE/network/admin directory - there we configure the master files,
which are used in all O_H (and GRID_HOME as well) - but that's only our
strategy, not sure if it fits your requirements.
hth
Martin
2017-09-02 21:35 GMT+02:00 Mladen Gogala <gogala.mladen@xxxxxxxxx>:
I understand that, that is why I haven't asked whether this is a bug or
not. I was under the impression that the separation of duties serves to
prevent the DBA personnel from messing up storage configuration on the
system. In other words, I assumed that "grid" can do everything that
"oracle" can do, while reverse is not the case. In any case, my question
was whether this behaviour is new with 12cR2 or was this the case with the
previous releases as well?
Another problem with RAC is TNS names resolution. The default TNS_ADMIN is
$ORACLE_HOME/network/admin, while the listener is on
$GRID_HOME/network/admin. If I want to maintain both the listener and
tnsnames.ora in the same location, for reasons of practicality, I have to
set TNS_ADMIN for the database:
[oracle@rac1 ~]$ srvctl getenv database -d rac12
rac12:
TNS_ADMIN=/app/grid/12.2.0/network/admin
[oracle@rac1 ~]$
That means that the user "grid" has control over the TNS configuration of
the database. It is strange that user grid, with all that power cannot
start and stop database instances.
On 09/02/2017 03:11 PM, Matthew Parker wrote:
Standard separation of duties, which was the purpose of having a grid and
an oracle user.
*Matthew Parker*
*Chief Technologist*
*Dimensional DBA*
*425-891-7934 (cell)*
*D&B *047931344
*CAGE *7J5S7
*Dimensional.dba@xxxxxxxxxxx* <Dimensional.dba@xxxxxxxxxxx>
*View Matthew Parker's profile on LinkedIn*
<http://www.linkedin.com/pub/matthew-parker/6/51b/944/>
www.dimensionaldba.com
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@
freelists.org <oracle-l-bounce@xxxxxxxxxxxxx>] *On Behalf Of *Mladen
Gogala
*Sent:* Saturday, September 2, 2017 11:39 AM
*To:* oracle-l <oracle-l@xxxxxxxxxxxxx> <oracle-l@xxxxxxxxxxxxx>
*Subject:* Grid owner cannot start the database?
Hi!
I was playing with my brand new 12.2 RAC and I tried starting it from the
user "grid":
[grid@rac2 ~]$ srvctl start db -d rac12
PRCR-1079 : Failed to start resource ora.rac12.db
CRS-2527: Unable to start 'ora.rac12.db' because it has a 'hard'
dependency on 'ora.acfs.acfs.acfs'CRS-0245: User doesn't have enough
privilege to perform the operation
Apparently, the GI owner doesn't have enough privileges for this
operation. When I log in as "oracle", I have no problems whatsoever:
mgogala@umajor:~/mp3$ ssh oracle@rac1
Last login: Thu Aug 31 21:15:06 2017
[oracle@rac1 ~]$ srvctl start db -d rac12
[oracle@rac1 ~]$ srvctl status db -d rac12
Instance rac121 is running on node rac1
Instance rac122 is running on node rac2
[oracle@rac1 ~]$ [oracle@rac1 ~]$ sqlplus scott/tiger@scan12/orclpdb.
home.com
SQL*Plus: Release 12.2.0.1.0 Production on Sat Sep 2 14:33:51 2017
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Last Successful login time: Sat Sep 02 2017 14:33:30 -04:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit
Production
SQL>
This looks a bit counter-intuitive. Why would the user grid not be allowed
to start the databases? This is the only RAC configuration I have, so I
can't check releases 11G and 12cR1. Does the same thing happen there or is
it specific to the new release?
Regards
--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217
--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217
