Scheduling OEM jobs

Printable View

08-31-2005, 03:25 PM
chikkodi

Scheduling OEM jobs

Currently in our place, all db jobs are scheduled through cron. We want to move them to a centralized OEM. There are 2 ways you can schedule a job through OEM.
1. Call a script remotely on the db server that does the job (eg analyze the schema) by running an os command
2. Perform the operation directly from OEM (select db as a target and select analyze as the operation)

Which is better?
I am thinking #1 because
1. We have control on what we are running
2. Wont be a burden on the OEM box (eg if 5 backup jobs kick off at the same time, which is highly likely as there are around 10-12 production databases)

What is your practical opinion on this?

Thanks!
09-01-2005, 09:19 AM
chikkodi

Could someone please guide me here? What is the best practice method in this case?
Thanks!
09-01-2005, 03:10 PM
chikkodi

Best practice for scheduling oem jobs

How do you guys do it?
09-01-2005, 03:15 PM
tamilselvan

Many Big shops do not use OEM.

CRON will do almost every thing.

Tamil
09-01-2005, 04:09 PM
chikkodi

Thanks for your reply, however, now I am confused.. Currently things work fine with cron at our place. Only problem we have is, we have to login to several boxes to check the logs of the various jobs that run each night and the output (stdout) is not spooled to logfiles so many times we wont know if things really ran or not.

I was thinking if we move to OEM, we will have one common place to view all the jobs and we will know (and get notified) at a glance if anything did not work. We can also setup events, alerts and stuff. Thats the reason we are undertaking this project of moving things over to OEM.

Is this a bad idea? Why should we not use OEM? Are there any practical, undocumented problems when we use it?
09-01-2005, 04:26 PM
tamilselvan

It is not bad idea to use OEM of current release. In fact, it is too good also.
The earlier releases got bad reputation among many DBAs.
That's why many of us (old guys?) did not use it at all.

CRON's age is 35. OEM's age is 10.

Just like RMAN.

Tamil
09-01-2005, 04:50 PM
chikkodi

Thank you. Now that we are back to scheduling jobs with oem, which methodology is better? Using scripts and running as an os command, or scheduling through inbuilt oem functions?
09-02-2005, 04:24 AM
bazza

Quote:

Originally Posted by chikkodi

Thank you. Now that we are back to scheduling jobs with oem, which methodology is better? Using scripts and running as an os command, or scheduling through inbuilt oem functions?

Which OEM are you talking about here? The 9i version or 10G Grid Control?

OEM can be a bit painful setting up (either version) so prepare for a little bit of a learning curve.

Bazza
09-02-2005, 08:27 AM
chikkodi

Since most of the dbs are 9i, we will use 9i OEM. We will be setting it up on a Windows box, with 500M RAM.
09-05-2005, 05:45 AM
bazza

Quote:

Originally Posted by chikkodi

Since most of the dbs are 9i, we will use 9i OEM. We will be setting it up on a Windows box, with 500M RAM.

Oracle's 10G Grid control will happily monitor both 8 and 9i databases, so please have a look into it.

10G:
The biggest problem with Grid and jobs, is there is no error reporting if a job fails. This is supposedly fixed in release 2 but you need error reporting then bear this in mind. You can still view the logfile, but if you need to be notified outside of normal

OEM9i:
The error reporting works in OEM9i. I would personally be inclined to store the scripts (if they are generic) etc in the job libraries on OEM, unless you have server specific scripts. Bear in mind when OEM runs a job, it will just get the agent to run the script on the target node, so either way, you won't have increased overhead on the OEM server.

Like I said just be prepared to give yourself time to get to grips with it, may be a little time to get everything working.