Re: best practices re: scheduled jobs

"Paul Brewer" <paul_at_paul.brewers.org.uk> wrote in message news:<3eb94ac5_1_at_mk-nntp-1.news.uk.worldonline.com>...
> "Ed Stevens" <nospam_at_noway.nohow> wrote in message
> news:vl2gbvga8fmmt1r4i01m3rp1lolej418je_at_4ax.com...
> > Trying to stretch my wings a bit here, playing around with the job
> > scheudling system and with compiled procedures. Looking for some
> > 'best practices' advice.
> >
> > I've built some rather simple procedures to take care of some dba
> > chores like refreshing stats for the optimizer and collecting stats
> > into a 'stats_history' table for trend analysis, and I have these
> > running under the dbms_jobs system on a test database. In getting to
> > this point, I worked thru the problem of procedures not having user
> > privs that are inherited via a role. I'm also finding it a bit
> > difficult to keep up with scheduled jobs running under various
> > user-ids. As a result, I'm wondering if I wouldn't be better off just
> > setting up the 'procedures' as sql files and feed them into SQL-Plus
> > from a cron job. What problems would I be trading for if I went this
> > direction? Are there any generally accepted practices or is it really
> > pretty much all over the map?
>
> My 2c:
> If it's gathering stats, housekeeping or any such job *within* the database,
> then IMHO it should be a database job.
> If it's an OS job: sqlldr, exp or the like; then it should be cronned.

I agree, although I have a big bias towards keeping things on the server, and tend to do everything in cron just because I'm a unix bigot. What I've seen happening, though, is DBA's will do things on their PC's, like generally set up a little database for OEM and such, and then become very PC centric and become over-dependent on db jobs and pretty tools. I'm not sure if that is just the way of the world (with Oracle pushing their own software, understandably), or if it is bad thing. It seems bad to me, since my view of the platform independence is it is driven more by the limitations of MS software than by grabbing the good parts of unix. It is just so much more warm and fuzzy editing a text file and knowing it will work predictably than pushing commands at some software that might be recalcitrant and mislead about whether it is working.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/computing/personaltech/20030505-9999_mz1b5passwor.html