Converting Crontab to Enterprise Manager Jobs

A customer recently asked me about whether they can convert numerous cron jobs to EM’s Job System. It reminded me that a former manager of mine had posted an article on just how to do this conversion. That manager has since left Oracle, and since his posting was on his own website, I wanted to make sure the intellectual capital wasn’t lost to us if he decided to remove it. The article was written in March 2015, so the screenshots were all taken with EM12c as that was the version available at the time. Obviously, the user interface has changed in EM13c, but the basic functionality remains the same. In the post below, I’ve updated the material to EM13c, but if you want to see the original EM12c post it’s still (as of August 2016) available here.

Surprisingly, a popular question posted on our internal forum is about the possibility of using the Enterprise Manager (EM) Job System to replace customer’s numerous cron jobs. The answer is obviously YES! I say surprisingly because the EM Job system has been in existence for around 10 years (I believe since EM 10.2.0.1), and my hope was that, by now, customers would have moved to using more enterprise class job schedulers instead of cron. So, here is a quick post on how to get started with this conversion from cron to EM Jobs for some of our new users.

Benefits of EM Job System

Before we learn about the how, let’s look at the why. The EM job system is:

  • Free – (Yes, I said free) It is included with the base EM at no cost.
  • Flexible – It supports multiple options for scheduling, notification, authentication, etc.
  • Infinitely scalable – the job system seamlessly scales to every new Oracle Management Server (OMS). In fact, in case of OMS failures, the job steps are automatically picked up by the next available OMS without affecting the job execution.
  • General purpose – General purpose since it provides numerous out-of-the-box job types like run OS command, start/stop, backup, SQL Script, patch, etc. that span multiple target types. As of today, there are over 50 job types available in the product.
  • Enterprise grade – It allows users to automate multiple administrative tasks like backup, patching, cloning, etc across multiple targets. Customers have not only converted their cron jobs to EM, but have also replaced other enterprise tools like Autosys and migrated 1000s of jobs to EM Job System.
  • APIs – Jobs can be scheduled and managed from the UI and using EMCLI (the command line interface).

Now back to our topic.

The Conversion Process

Let’s start with a sample crontab that we want to convert.

crontab

A cron expression consists of 6 fields, where the first 5 fields represent the schedule, while the last field represents the command or script to run.

Field NameMandatory?Allowed ValuesAllowed Special Characters
MinutesYes0-59 * / , –
HoursYes0-23 * / , –
Day of monthYes1-31* / , – ? L W
MonthYes1-12 or JAN-DEC * / , –
Day of weekYes0-6 or SUN-SAT* / , – ? L #

Cron jobs run on the operating system, often using the native shell or other tools installed on the operating system. The equivalent of this capability in Enterprise Manager is the ‘OS Command’ job type. Here are the steps required to convert the first entry in the crontab to an EM job:

1. Navigate to the Job Activity page:

Crontab1

2. Click on “Create Job”:

Crontab2

3. Scroll down and select “OS Command” from the pop-up window then click “Select”:

Crontab3

A 5-tab wizard will appear. Let’s step through these one by one.

4. Select the first tab called ‘General’. Here provide a meaningful name and description for the job. Since this job will be run on the Host target, keep the target type selection as ‘Host’. Next, select all host targets in EM that you wish to run this script against.

While cron jobs are defined on a per host basis, in EM a job definition can be run and managed across multiple hosts or groups of hosts. This avoids having to maintain the same crontab across multiple hosts.

Crontab4

5. Select the ‘Parameters’ tab. Here enter the command or script as specified in the last field of the crontab entry. When constructing the command, you can make use of the various target properties.

Crontab5

6. Next select ‘Credentials’. Here we provide the credentials required to connect to the host and execute the required commands or scripts. Three options are presented to the user:

  • Preferred – default credential set for the host.
  • Named – Credentials are stored within Enterprise Manager as “named” entities. Named credentials can be a username/password, or a public key-private key pair. Here we choose pre-created named credentials.
  • New – This allows us to create and use a new named credential.

Note: If your OS user does not have the required privileges to execute the set command, Named Credentials also support use of sudo, powerbroker, sesu, etc.

Crontab6

7. Next, we set the Schedule and this is where it gets interesting. As discussed before, crontab uses a textual representation for the schedule, while the EM Job system has a graphical representation for the schedule.

Our sample schedule in the crontab is ‘00 0 * * Sun’. This translates to a weekly job at 12 midnight on every Sunday. To set this in EM, choose the ‘Repeating’ schedule type. The screenshot below shows all the other selections.

Crontab7

The key here is to select the correct ‘Type’, the rest of the selections are quite obvious. This also lets you choose the desired timezone for the schedule. Your options are to either start the job w.r.t a fixed timezone, or start it in individual target’s timezone. The latter is very popular, for example, I want to start a job at 2 AM local time in every region around the world.

