CHAPTER 21Automating Jobs

Introduction to Automating Jobs• DBAs rely heavily on automating jobs.• DBAs cannot be effective without automation.• Listed next are a sample of tasks DBAs typically

automate:• Shutdown and startup of databases and listeners• Backups• Validating the integrity of backups• Checking for errors• Removing old trace or log files• Checking for errant processes• Checking for abnormal conditions

Utilities to Automate• Oracle Scheduler• The Linux/Unix cron utility• Others?

Creating and Scheduling a Job Using Oracle Scheduler• Use the CREATE_JOB procedure of the DBMS_SCHEDULER package to

create a job. Run the following as SYS (from the SQL*Plus):•  

BEGIN

DBMS_SCHEDULER.CREATE_JOB(

job_name => 'RMAN_BACKUP',

job_type => 'EXECUTABLE',

job_action => '/orahome/oracle/bin/rmanback.bsh',

repeat_interval => 'FREQ=DAILY;BYHOUR=14;BYMINUTE=11',

start_date => to_date('21-OCT-10'),

job_class => '"DEFAULT_JOB_CLASS"',

auto_drop => FALSE,

comments => 'RMAN backup job',

enabled => TRUE);

END;

/

Viewing Job Details• To view details about how a job is configured query the

DBA_SCHEDULER_JOBS view.• This example selects information for the RMAN_BACKUP job:•  

SELECT

job_name

,last_start_date

,last_run_duration

,next_run_date

,repeat_interval

FROM dba_scheduler_jobs

WHERE job_name='RMAN_BACKUP';

Modifying Job Logging History• By default Oracle Scheduler keeps 30 days worth of log

history. You can modify the default retention period via the SET_SCHEDULER_ATTRIBUTE procedure.

• For example, this changes the default number of days to 15:•  

SQL> exec dbms_scheduler.set_scheduler_attribute('log_history',15);•  • To completely remove the contents of the log history, use the

PURGE_LOG procedure:•  

SQL> exec dbms_scheduler.purge_log();

Modifying a Job• You can modify various attributes of a job via the

SET_ATTRIBUTE procedure.• This example modifies the RMAN_BACKUP job to run

weekly on Monday:•  

BEGIN

dbms_scheduler.set_attribute(

name=>'RMAN_BACKUP'

,attribute=>'repeat_interval'

,value=>'freq=weekly; byday=mon'); 

END;

/

Stopping a Job• If you have a job that has been running for an abnormally

long time, you may want to abort it.• Use the STOP_JOB procedure to stop a currently running

job.• This example stops the RMAN_BACKUP job while it is

running:•  

SQL> exec dbms_scheduler.stop_job(job_name=>'RMAN_BACKUP');

Disabling a Job• You may want to temporarily disable a job because it's not

running correctly or you may want to stop a job while performing an upgrade or maintenance activity and so on.

• Use the DISABLE procedure to disable a job:

SQL> exec dbms_scheduler.disable('RMAN_BACKUP');

Enabling a Job• You can enable a previously disabled job via the ENABLE

procedure of the DBMS_SCHEDULER package.• This example re-enables the RMAN_BACKUP job:

 

SQL> exec dbms_scheduler.enable(name=>'RMAN_BACKUP');

Copying a Job• If you have a current job that you want to clone, you can use

the COPY_JOB procedure to accomplish this.• This procedure takes two arguments: the old job name and

the new job name.• Here's an example of copying a job where RMAN_BACKUP

is a previously created job and RMAN_NEW_BACK is the new job that will be created:

•  

begin dbms_scheduler.copy_job('RMAN_BACKUP','RMAN_NEW_BACK');

end;

/

Running a Job Manually• You can manually run a job outside of its regular schedule. You

might want to do this to test the job to ensure that it's working correctly.

• Use the RUN_JOB procedure to manually initiate a job.• This example manually runs the previously created

RMAN_BACKUP job:•  

BEGIN

DBMS_SCHEDULER.RUN_JOB(

JOB_NAME => 'RMAN_BACKUP',

USE_CURRENT_SESSION => FALSE);

END;

/•  

Deleting  a Job• If you no longer require a job, you should delete it from

the scheduler.• Use the DROP_JOB procedure to permanently remove a

