views:

25

answers:

2

I use PHP and Oracle, with crontab executing the PHP scripts at scheduled times. My current logging/auditing solution involves simple log files. I'd like to save my cron execution logs to a database instead.

Right now I'm trying to design the process so that when a cron job starts I create a record in an CronExecution table. Then every time I want to log something for that cron I'll put a record in a CronEvent table which will have a foreign key to the CronExecution table.

I plan to log all events using a PRAGMA AUTONOMOUS pl/sql procedure. With this procedure I will be able to log events inside of other pl/sql procedures and also from my PHP code in a consistent manner.

To make it more robust, my plan is to have a fallback to log errors to a file in the event that the database log calls fail.

Has anybody else written something similar? What suggestions do you have based on your experience?

+1  A: 

Yep, I've done this several times.

The CronExecution table is a good idea. However, I don't know that you really need to create the CronEvent table. Instead, just give yourself a "status" column and update that column.

You'll find that makes failing over to file much easier. As you build lots of these CronExecutions, you'll probably have less interest in CronEvents and more interest in the full status of the execution.

Wrap all of the update calls in stored procedures. You definitely have that correct.

Including a 'schedule' in your CronExecution will prove handy. It's very easy to have a lot of cron jobs and not be able to connect the dots on "how long did this take?" and "when is this supposed to run". Including a "next scheduled run" on completion of a job will make your life much easier.

Gates VP
@Gates VP: So are you suggesting I have a CLOB column that I append each message to as I work my way through the job? And then at the end set the status to complete or something, at which point I could retrieve the entire execution log from that CLOB?You read my mind about having some kind of scheduling properties in the database as well. I've used Quartz for Java and I liked that, but am not sure how much functionality I can take over from crontab as I'm using PHP. But adding informational fields with the start/stop/next run details is a good idea. Thanks!
RenderIn
CLOB, VARCHAR(MAX), whatever's in your DB. In my experience, I rarely needed anything at the `CronEvent` level. Just print the time at the beginning of each log message and you should be fine. Now you don't need the configuration in the DB, but when you start writing code to watch the "CronLog", the biggest question you'll want to know is "when did X last run, how long did it take, when will it run again"
Gates VP
A: 

You will want to read the documentation on DBMS_SCHEDULER. It's a little bit of work to implement (what isn't?), but it will allow you to control scheduled and one-time jobs from within the database. That includes OS-level jobs.

Bernard