====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:
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
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:
asmcmd
Connected to an idle instance.
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:
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)
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:
#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
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!
**Lösung:**
#Als User root
# in unseren fall auf dem Grid Home auf Knoten 2
chmod 6751 $ORACLE_HOME/bin/oracle
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:
#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
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