Il problema, come sottolineato nei commenti, è che Runtime.getRuntime().exec viene eseguito tramite EXTPROC e quindi tramite Grid Listener. Poiché abbiamo l'isolamento degli utenti del sistema operativo tra DB e GRID sulla nostra nuova configurazione, ciò ha sollevato un problema di autorizzazione su FS.
La soluzione a questo è una delle seguenti:
-
Risolto il problema con l'autorizzazione FS per consentire all'utente della griglia di scrivere i file e modificare umask in qualcosa come 774 o 664, quindi sia gli utenti della griglia che quelli di Oracle potranno modificare i file in un secondo momento;
-
cambia il file sudoers e consenti alla griglia di eseguire i comandi necessari come oracle senza password e cambia lo script della shell per includere sudo;
-
creare un nuovo listener su DB Home su un'altra porta e modificare la voce TNSNAMES.ORA in modo che punti alla nuova porta. Quindi extproc verrà eseguito come oracle dell'utente del sistema operativo. Dovrai modificare manualmente LISTENER.ORA su $OH e avviarlo con lsnrctl, perché i listener registrati con srvctl verranno sempre avviati dalla griglia;
-
cambia l'ascoltatore principale nella home del db. Non lo consiglio (vedi voce sopra).
[EDIT]Come sottolineato da @AlexPoole e @jonearles, ci sono altre due opzioni che non erano adatte al mio caso, ma potrebbero esserlo per altre:
- se esegui lo script in locale su sqlplus, impostando ORACLE_SID, l'accesso FS verrà effettuato dall'utente del sistema operativo che esegue sqlplus. Quindi puoi eseguire come Oracle o qualche altro utente e correggere i permessi di FS;
- se pianifichi un lavoro su dbms_job scheduler come SYS, l'attività verrà eseguita da Oracle (questo comportamento potrebbe dipendere dalla versione, quindi sono necessari ulteriori test).
Saluti,
Daniel Stolf
