Vấn đề, như đã chỉ ra trong các nhận xét, là Runtime.getRuntime ().. Thực thi chạy qua EXTPROC và do đó thông qua Grid Listener. Vì chúng tôi có sự cô lập người dùng hệ điều hành giữa DB và GRID trên cấu hình mới của chúng tôi, điều này đã gây ra sự cố về quyền trên FS.
Giải pháp cho vấn đề này là một trong những giải pháp dưới đây:
-
Sửa quyền FS để cho phép người dùng lưới ghi tệp và thay đổi umask thành một thứ gì đó như 774 hoặc 664, vì vậy cả người dùng lưới và người dùng oracle đều có thể sửa đổi tệp sau này;
-
thay đổi tệp sudoers và cho phép lưới thực thi các lệnh cần thiết như oracle mà không cần mật khẩu và thay đổi tập lệnh shell để bao gồm sudo;
-
tạo trình lắng nghe mới trên DB Home trên một cổng khác và thay đổi mục nhập TNSNAMES.ORA để trỏ đến cổng mới. Sau đó, extproc sẽ được thực thi với tư cách là tiên tri người dùng hệ điều hành. Bạn sẽ phải chỉnh sửa thủ công LISTENER.ORA trên $ OH và bắt đầu nó bằng lsnrctl, vì những người nghe đã đăng ký với srvctl sẽ luôn được bắt đầu bằng lưới;
-
thay đổi bộ nghe chính sang nhà db. Tôi không khuyến nghị điều đó (xem mục ở trên).
[EDIT] Như đã chỉ ra bởi @AlexPoole và @jonearles, có hai tùy chọn khác không phù hợp với trường hợp của tôi nhưng có thể dành cho những người khác:
- nếu bạn chạy tập lệnh cục bộ trên sqlplus, thiết lập ORACLE_SID, thì quyền truy cập FS sẽ được thực hiện bởi người dùng OS đang chạy sqlplus. Vì vậy, bạn có thể chạy với tư cách là nhà tiên tri hoặc một số người dùng khác và sửa các quyền FS;
- nếu bạn lên lịch công việc trên bộ lập lịch dbms_job dưới dạng SYS, công việc sẽ được oracle thực thi (hành vi này có thể phụ thuộc vào phiên bản, vì vậy cần phải kiểm tra thêm).
Trân trọng,
Daniel Stolf
