Re: dbms_scheduler.create_file_watcher
Date: Fri, 19 Oct 2012 12:48:45 -0700 (PDT)
Message-ID: <e0a07976-2b43-49c1-9059-2651313946eb_at_googlegroups.com>
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).
David Fitzjarrell Received on Fri Oct 19 2012 - 21:48:45 CEST