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.
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:
http://www.ibm.com/developerworks/linux/library/l-ubuntu-inotify/inde...
"Mladen Gogala" <gogala.mla...@gmail.com> wrote in message
news:pan.2012.10.18.02.59.01@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:
| http://www.ibm.com/developerworks/linux/library/l-ubuntu-inotify/inde... |
|
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.
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 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.
In message <MFsoS$JGIwfQF...@ku.gro.lloiff>, Adrian <bull...@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.
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
-- 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.
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 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.
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.
>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
>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.
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).
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.
# 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!
On Friday, October 19, 2012 12:07:12 PM UTC-6, John Hurley wrote:
> 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!
Dinosaur I'll *possibly* accept, *old* I will not.
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).
