Problém, jak bylo zdůrazněno v komentářích, je ten, že Runtime.getRuntime().exec běží přes EXTPROC, a tedy přes Grid Listener. Vzhledem k tomu, že v naší nové konfiguraci máme izolaci uživatelů OS mezi DB a GRID, vyvolalo to problém s oprávněními na FS.
Řešením je jedno z níže uvedených:
-
Opravte oprávnění FS, aby uživatel gridu mohl zapisovat soubory a změnit umask na něco jako 774 nebo 664, takže uživatelé gridu i oracle budou moci soubory později upravovat;
-
změnit soubor sudoers a umožnit gridu spouštět příkazy potřebné jako oracle bez hesla a změnit skript shellu tak, aby obsahoval sudo;
-
vytvořte nový posluchač na DB Home na jiném portu a změňte položku TNSNAMES.ORA tak, aby ukazovala na nový port. Poté bude extproc spuštěn jako uživatel OS oracle. Budete muset ručně upravit LISTENER.ORA na $OH a spustit jej pomocí lsnrctl, protože posluchači registrovaní pomocí srvctl budou vždy spuštěni mřížkou;
-
změnit hlavní posluchač na domovskou stránku db. Nedoporučuji to (viz položka výše).
[EDIT]Jak zdůraznili @AlexPoole a @jonearles, existují dvě další možnosti, které se nehodily pro můj případ, ale mohly by být vhodné pro jiné:
- Pokud skript spustíte lokálně na sqlplus s nastavením ORACLE_SID, přístup k FS provede uživatel operačního systému se spuštěným sqlplus. Takže můžete běžet jako oracle nebo jiný uživatel a opravit oprávnění FS;
- Pokud naplánujete úlohu v plánovači dbms_job jako SYS, bude úloha provedena oracle (toto chování může být závislé na verzi, takže je potřeba další testování).
S pozdravem
Daniel Stolf