El problema, como se señala en los comentarios, es que Runtime.getRuntime().exec se ejecuta a través de EXTPROC y, por lo tanto, a través de Grid Listener. Dado que tenemos aislamiento de usuario del sistema operativo entre DB y GRID en nuestra nueva configuración, esto planteó un problema de permisos en el FS.
La solución a esto es una de las siguientes:
-
Corrija el permiso de FS para permitir que el usuario de la cuadrícula escriba los archivos y cambie umask a algo como 774 o 664, de modo que tanto los usuarios de la cuadrícula como los de Oracle puedan modificar los archivos más adelante;
-
cambie el archivo sudoers y permita que grid ejecute los comandos necesarios como Oracle sin contraseña y cambie el script de shell para incluir sudo;
-
cree un nuevo oyente en DB Home en otro puerto y cambie la entrada TNSNAMES.ORA para que apunte al nuevo puerto. Luego, extproc se ejecutará como usuario del sistema operativo Oracle. Tendrá que editar manualmente LISTENER.ORA en $OH e iniciarlo con lsnrctl, porque los oyentes registrados con srvctl siempre se iniciarán con grid;
-
cambie el oyente principal a la base de datos de inicio. No lo recomiendo (ver artículo anterior).
[EDITAR] Como señalaron @AlexPoole y @jonearles, hay otras dos opciones que no eran adecuadas para mi caso, pero podrían serlo para otros:
- si ejecuta el script localmente en sqlplus, configurando ORACLE_SID, el usuario del sistema operativo que ejecuta sqlplus realizará el acceso a FS. Entonces puede ejecutar como Oracle, o algún otro usuario y corregir los permisos de FS;
- si programa un trabajo en el programador dbms_job como SYS, oracle ejecutará la tarea (este comportamiento puede depender de la versión, por lo que se necesitan más pruebas).
Saludos,
Daniel Stolf
