CHAPTER 21
Automating 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 cron
1.
2.
3.
4.
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.
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.
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.
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.