关于oracle文件权限的问题

在Oracle数据库中，经常会遇到因为$ORACLE_HOME/bin/oracle文件或$GRID_HOME/bin/oracle文件权限的改变，而导致数据库或grid无法使用的情况。

昨天同样又遇到一个情况，Oracle 11.2.0.4在安装完最新的psu补丁20160719后，出现crs，grid都能启动，但是数据库无法启动的问题。错误信息如下：
[oracle@crm4gdb2 ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Mon Jul 25 15:36:35 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '+DATA/testdb/spfiletestdb.ora'
ORA-17503: ksfdopn:10 Failed to open file +DATA/testdb/spfiletestdb.ora
ORA-12547: TNS:lost contact
SQL> 

错误提示无法读取数据库参数文件。登录grid用户下，然后使用asmcmd查看，lsdg查看DG是mount状态，同时spfile也是正常的，但使用oracle用户就是不能读取它自己的spfile。

检查grid用户下的$GRID_HOME/bin/oracle权限，很明显权限不对，权限为0755的权限：
[grid@testdb1 bin]$ ls -ltr oracle
-rwxr-xr-x. 1 grid oinstall 210122931 Jul 25 11:18 oracle

修改oracle的权限为6755：
[grid@testdb1 bin]$ chmod 6755 oracle
[grid@testdb1 bin]$ ls -l oracle
-rwsr-sr-x. 1 grid oinstall 210122931 Jul 25 11:18 oracle
[grid@testdb1 bin]$ 

再启动数据库后就一切正常。
这个数据库在升级psu 20160719补丁之前客户说数据库是正常运行的，但是升级之后就出现这个权限问题。按理来说，oracle应该不会犯这种发的包权限不对的低级错误，有可能是在数据库运行的时候有人修改过权限。而数据库在运行的过程中继承修改之前的权限，重启之后就存在问题。

－－－－－－－－
关于oracle文件的权限，平时需要注意，轻易不要去修改。记得oracle的权限应该是6755，前面那个必须是6
如果oracle用户下的$ORACLE_HOME/bin/oracle文件权限被修改，可能会导致用户连接oracle连接不上。在11g RAC数据库中，监听进程是grid用户启动的，也就是说是grid用户访问oracle用户下的文件，如果oracle文件权限的suid和sgid位清零，就会在Listener的日志中提示连接中断（broken pipe ？）而无法连接数据库。

同样对于11g RAC中，由于oracle用户下的数据库需要访问grid用户下的ASM，因此grid用户下的$GRID_HOME/bin/oracle权限suid和sgid位被清零，则会出现上述的问题，oracle数据库无法访问到grid的ASM文件，而导致数据库无法启动。

关于Linux系统下的共享文件介绍。
我们平时知道在Linux系统下，权限有三个组类：当前用户、同组其他用户、其他用户，这三个组中分别有读、写、执行三种权限。
但是在大的环境中创建文件并将文件与其他用户共享，会比较繁琐。Linux通过为每个文件和目录存储了三个信息位来进行处理：
设置用户ID（SUID）：当文件被用户使用时，程序会以文件属主的权限运行。
设置组ID（SGID）：对文件来说，程序会以文件属组的权限运行；对目录来说，目录中创建的心文件会以目录的默认属组作为默认属组。
粘着位（ sticky）：进程结束后文件还会在内存中。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23850820/viewspace-2122545/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23850820/viewspace-2122545/