job.• This example removes the RMAN_BACKUP job:•  

BEGIN

dbms_scheduler.drop_job(job_name=>'RMAN_BACKUP');

END;

/

Oracle Scheduler Advantages over cron

• Can make the execution of a job dependent on the completion of another job

• Robust resource balancing and flexible scheduling features• Can run jobs based on a database event• The Oracle Scheduler DBMS_SCHEDULER PL/SQL

package syntax works the same regardless of the operating system

• Can run status reports using the data dictionary• If working in clustered environment, no need to worry about

synchronizing multiple cron tables for each node in the cluster

• Can be maintained and monitored via Enterprise Manager

cron Advantages over Scheduler• Easy to use, simple, tried and true; only takes seconds to

create and/or modify jobs• Almost universally available on all Linux/Unix boxes; for

the most part, runs nearly identically regardless of the Linux/Unix platform (yes, there are minor differences)

• Database agnostic; operates independently of the database and works the same regardless of the database vendor or database version

• Works whether the database is available or not

How cron Works• When your Linux/Unix server boots up, a cron background

process is automatically started that manages all cron jobs on the system.

• The cron background process is also known as the cron daemon.

• This process is started on system startup by the /etc/init.d/crond script.

• You can check to see whether the cron daemon process is running with the ps command:

•  • $ ps -ef | grep crond | grep -v grep• root 3049 1 0 Aug02 ? 00:00:00 crond

Enabling Access to cron• To verify whether you have access to access cron type in the

following:

 

$ crontab -e

 • If you receive the following error message, then you do not

have access:

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

• To enable cron access, as the root user, add oracle to the /etc/cron.allow file with the echo command:

 

# echo oracle >> /etc/cron.allow

Understanding cron Table Entries• Your cron table is a list of numbers and commands that

the cron background process (cron daemon) will run at a specified time and schedule.

• The crontab utility expects entries to follow a well-defined format.

• You can add a comment line at the beginning of your crontab file that documents the required format:

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

0,30 8-16 * * 1-5 echo "wake up" | mailx -s "wake up" larry@oracle.com

Editing the cron Table Directly• You can edit your cron table directly with the -e (editor)

option of the crontab command:•  

$ crontab -e

Loading the cron Table from a File• The other way to modify your cron table is to load it

directly with a file name using the following syntax:•  

$ crontab <filename>

Redirecting cron Output• Whenever you run a Linux shell command by default the

standard output (of the command) will be displayed on your screen.

• Also if any error messages are generated they will by default be displayed on your terminal.

• You can use either > or 1> (they are synonymous) to redirect any standard output to an operating system file.

• Additionally you can use 2> redirect any error messages to a file.

• The notation of 2>&1 instructs the shell to send any error messages to the same location as standard output.

Troubleshooting cron1. Copy your cron entry, paste it to the operating system command line,

and manually run the command. Often a slight typo in a directory or file name can be the source of the problem.

2. If the script runs Oracle utilities, ensure that you source (set) the required operating system variables within the script such as ORACLE_HOME and ORACLE_SID. Oftentimes these variables are set by startup scripts (like HOME/.bashrc) when you log on. Since cron doesn’t run a user’s startup scripts, any required variables must be set explicitly within the script.

3. Ensure that the first line of any shell scripts invoked from cron specifies the name of the program that will be used to interpret the commands within the script. For example, #!/bin/bash should be the first entry in a Bash shell script. Since cron doesn’t run a user’s startup scripts (like HOME/.bashrc), you can’t assume that your operating system user’s default shell will be used to run a command or script evoked from cron.

4. Ensure that the cron background process is running.

Examples of Automated DBA Jobs• Starting and Stopping Database and Listener • Checking for Archive Redo Destination Fullness• Truncating Large Log Files• Checking for Locked Production Accounts• Checking for Files over a Certain Age• Checking for Too Many Processes• Verifying Integrity of RMAN Backups• This can be a long list...

Summary• In order to manage and maintain an environment with any

sort of complexity, DBAs must be proficient with automating various jobs.

• Oracle’s Job Scheduler and the Linux/Unix cron utility are two tools that DBAs commonly use to automate jobs.

• If you work in Linux/Unix environments, you should become familiar with cron, it’s widely used.