コメントで指摘されているように、問題は、Runtime.getRuntime（）。execがEXTPROCを介して実行されるため、グリッドリスナーを介して実行されることです。新しい構成では、DBとGRIDの間でOSユーザーが分離されているため、FSでアクセス許可の問題が発生しました。
これに対する解決策は次の1つです：
-
グリッドユーザーがファイルを書き込み、umaskを774や664などに変更できるように、FS権限を修正して、グリッドユーザーとOracleユーザーの両方が後でファイルを変更できるようにします。
-
sudoersファイルを変更し、グリッドがパスワードなしでoracleとして必要なコマンドを実行できるようにし、シェルスクリプトを変更してsudoを含めます。
-
別のポートのDBホームに新しいリスナーを作成し、TNSNAMES.ORAエントリを変更して新しいポートを指すようにします。次に、extprocがOSユーザーoracleとして実行されます。 srvctlに登録されたリスナーは常にグリッドによって開始されるため、$ OHでLISTENER.ORAを手動で編集し、lsnrctlで開始する必要があります;
-
メインリスナーをdbホームに変更します。私はそれをお勧めしません（上記の項目を参照してください）。
[編集]@AlexPooleと@jonearlesが指摘しているように、私の場合には適さなかったが、他の人には適している可能性のある他の2つのオプションがあります。
- ORACLE_SIDを設定してsqlplusでローカルにスクリプトを実行する場合、FSアクセスはsqlplusを実行しているOSユーザーによって行われます。したがって、オラクルまたは他のユーザーとして実行し、FS権限を修正できます。
- dbms_jobスケジューラでジョブをSYSとしてスケジュールすると、タスクはoracleによって実行されます（この動作はバージョンに依存する可能性があるため、さらにテストが必要です）。
よろしく、
ダニエル・ストルフ