Problemet, som påpeget i kommentarerne, er, at Runtime.getRuntime().exec kører gennem EXTPROC, og dermed gennem Grid Listener. Da vi har OS-brugerisolering mellem DB og GRID på vores nye konfiguration, rejste dette et tilladelsesproblem på FS.
Løsningen på dette er en af nedenstående:
-
Ret FS-tilladelse til at lade grid-brugeren skrive filerne og ændre umask til noget som 774 eller 664, så både grid- og oracle-brugere vil være i stand til at ændre filerne senere;
-
skift sudoers-fil og tillad grid at udføre de nødvendige kommandoer som oracle uden adgangskode og skift shell-script til at inkludere sudo;
-
opret en ny lytter på DB Home på en anden port og skift TNSNAMES.ORA-indgangen til at pege på den nye port. Derefter vil extproc blive udført som OS bruger oracle. Du bliver nødt til manuelt at redigere LISTENER.ORA på $OH og starte den med lsnrctl, fordi lyttere, der er registreret med srvctl, altid vil blive startet af grid;
-
skift hovedlytter til db-hjemmet. Det anbefaler jeg ikke (se punkt ovenfor).
[EDIT]Som påpeget af @AlexPoole og @jonearles, er der to andre muligheder, der ikke var egnede til mit tilfælde, men som måske er for andre:
- hvis du kører scriptet lokalt på sqlplus, indstiller ORACLE_SID, vil FS-adgangen blive foretaget af OS-brugeren, der kører sqlplus. Så du kan køre som oracle eller en anden bruger og rette FS-tilladelserne;
- hvis du planlægger et job på dbms_job scheduler som SYS, vil opgaven blive udført af oracle (denne adfærd kan være versionsafhængig, så yderligere test er nødvendig).
Med venlig hilsen
Daniel Stolf