Wie in den Kommentaren ausgeführt, besteht das Problem darin, dass Runtime.getRuntime().exec durch EXTPROC und damit durch den Grid Listener läuft. Da wir in unserer neuen Konfiguration eine OS-Benutzerisolierung zwischen DB und GRID haben, führte dies zu einem Berechtigungsproblem auf dem FS.
Die Lösung dafür ist eine der folgenden:
-
Korrigieren Sie die FS-Berechtigung, damit Grid-Benutzer die Dateien schreiben und umask auf etwas wie 774 oder 664 ändern können, sodass sowohl Grid- als auch Oracle-Benutzer die Dateien später ändern können;
-
sudoers-Datei ändern und Grid erlauben, die Befehle auszuführen, die als Orakel ohne Passwort benötigt werden, und Shell-Skript so ändern, dass es sudo enthält;
-
Erstellen Sie einen neuen Listener auf DB Home auf einem anderen Port und ändern Sie den TNSNAMES.ORA-Eintrag so, dass er auf den neuen Port zeigt. Dann wird extproc als OS-Benutzer oracle ausgeführt. Sie müssen LISTENER.ORA auf $OH manuell bearbeiten und mit lsnrctl starten, da mit srvctl registrierte Listener immer per Grid;
gestartet werden -
Ändern Sie den Haupt-Listener auf das db home. Ich empfehle das nicht (siehe Punkt oben).
[BEARBEITEN]Wie von @AlexPoole und @jonearles hervorgehoben, gibt es zwei weitere Optionen, die für meinen Fall nicht geeignet waren, aber für andere möglicherweise geeignet sind:
- Wenn Sie das Skript lokal auf sqlplus ausführen und ORACLE_SID festlegen, erfolgt der FS-Zugriff durch den Betriebssystembenutzer, der sqlplus ausführt. Sie können also als Orakel oder ein anderer Benutzer ausführen und die FS-Berechtigungen ändern;
- Wenn Sie einen Job auf dem dbms_job-Scheduler als SYS planen, wird der Task von Oracle ausgeführt (dieses Verhalten kann von der Version abhängig sein, daher sind weitere Tests erforderlich).
Grüße,
Daniel Stolf