Another selection of note is that for ‘Grace Period’. This is an extremely powerful feature, but often not used by many customers. Typically, we expect jobs to be started within a few seconds or minutes (based on the load on the system and number of jobs scheduled) of the start time, but a job might not start on time for many reasons. The most common reasons are the Agent being down or due to a blackout. The grace period controls the latest start time for the job in case the job is delayed, else its is marked as skipped. By default, jobs are scheduled with indefinite grace periods, but I highly recommend setting a value for it. For example, I can set a 3 hr limit which may seem large but given the weekly nature of the job seems reasonable. So the job system will wait until 3 am (the job start time is 12 am) to start the job, after which the iteration will be skipped. For repeating schedules, the grace period should always be less than the repeat interval. If the job starts on time, the grace period is ignored.

8. Finally, we navigate to the ‘Access’ tab. This tab has two parts:

  • Privilege assignment to roles and users: this allows you to control job level access for other users
  • Email notifications for the Job owner: this allows you to control the events for which you wish to receive notifications. Note, this only sets notification for the job owner, the other users can subscribe to emails by setting up notification and/or incident rules.

To prevent EM from sending a deluge of emails, I recommend the following settings in the notifications region:

  • Match status and severity: Both
  • Select severity of status: Critical
  • Select status: Problems & Action Required

You can always come back and modify these settings to suit your needs.

Crontab8

Not all cron jobs need to be converted to OS commands. For example, if you are taking Oracle database backups using cron, then you probably want to use the out-of-the-box job type for RMAN scripts. Just provide the RMAN script, list of databases to run this against, and the credentials required to connect to the database. Similarly, if you run sqls on numerous databases, you can leverage the SQL Script job type for this purpose. There are over 50 job types available in EM13c, all available for use from the UI and EMCLI.

Finally, the best way to learn more about the EM Job System is to actually play with it. Good luck!!

Pete

After 22 years of working at Oracle in just about every role except Marketing and Support, I am now working as a Senior Managed Services Consultant with Red Stack Tech, specializing in Oracle Database technology, High Availability and Disaster Recovery solutions.

I am also a member of the OakTable Network, and have presented at RMOUG Training Days, Hotsos Symposia, Oracle OpenWorld conferences, and other user group events. I have co-authored the Expert Oracle Enterprise Manager 12c and Practical Oracle Database Appliance books published by Apress, and am one of the authors of the Building Database Clouds in Oracle Database 12c book published by Addison Wesley.

One Comment:

  1. Pete,
    I can’t reply to your post about converting Crontab to Enterprise Manager Jobs https://petewhodidnottweet.com/2016/08/converting-crontab-enterprise-manager-jobs/ as I don’t see how to, so I decided to reply here. Sorry for a long post but I have faced the same issue recently and have some arguments about the subject.

    Could you tell me please how many Enterprise Manager (EM) jobs you have created for the single cron job from your example:
    #Run a script at 8:45pm (20:45) on 2nd and the 16th only in the months of January and April.
    45 20 2,16 1,4 * /tools/a_script.sh

    As far as I know, to replicate a schedule alike we have to create several jobs in EM because the current UI allows us to create fixed-interval schedules, i.e. weekly, dayly and so on.
    There is a known Enhancement Request about this: Bug 14511940 : SCHEDULE A JOB LIKE A CRON JOB

    https://support.oracle.com/CSP/main/article?cmd=show&type=BUG&&productFamily=Oracle&id=14511940

    Regarding the initial task about converting Crontab to Enterprise Manager Jobs, I found it’s more convenient to use EMCLI for this task as it’s fast, it can be automated (no need to surfing through the EM Web Interface), and all I have to do is to specify appropriate parameter in a property file: a job owner, a target and a schedule in a simple case.
    And the command line to create a job may be as follows:
    emcli create_job -input_file=property_file:/path_to_property_file
    where the property_file contains a job description like in the below example:

    # Current status of the job is ACTIVE.
    name=TEST_JOB1
    type=OSCommand
    description=Test Job
    owner=SYSMAN

    target_list=emcc.example.com:host
    #Number of targets : 1

    # Credential Usage: defaultHostCred
    # Description:
    cred.defaultHostCred.:host=NAMED:SYSMAN:NC_HOST_ORACLE

    # Description: (Optional) The complete command line, including parameters.
    variable.default_shell_command=/home/oracle/oem_test_scripts/test1.sh

    schedule.frequency=REPEAT_BY_MINUTES
    schedule.startTime=2016-08-30 03:16:00
    schedule.endTime=2016-09-28 10:00:00
    schedule.interval=15
    schedule.timezone.region=America/New_York

    Yours faithfully,
    Mikhail Velikikh.

    • Mikhail

      Firstly, thanks for pointing out the comments were disabled problem. I’d mis-set a configuration setting. I’ve moved the comment to the approproate post (I hope!)

      Secondly, the example you asked about (last entry in the crontab) was not one I’d included in the post, it was just another entry in the crontab. As you rightly point out, it will need multiple jobs to handle that specific entry. The bug you referred to is one we are looking at for the 13.3 release (the next one to be coded as of the date I’m replying), but as it will need a reasonably complex change to the scheduling function as it currently exists, I can’t guarantee it will actually be accepted for that release.

      Thirdly, I agree with you that emcli is the way to go with these things, as it is in many cases. Quite often we find that people use the GUI as a way of familiarizing themselves with the product capability, and then move on to scripting commands with emcli when they are both more familiar with it and need to perform multiple commands in one operation.

      Thanks for your comments!

      Pete

Comments are closed