Re: dbms_scheduler.create_file_watcher

"Mladen Gogala" <gogala.mladen_at_gmail.com> wrote in message
news:pan.2012.10.18.02.59.01_at_gmail.com...
| On Wed, 17 Oct 2012 20:07:50 +0100, Adrian wrote:|| > 11.2 Linux| >| > I'm looking at using this to identify when I've got new files to load.| > At first glance it looks ideal, but on digging into the docs, it seems| > that I need to set up a credential, which is where I hit problems.| >| > The plan is that the files will be put in a directory owned by a user| > that we would be accessing using sudo rather than by logging in, so we| > won't know what the password is. No password, no credential, no| > credential, no file watcher appears to be the situation, or is there a| > (legitimate) way around it that I've missed ?.| >| >| > TIA| >| > Adrian|| Don't use RDBMS for the things better solved by the operating system.| Check out inotifywait and inotifywatch utilities. If you want to script| it, there is a Perl module called Linux::Inotify. Inotify is a kernel| module, available since the kernel 2.6.13, which means that RH 5.0 and| compatible or newer versions have it. RH 5.0 has kernel 2.6.18. Very good| article about Inotify is here:|

I would guess that the OP has a system where he wants an Oracle job to pick
up a data file and load it into the database as soon as it appears - that's
what the file-watcher is basically for. If he uses inotify to watch for the
file he still needs to do something to load that file into the database -
which means Oracle still needs to be able to read the file (do you want
inotify to copy it somewhere else where the file watcher can watch for it)
unless he now has a looping program running externally to the database that
has to be stopped and started as the database is stopped and started etc.
etc. etc.

I don't have an answer to the original question since I haven't looked
closely at file watcher - but I'm always reluctant to add an external
component to a task that looks as if it could (or should) be handled and
synchronised internally. That's why I learned to rethink some cron jobs as
dbms_job and then dbms_scheduler became available - fewer dependencies.