====Oracle User kann die ASM Platten im Cluster nicht lesen - ORA-17503: ksfdopn:10 Failed to open file====

==== Problem ====
Folgender Fehler trat nach der Installation eines 12c Rac mit einer 11g Datenbank beim anlegen der Datenbank auf dem zweiten Knoten auf:

<code SQL>
SYS@GPIRP2-?>startup
ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '+DATA01/GPIRP/spfileGPIRP.ora'
ORA-17503: ksfdopn:10 Failed to open file +DATA01/GPIRP/spfileGPIRP.ora
ORA-01034: ORACLE not available
ORA-27123: unable to attach to shared memory segment
Linux-x86_64 Error: 13: Permission denied
Additional information: 2667
Additional information: 223936514
</code>

Das Cluster läuft unter dem User "GRID", die Datenbank unter dem User "ORACLE".

Wird unter dem User Oracle dann versucht mit ASMCMD auf die ASM Platten zuzugreifen:
<code bash>
asmcmd
Connected to an idle instance.
</code>
Umgebung ist aber nichtig gesetzt!

==== Lösung ====

===Gruppen Zuordnung prüfen ===

Eine Ursache kann sein das der Oracle User nicht in der Gruppe ist, die die ASM Platten lesen kann.

Prüfen als root:
<code bash>
ls -la /dev/oracleasm/disks/*
brw-rw---- 1 grid asmadmin 252, 34 Apr  8 13:46 /dev/oracleasm/disks/ACFS1_S1

#Die gemeinsame Gruppe ist also asmadmin 

[root@tng3db02 ~]# id grid
uid=1101(grid) gid=54321(oinstall) groups=54322(dba),1002(asmadmin),54321(oinstall)

[root@tng3db02 ~]# id oracle
uid=54321(oracle) gid=54321(oinstall) groups=54322(dba),1002(asmadmin),54321(oinstall)
</code>
Sind beide in der richtigen Gruppe kann es daran nicht mehr liegen

=== Rechte auf der Oracle Binary===


Rechte auf den Oracle Binaries unter dem Oracle UND dem Grid User kontrollieren auf beiden Knoten:
<code bash>
#Grid User 
ls -la $ORACLE_HOME/bin/oracle

#Knoten 1
-rwxr-x--x 1 grid oinstall 291326028 Apr  4 22:23 oracle

#Knoten 2
-rwsr-s--x 1 grid oinstall 291326028 Apr  4 18:09 oracle

-------------

#DB User

ls -la $ORACLE_HOME/bin/oracle

#Knoten 1
-rwsr-s--x 1 oracle asmadmin 227003989 Apr  4 21:39 oracle
#Knoten 2
-rwsr-s--x 1 oracle asmadmin 227003989 Apr  4 21:39 oracle

</code>

ALLE oracle binariey müssen die Rechte "-rwsr-s--x" besitzen, achten Sie auf das **"s"**!
Siehe dazu => [[linux:linux_setuid_getgid_stickybit|Besondere Berechtigungen auf Dateien und Verzeichnissen unter Linux -  File Permissions (setuid, setgid and Sticky Bit)]]

Hier fehlt das auf einer der Binaries, und das hat diese ganzen Ärger verursacht!

<fc #800000>**Lösung:**</fc>
<code bash>
#Als User root
# in unseren fall auf dem Grid Home auf Knoten 2
chmod 6751 $ORACLE_HOME/bin/oracle
</code>

Knoten 2 dann neustarten und das was die Lösung!

=== Cluster Temp ===

Eine Lösung bei Berechtigungsfehlern im Cluster kann auch das Löschen der Temp Files des Clusters sein:
<code bash>
#Cluster start bei boot ausschalten 
/opt/12.1.0.2/grid/bin/crsctl disable crs

#Neu Starten
reboot

# Temp files löschen
cd /var/tmp/.oracle/
rm -f *

#Cluster start bei boot  einschalten
/opt/12.1.0.2/grid/bin/crsctl enable crs

#Cluster starten
/opt/12.1.0.2/grid/bin/crsctl start  crs

#prüfen
/opt/12.1.0.2/grid/bin/crsctl check  crs

</code>
Das tritt aber mehr mit Fehlern im Umfeld des Starten das Clusters auf.


==== Quellen ====

siehe auch http://ora10gadmin.blogspot.de/2014/11/ora-17503-ksfdopn2-failed-to-open-file.html