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.
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 Name||Mandatory?||Allowed Values||Allowed Special Characters|
|Minutes||Yes||0-59||* / , –|
|Hours||Yes||0-23||* / , –|
|Day of month||Yes||1-31||* / , – ? L W|
|Month||Yes||1-12 or JAN-DEC||* / , –|
|Day of week||Yes||0-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:
2. Click on “Create Job”:
3. Scroll down and select “OS Command” from the pop-up window then click “Select”:
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.
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.
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.
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.
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.
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!!