Проблемът, както е посочено в коментарите, е, че Runtime.getRuntime().exec работи през EXTPROC и по този начин през Grid Listener. Тъй като имаме изолация на потребителите на ОС между DB и GRID в нашата нова конфигурация, това повдигна проблем с разрешението на FS.
Решението за това е едно от следните:
-
Коригирайте разрешението на FS, за да позволите на потребителя на мрежата да пише файловете и да промените umask на нещо като 774 или 664, така че потребителите на мрежата и оракул да могат да променят файловете по-късно;
-
променете sudoers файла и позволете на мрежата да изпълнява командите, необходими като оракул без парола и променете shell скрипта, за да включи sudo;
-
създайте нов слушател на DB Home на друг порт и променете записа в TNSNAMES.ORA, за да сочи към новия порт. След това extproc ще се изпълни като OS user oracle. Ще трябва ръчно да редактирате LISTENER.ORA на $OH и да го стартирате с lsnrctl, тъй като слушателите, регистрирани с srvctl, винаги ще бъдат стартирани от мрежа;
-
променете основния слушател на db home. Не препоръчвам това (вижте елемента по-горе).
[EDIT]Както беше посочено от @AlexPoole и @jonearles, има две други опции, които не бяха подходящи за моя случай, но може да са за други:
- ако стартирате скрипта локално на sqlplus, като зададете ORACLE_SID, достъпът до FS ще бъде направен от потребителя на ОС, работещ с sqlplus. Така че можете да стартирате като oracle или друг потребител и да коригирате разрешенията на FS;
- ако планирате задание на dbms_job Scheduler като SYS, задачата ще бъде изпълнена от Oracle (това поведение може да зависи от версията, така че е необходимо допълнително тестване).
Поздрави,
Даниел Столф
