Re: best practices re: scheduled jobs

"Joel Garry" <joel-garry_at_home.com> wrote in message news:91884734.0305071625.7e6256ca_at_posting.google.com...
> "Paul Brewer" <paul_at_paul.brewers.org.uk> wrote in message
news:<3eb94ac5_1_at_mk-nntp-1.news.uk.worldonline.com>...
> > 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

Joel,

I wasn't envisaging that kind of scenario. I was thinking about running database jobs on the 'real' database; i.e. the database on the server, as opposed to running cron jobs on the *same* server - whatever Os the server runs (and our servers run HPUX for the main part, btw.)

I certainly don't like the idea of DBAs creating 'little' databases on their own 'client' PCs for admin purposes; IMHO that leads to anarchy if we're not careful.

However, considering OEM in particular, I'm not against having a a 'proper' shared OEM repository.

Regards,
Paul Received on Thu May 08 2003 - 14:56:48 CDT