Le problème, comme indiqué dans les commentaires, est que Runtime.getRuntime().exec s'exécute via EXTPROC, et donc via Grid Listener. Étant donné que nous avons une isolation des utilisateurs du système d'exploitation entre DB et GRID sur notre nouvelle configuration, cela a soulevé un problème d'autorisation sur le FS.
La solution à cela est l'une des suivantes :
-
Correction de l'autorisation FS pour permettre à l'utilisateur de la grille d'écrire les fichiers et de remplacer umask par quelque chose comme 774 ou 664, afin que les utilisateurs de la grille et de l'oracle puissent modifier les fichiers plus tard ;
-
modifier le fichier sudoers et autoriser la grille à exécuter les commandes nécessaires en tant qu'oracle sans mot de passe et modifier le script shell pour inclure sudo ;
-
créez un nouvel écouteur sur DB Home sur un autre port et modifiez l'entrée TNSNAMES.ORA pour qu'elle pointe vers le nouveau port. Ensuite, extproc sera exécuté en tant qu'utilisateur oracle du système d'exploitation. Vous devrez éditer manuellement LISTENER.ORA sur $OH et le démarrer avec lsnrctl, car les listeners enregistrés avec srvctl seront toujours démarrés par grid;
-
changez l'écouteur principal en db home. Je ne le recommande pas (voir article ci-dessus).
[EDIT] Comme l'ont souligné @AlexPoole et @jonearles, il existe deux autres options qui ne convenaient pas à mon cas, mais qui pourraient convenir à d'autres :
- si vous exécutez le script localement sur sqlplus, en définissant ORACLE_SID, l'accès FS sera effectué par l'utilisateur du système d'exploitation exécutant sqlplus. Vous pouvez donc exécuter en tant qu'oracle ou un autre utilisateur et corriger les autorisations FS ;
- si vous planifiez une tâche sur dbms_job scheduler en tant que SYS, la tâche sera exécutée par oracle (ce comportement peut dépendre de la version, des tests supplémentaires sont donc nécessaires).
Cordialement,
Daniel Stolf
