關於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/，如需轉載，請註明出處，否則將追究法律責任。