srvctl -p option part II

This is an update on my earlier post “srvctl -p option“, which reported that srvctl modify database with the -p option does not work as documented. Thanks to Surachart for providing his findings in the comments and thanks to Neil for providing me with a chance to test this in another environment.

The key turned out to be the permissions on $ORACLE_HOME/dbs, but whilst the original problem has been solved another question has been raised…

As commented in the update on the original post I have installed 11.2 with both “grid” and “oracle” users. I had previously noticed that srvctl config shows the “Oracle user” as “grid”, but that the documentation for srvctl modify database -u states that the user should be the “Name of the Oracle user who owns the Oracle home directory”. Interestingly srvctl add database does not have a -u option, but does have a -o option to specify the full path to the $ORACLE_HOME (thanks to Pawel for pointing that out) which suggests (to me at least) that srvctl add database derives the “Oracle user” from the permissions on ORACLE_HOME.

Anyway, the crux of this is that allowing group write on $ORACLE_HOME/dbs allows srvctl modify database with the -p option to work as documented and shown below:

Removing the spfile configuration:

[oracle@gg01 ~]$ srvctl modify database -d gg01 -p ' '
[oracle@gg01 ~]$ srvctl config database -d gg01
Database unique name: gg01
Database name: gg01
Oracle home: /u01/app/oracle/product/11.2.0/db_1
Oracle user: grid
Spfile:
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups: DATA
Services:

Confirming groups for “grid” user and changing $ORACLE_HOME/dbs permissions:

[oracle@gg01 ~]$ id grid
uid=501(grid) gid=501(oinstall) groups=501(oinstall),500(dba),503(asmadmin),504(asmoper),505(asmdba)
[oracle@gg01 ~]$ chmod g+w /u01/app/oracle/product/11.2.0/db_1/dbs
[oracle@gg01 ~]$ ls -ld /u01/app/oracle/product/11.2.0/db_1/dbs
drwxrwxr-x 2 oracle oinstall 4096 Jan 14 22:22 /u01/app/oracle/product/11.2.0/db_1/dbs

Stopping the database and removing the pfile:

[oracle@gg01 ~]$ srvctl stop database -d gg01
[oracle@gg01 ~]$ mv /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora.bak

Setting the spfile parameter:

[oracle@gg01 ~]$ srvctl modify database -d gg01 -p '+DATA/gg01/spfilegg01.ora'
[oracle@gg01 ~]$ srvctl config database -d gg01
Database unique name: gg01
Database name: gg01
Oracle home: /u01/app/oracle/product/11.2.0/db_1
Oracle user: grid
Spfile: +DATA/gg01/spfilegg01.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups: DATA
Services:

Confirming that the pfile has not been created:

[oracle@gg01 ~]$ ls -l /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora
ls: /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora: No such file or directory

Starting the database and confirming that the pfile has been created:

[oracle@gg01 ~]$ srvctl start database -d gg01
[oracle@gg01 ~]$ ls -l /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora
-rw-r--r-- 1 grid   oinstall   58 Jan 14 22:32 /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora
[oracle@gg01 ~]$ cat /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora
SPFILE='+DATA/gg01/spfilegg01.ora' # line added by Agent
[oracle@gg01 ~]$

The part of all this that still confuses me is that the srvctl “Oracle user” for the database is set to “grid” rather than “oracle” when using srvctl add database. As I see it, either the permissions on $ORACLE_HOME/dbs is a bug or setting “grid” as the “Oracle user” is a bug because the two don’t work together with the srvctl -p option… Interestingly changing the “Oracle user” to “oracle” when a pfile pointing to the spfile already exists does allow the database to start, but trying to start a database with “Oracle user” set to “oracle”, having write permissions to $ORACLE_HOME/dbs, but no existing pfile in $ORACLE_HOME/dbs does not work (at least for me) as shown below:

[oracle@gg01 ~]$ srvctl stop database -d gg01
[oracle@gg01 ~]$ mv /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora.bak
[oracle@gg01 ~]$ su
Password: 
[root@gg01 oracle]# srvctl modify database -d gg01 -u oracle
[root@gg01 oracle]# exit
exit
[oracle@gg01 ~]$ ls -ld $ORACLE_HOME/dbs
drwxr-xr-x 2 oracle oinstall 4096 Jan 20 20:37 /u01/app/oracle/product/11.2.0/db_1/dbs
[oracle@gg01 ~]$ srvctl modify database -d gg01 -p ' '
[oracle@gg01 ~]$ srvctl modify database -d gg01 -p '+DATA/gg01/spfilegg01.ora'
[oracle@gg01 ~]$ srvctl config database -d gg01
Database unique name: gg01
Database name: gg01
Oracle home: /u01/app/oracle/product/11.2.0/db_1
Oracle user: oracle
Spfile: +DATA/gg01/spfilegg01.ora
Domain: 
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups: DATA
Services: 
[oracle@gg01 ~]$ srvctl status database -d gg01
Database is not running.
[oracle@gg01 ~]$ ls -l $ORACLE_HOME/dbs/initgg01.ora
ls: /u01/app/oracle/product/11.2.0/db_1/dbs/initgg01.ora: No such file or directory
[oracle@gg01 ~]$ srvctl start database -d gg01
PRCR-1079 : Failed to start resource ora.gg01.db
CRS-2674: Start of 'ora.gg01.db' on 'gg01' failed
[oracle@gg01 ~]$ chmod g+w $ORACLE_HOME/dbs
[oracle@gg01 ~]$ su
Password: 
[root@gg01 oracle]# srvctl modify database -d gg01 -u grid
[root@gg01 oracle]# exit
exit
[oracle@gg01 ~]$ srvctl start database -d gg01
[oracle@gg01 ~]$ 

I think it is now time for me to leave this alone, although please feel free to comment.

About these ads

3 thoughts on “srvctl -p option part II

  1. Pingback: srvctl -p option « ORAganism

    • I had this same problem. The issue and resolution are documented in Metalink Doc 985743.1.

      Grid Infrastructure owner must be part of OSDBA group if the database needs to be managed by srvctl. I also had to add group write permission to the $OH/dbs directory before I could use srvctl to start and stop the DB.

  2. I was facing the similar issue while starting the database which is registered to Oracle Restart. I don’t have metalink login as of now. This was very helpful and the problem is resolved after providing write access to $OH/dbs directory.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s