Das Problem:
Mit UTL_FILE soll in einer Oracle RAC Umgebung aus der Datenbank auf einen NFS Share geschrieben werden.
Beim Schreiben über eine vom Anwender aufgerufenen PL/SQL Procedure wird der folgende Fehler gerufen:
Error: no permission - -29283 - ORA-29283: niepoprawna operacja na pliku ORA-06512: przy "SYS.UTL_FILE", linia 41 ORA-06512: przy "SYS.UTL_FILE", linia 512 ORA-29283: niepoprawna operacja na pliku
Kontrolle der Umgebung:
Um das ganze sauber zu testen wird der folgnde Testcase verwandt um eine einfache Datei zu schreiben und zu lesen:
-- create directory with the link to the nfs CREATE OR REPLACE directory WRITE_TEST AS '/nfs/share/data'; -- test SET serveroutput ON DECLARE input_file utl_file.file_type; input_buffer varchar2(32767); BEGIN input_file := UTL_FILE.FOPEN('WRITE_TEST', 'oracle_db_export.txt','w'); UTL_FILE.PUT_LINE(input_file, 'This is a line in the export file'); utl_file.fclose(input_file); END; / SET serveroutput ON DECLARE input_file utl_file.file_type; input_buffer varchar2(32767); BEGIN input_file := UTL_FILE.FOPEN('WRITE_TEST', 'oracle_db_export.txt','r',32767); utl_file.get_line (input_file,input_buffer); dbms_output.put_line(input_buffer); utl_file.fclose(input_file); END; /
Mit dem Testcase tritt der Fehler NUR auf, wenn die Verbindung zur DB via SQL*Net über einem im Cluster registrierten Service aufgebaut wird.
Die User oracle und grid sind Mitglieder in der Gruppe, die auf das NFS schreiben darf. Die Gruppe heißt NFS_SHARE
id oracle id grid
Auf die groups achten, dass bei beiden die NFS_SHARE auch hinterlegt sind.
Da die Rechte vorhanden sind, muss das Problem muss etwas mit dem Rechten zu tun haben unter dem der Listener Prozess auf der Umgebung läuft.
Auf jeden Knoten über die Datei /proc/<prozess_id>/status prüfen:
-- Process id des Listener ermitteln ps uafx | grep LISTENER_GPI grid 5656 ... -- aktuelle Rechte des Listender prüfen -- auf die Spalte cat /proc/5656/status .. Groups: 509 607 1001 ..
Überprüfen ob die ID der NFS_SHARE in dieser Liste enthalten ist, falls nicht ist der Fehler gefunden!
Der gesamte Clusterstack muss nach einer Rechte Änderung am GRID Owner neu gestartet werden, eine Änderung der Rechte der User reicht nicht aus!
siehe Support Node für die Mount Optionen:
Zum Beispiel für DB Dateien und DataPump Exports unter Linux 64 :