Scheduling OEM jobs
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 10 of 10

Thread: Scheduling OEM jobs

  1. #1
    Join Date
    Jan 2001
    Posts
    216

    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!

  2. #2
    Join Date
    Jan 2001
    Posts
    216
    Could someone please guide me here? What is the best practice method in this case?
    Thanks!

  3. #3
    Join Date
    Jan 2001
    Posts
    216

    Best practice for scheduling oem jobs

    How do you guys do it?

  4. #4
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135
    Many Big shops do not use OEM.

    CRON will do almost every thing.

    Tamil

  5. #5
    Join Date
    Jan 2001
    Posts
    216
    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?

  6. #6
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135
    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
    Last edited by tamilselvan; 09-01-2005 at 04:28 PM.

  7. #7
    Join Date
    Jan 2001
    Posts
    216
    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?

  8. #8
    Join Date
    Jul 2002
    Posts
    335
    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

  9. #9
    Join Date
    Jan 2001
    Posts
    216
    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.

  10. #10
    Join Date
    Jul 2002
    Posts
    335
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width