Problemet, som påpekats i kommentarerna, är att Runtime.getRuntime().exec körs genom EXTPROC, och därmed genom Grid Listener. Eftersom vi har OS-användarisolering mellan DB och GRID på vår nya konfiguration, väckte detta ett behörighetsproblem på FS.
Lösningen på detta är en av följande:
-
Fixa FS-behörighet för att låta grid-användare skriva filerna och ändra umask till något som 774 eller 664, så att både grid- och oracle-användare kommer att kunna ändra filerna senare;
-
ändra sudoers-fil och tillåt grid att köra de kommandon som behövs som oracle utan lösenord och ändra skalskriptet till att inkludera sudo;
-
skapa en ny lyssnare på DB Home på en annan port och ändra TNSNAMES.ORA-posten så att den pekar på den nya porten. Sedan kommer extproc att köras som OS-användaroracle. Du måste manuellt redigera LISTENER.ORA på $OH och starta den med lsnrctl, eftersom lyssnare som är registrerade med srvctl alltid startas av grid;
-
byt huvudavlyssnare till db-hemmet. Jag rekommenderar inte det (se punkten ovan).
[EDIT]Som påpekat av @AlexPoole och @jonearles, finns det två andra alternativ som inte passade för mitt fall, men som kan vara för andra:
- om du kör skriptet lokalt på sqlplus, inställning av ORACLE_SID, kommer FS-åtkomsten att göras av OS-användaren som kör sqlplus. Så du kan köra som oracle, eller någon annan användare och fixa FS-behörigheterna;
- om du schemalägger ett jobb på dbms_job scheduler som SYS, kommer uppgiften att köras av Oracle (detta beteende kan vara versionsberoende, så ytterligare testning behövs).
Hälsningar,
Daniel Stolf