Re: weird issues with large# of jobs

Joel Garry wrote:
...
>
> For example, create a table, select a row for update.
>
> In another session, drop the table. You'll get an ora-00054.

Any such error would be reported in alert_log, unless it's properly 'trapped' in the exception part of the procedure (which it isn't).

> That's just one legitimate example of things that can go wrong (in this
> case, implying a user/app left something out there), more difficult to
> demonstrate things can happen with a non-scalable solution as you've
> described. That's not even getting into plain old bugs. If you could
> prove a jobs bug where info gets swapped, that would be real scary.

I didn't claim we had a perfect application, however it did work for years (at least 5) every day until recently.

I did demonstrate the the alert log had reported job failures for schemas these jobs actually didn't belong to.

I did claim that it was a bit odd that this started happenning after I upped the amount of job_queue_processes from the old 8i maximim of 36 maximum jobs to 54 (well, 52 run at 10pm).

A logical step would be to drop the # of jobs back to 36, but the application people don't want to do it since it 'breaks' application in other places.

We are looking into workarounds (e.g. flash back query, or opening 4 cursors on tables at 10pm) to reduce the # of jobs. Received on Mon Apr 17 2006 - 22:51:49 CDT