Het probleem, zoals aangegeven in de opmerkingen, is dat Runtime.getRuntime().exec door EXTPROC loopt, en dus door de Grid Listener. Omdat we OS-gebruikersisolatie hebben tussen DB en GRID op onze nieuwe configuratie, veroorzaakte dit een toestemmingsprobleem op de FS.
De oplossing hiervoor is een van de onderstaande:
-
Fix FS-permissie om de rastergebruiker de bestanden te laten schrijven en umask te wijzigen in iets als 774 of 664, zodat zowel raster- als orakelgebruikers de bestanden later kunnen wijzigen;
-
verander het sudoers-bestand en laat het raster de commando's uitvoeren die nodig zijn als orakel zonder wachtwoord en verander het shellscript om sudo op te nemen;
-
maak een nieuwe listener op DB Home op een andere poort en wijzig de vermelding TNSNAMES.ORA om naar de nieuwe poort te wijzen. Dan wordt extproc uitgevoerd als OS-gebruikersorakel. Je moet LISTENER.ORA handmatig bewerken op $OH en het starten met lsnrctl, omdat luisteraars die zijn geregistreerd bij srvctl altijd worden gestart door raster;
-
verander de hoofdlistener naar de db home. Ik raad dat niet aan (zie item hierboven).
[EDIT]Zoals aangegeven door @AlexPoole en @jonearles, zijn er twee andere opties die niet geschikt waren voor mijn geval, maar misschien wel voor anderen:
- als je het script lokaal op sqlplus uitvoert en ORACLE_SID instelt, wordt de FS-toegang gemaakt door de OS-gebruiker die sqlplus draait. Dus je kunt als orakel of een andere gebruiker draaien en de FS-rechten herstellen;
- als u een taak plant op dbms_job scheduler als SYS, wordt de taak uitgevoerd door oracle (dit gedrag kan versie-afhankelijk zijn, dus verdere tests zijn nodig).
Groeten,
Daniel Stolf