Inhaltsverzeichnis
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 ⇒ 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.