Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
dbms_scheduler.create_file_watcher
111 views
Skip to first unread message
Adrian
Oct 17, 2012, 3:07:50 PM10/17/12
to
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
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
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
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.
Mladen Gogala
Oct 17, 2012, 10:59:02 PM10/17/12
to
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.
> 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
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:
http://www.ibm.com/developerworks/linux/library/l-ubuntu-inotify/index.html
--
Mladen Gogala
http://mgogala.freehostia.com
Jonathan Lewis
Oct 18, 2012, 3:47:01 AM10/18/12
to
"Mladen Gogala" <gogala...@gmail.com> wrote in message
news:pan.2012.10...@gmail.com...
Mladen,
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.
--
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com/all_postings
Author: Oracle Core (Apress 2011)
http://www.apress.com/9781430239543
news:pan.2012.10...@gmail.com...
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.
--
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com/all_postings
Author: Oracle Core (Apress 2011)
http://www.apress.com/9781430239543
Mladen Gogala
Oct 18, 2012, 10:11:06 AM10/18/12
to
On Thu, 18 Oct 2012 08:47:01 +0100, Jonathan Lewis wrote:
> 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.
Jonathan, I agree with you for the most part. I also am using
> 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.
DBMS_SCHEDULER wherever it makes sense. However, in this particular case,
I would write a Perl script which would wait for the files to appear and
then insert them into Oracle. That seems like the simplest solution as it
deals with the OS object: it monitors directory.
Change of ownership and permissions cans easily be handled from a Perl
script.
Adrian
Oct 18, 2012, 2:58:49 PM10/18/12
to
In message <MFsoS$JGIwf...@ku.gro.lloiff>, Adrian
<bul...@ku.gro.lioff> writes
Jonathan is right in his assumption, I would like to be able to load
files as soon as I spot that they have arrived, whilst this could be
done using cron and a script of some form. Whilst I have nothing
against doing things at OS level, there seems some logic in allowing the
DB to do it if possible.
<bul...@ku.gro.lioff> writes
>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 ?.
>
Thanks to Mladen and Jonathan for the replies.
>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 ?.
>
Jonathan is right in his assumption, I would like to be able to load
files as soon as I spot that they have arrived, whilst this could be
done using cron and a script of some form. Whilst I have nothing
against doing things at OS level, there seems some logic in allowing the
DB to do it if possible.
Mladen Gogala
Oct 18, 2012, 8:13:34 PM10/18/12
to
On Thu, 18 Oct 2012 19:58:49 +0100, Adrian wrote:
> Jonathan is right in his assumption, I would like to be able to load
> files as soon as I spot that they have arrived, whilst this could be
> done using cron and a script of some form. Whilst I have nothing
> against doing things at OS level, there seems some logic in allowing the
> DB to do it if possible.
Adrian, as far as I know, there is nothing like that in the database. If
> Jonathan is right in his assumption, I would like to be able to load
> files as soon as I spot that they have arrived, whilst this could be
> done using cron and a script of some form. Whilst I have nothing
> against doing things at OS level, there seems some logic in allowing the
> DB to do it if possible.
you come to think of it, databases are unlikely to have things like that
because monitoring file needs kernel call to monitor inode, which is
precisely what Inotify is. I doubt that there is an elegant way of doing it
in the database.
joel garry
Oct 19, 2012, 11:47:54 AM10/19/12
to
On Oct 18, 12:46 am, "Jonathan Lewis" <jonat...@jlcomp.demon.co.uk>
wrote:
>
> 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.
>
I've had more fails using dbconsole to schedule backups than I ever
did with custom scripts in cron. More dependencies on stupid wheel-
reinvention (TZ bugs!), more parts to break (cert expiration every 6
months!), easier to pick wrong settings.
There's something to be said for the complexity of the solution being
congruent with that of the problem.
jg
--
@home.com is bogus.
http://www.11alive.com/news/article/261138/166/Google-stock-plummets-after-early-earnings-release
wrote:
>
> 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.
>
did with custom scripts in cron. More dependencies on stupid wheel-
reinvention (TZ bugs!), more parts to break (cert expiration every 6
months!), easier to pick wrong settings.
There's something to be said for the complexity of the solution being
congruent with that of the problem.
jg
--
@home.com is bogus.
http://www.11alive.com/news/article/261138/166/Google-stock-plummets-after-early-earnings-release
Adrian
Oct 19, 2012, 12:03:18 PM10/19/12
to
In message <pan.2012.10...@gmail.com>, Mladen Gogala
<gogala...@gmail.com> writes
Thanks for the follow up, the file watcher, and a corresponding routine
(I think the documentation shows a good starting point) looked ideal,
but if we need to provide a password (not unreasonable), then we could
be sunk. It is looking like plan B (a cron job).
<gogala...@gmail.com> writes
(I think the documentation shows a good starting point) looked ideal,
but if we need to provide a password (not unreasonable), then we could
be sunk. It is looking like plan B (a cron job).
John Hurley
Oct 19, 2012, 2:07:11 PM10/19/12
to
Joel:
# I've had more fails using dbconsole to schedule backups than I ever
did with custom scripts in cron. More dependencies on ...
We do not USE ... jobs or scheduling from within the database ...
So many potential problems hard to know where to start.
If you want a job that runs a backup of the database ... lets see ...
run it from cron and it can check to see if the database is up and
operating if not email/alert ... it can run the backup and check the
output ( custom scripting required ) and email/alert the backup
status ...
If you run it from the database side and the database is not up ...
thats not going to work so well is it?
Old dinosaurs prefer something reliable and proven and consistent!
# I've had more fails using dbconsole to schedule backups than I ever
did with custom scripts in cron. More dependencies on ...
We do not USE ... jobs or scheduling from within the database ...
So many potential problems hard to know where to start.
If you want a job that runs a backup of the database ... lets see ...
run it from cron and it can check to see if the database is up and
operating if not email/alert ... it can run the backup and check the
output ( custom scripting required ) and email/alert the backup
status ...
If you run it from the database side and the database is not up ...
thats not going to work so well is it?
Old dinosaurs prefer something reliable and proven and consistent!
ddf
Oct 19, 2012, 3:48:45 PM10/19/12
to
That being said we do no job scheduling through the database for backups, tablespace checks, etc. Yes, OEM can do those and, by default, we have those running but the thresholds are so ... limiting. We augment that information with regularly scheduled jobs through cron which we find much more reliable and informative if only because we can better control the schedule, can check more pieces of the puzzle and report any issues, including, as John mentioned, the dreaded 'database down', and can set meaningful thresholds depending on the file system, tablespace and database.
The Oracle database is a wonderful thing, truly it is. However, I'd rather let the O/S do what it does best, cron what it does best and leave the database to do what IT does best.
My two cents (which is now about 4.237 cents due to inflation).
David Fitzjarrell
0 new messages