This content has been marked as final. Show 5 replies
Like all database objects, the database looks in the current schema for the object first. In this case there is no object called file_watcher_schedule in the current schema.
I think the object you are referring to is in the SYS schema so you would need to modify 'SYS.file_watcher_schedule' .
However, by default only SYS can modify objects in the SYS schema so you would probably need to be logged in as SYS to do this.
Hope this helps,
Hello Oracle Gurus,
Is anyone implemented Filewatcher in 11gR2 RAC environment? I'm not sure if there is any different but I have followed steps from Oralce-base article http://www.oracle-base.com/articles/11g/scheduler-enhancements-11gr2.php#file_watcher but nothing working. No errors in the logs. How do I check if Filewatcher running? I have set interval to run every minute, created couple of files, but scheduler job never ran, at least it doesn't show in scheduler job run details.
Thanks in advance.
See if you can run a simple external job (in the background) with the same credential you are using for the file watcher.
If that job throws any errors, fixing those might fix your file watcher problems.
The permissions are set incorrectly on the underlying OS file out of the box from Oracle. I opened tar for this recently and this was the fix:
- rdbms/admin/externaljob.ora file must must be owned by root:oraclegroup and be writable only by the owner i.e. 644 (rw-r--r--)
It must contain at least two lines: one specifying the run-user and one specifying the run-group. (not used with credentials)
- bin/extjob file must be also owned by root:oraclegroup but must be setuid i.e. 4750 (-rwsr-x---)
- bin/extjobo should have normal 755 (rwxr-xr-x) permissions and be owned by oracle:oraclegroup
- bin/jssu should exist with root setuid
permissions i.e. owned by root:oraclegroup with 4750 (-rwsr-x---)
Had to drop and recreate all the scheduler objects afterward.
These permissions are set during installation when the "root.sh" script is run as the root user.
If the root.sh script is never run as the root user then the permissions will be set incorrectly.
Rerunning the root.sh script at anytime as the root user will reset the permissions correctly.