Problem, jak wskazano w komentarzach, polega na tym, że Runtime.getRuntime().exec działa przez EXTPROC, a więc przez odbiornik siatki. Ponieważ w naszej nowej konfiguracji mamy izolację użytkowników systemu operacyjnego między DB i GRID, spowodowało to problem z uprawnieniami w FS.
Rozwiązaniem tego jest jedno z poniższych:
-
Napraw uprawnienia FS, aby umożliwić użytkownikowi grida zapisywanie plików i zmianę umask na coś takiego jak 774 lub 664, dzięki czemu zarówno użytkownicy grida, jak i Oracle będą mogli później modyfikować pliki;
-
zmień plik sudoers i zezwól gridowi na wykonywanie poleceń wymaganych jako wyrocznia bez hasła i zmień skrypt powłoki, aby zawierał sudo;
-
utwórz nowy nasłuch w DB Home na innym porcie i zmień wpis TNSNAMES.ORA tak, aby wskazywał na nowy port. Następnie extproc zostanie uruchomiony jako wyrocznia użytkownika systemu operacyjnego. Będziesz musiał ręcznie wyedytować LISTENER.ORA na $OH i uruchomić go z lsnrctl, ponieważ detektory zarejestrowane z srvctl będą zawsze uruchamiane przez siatkę;
-
zmień głównego słuchacza na db home. Nie polecam (patrz punkt powyżej).
[EDIT]Jak wskazał @AlexPoole i @jonearles, istnieją dwie inne opcje, które nie pasowały do mojego przypadku, ale mogą być dla innych:
- jeżeli uruchomisz skrypt lokalnie na sqlplus, ustawiając ORACLE_SID, dostęp do FS będzie wykonywany przez użytkownika systemu operacyjnego używającego sqlplus. Możesz więc uruchomić jako oracle lub inny użytkownik i poprawić uprawnienia FS;
- Jeśli zaplanujesz zadanie w harmonogramie zadań dbms_job jako SYS, zadanie zostanie wykonane przez Oracle (to zachowanie może być zależne od wersji, więc potrzebne są dalsze testy).
Pozdrawiam,
Daniel Stolf
