Automating RMAN backup Jobs with CRON utility

Automating RMAN backup Jobs with CRON utility

DBAs often debate whether they should use Oracle Scheduler or the Linux/Unix cron utility for scheduling and automating tasks. There are many benefits that Oracle Scheduler  has over cron, but yet despite these benefits, many DBAs prefer to use a scheduling utility such as cron to automate many tasks. There are some advantages of cron:-

• Easy to use, simple, tried and true, only takes seconds to create or modify jobs.
• Almost universally available on all Linux/Unix boxes; for the most part, runs nearly identically, regardless of the Linux/Unix platform (yep!, there are minor differences)
• Database agnostic; operates independently of the database and works the same, regardless of the database vendor or version.
• Works whether or not the database is available.

When your Linux server boots up, a cron background process is automatically started to manage all the cron jobs in the  system.

On your Linux box, you can check  to see whether the cron daemon is running, using the service command:

Enabling Access to cron

Sometimes when System Admins set up a new Linux box, they don't (by default) enable the use of cron for all users on the system. So to verify  whether you have  access to cron, invoke  the utility as follows:

      $ crontab -e

If you receive the following error massage, then you do not have access:

       You (oracle) are not allowed to use this program (crontab)

If you received this error then you can enable cron access as root user or ask your SA to enable it for you.

# echo oracle >> /etc/cron.allow

Once the oracle entry is added to the /etc/cron.allow file, you can use the crontab utility to schedule a job.

Next you need a backup script, you can download a backup script using the link below or write your own rman backup script. 

rman backup script

Once you have your script ready the next thing is to understand cron table enteries

Understanding cron Table Entries

Your cron  table is a list of numbers and commands that cron background  process will run at specified time and schedule. The crontab utility expects entries to follow a well-defined format. It's a good practice to add a comment line at the beginning of your crontab file that documents the required format, like :-

# min(0-59) hr(0-23) dayMonth(1-31) monthYear(1-12) dayWeek(0/7-6) commandOrScript

The number sign (#) in the cron file represents the start of a comment. Any text entered after # is ignored by cron.

Scheduling a Job to Run Automatically

To schedule a job, you must add a line in your cron table, specifying  the time you want  the job to execute.

You can edit you cron table directly with the -e (editor) option of the crontab command:

$ crontab -e

When issuing the previous command, you will be presented with a file to edit. This file is known as your cron table (crontab).

To schedule a script name rman_backup.sh to run daily, at 11:50 pm enter the line into your cron table:

# min(0-59) hr(0-23) dayMonth(1-31) monthYear(1-12) dayWeek(0/7-6) commandOrScript

 50   23    *    *    *     /home/oracle/bin/rman_backup.sh  1>/home/oracle/bin/log/bck.log 2>&1

Exit the cron table file. If your default editor is vi, then type wq to exit. When you exit crontab, your cron table is saved for you. To view your cron entries, use the -l (list) option of the crontab command:

$ crontab -l

To remove your cron table completely, use the r option:

$ crontab -r

NB!! Before running the previous command, you should save your cron table in a text file, as shown:

$ crontab -l > saved.cron

In this way, you can refer to the saved file, in the event that you didn’t mean to delete your cron table.

The cron job above use redirection features to send the output of a shell script to a log file.

In the cron table entry, any standard output and error messages generated by the rman_backup.sh shell script are captured in a file named bck.log

If you don’t redirect the cron job output, then any output will be e-mailed to the user that owns the cron table. You can override this behavior by specifying the MAILTO variable directly within the cron table.