Chapter 21

1. Chapter 21 Automating Jobs

2. 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

3. Utilities to Automate • Oracle Scheduler • The Linux/Unix cronutility • Others?

4. 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; /

5. Viewing Job Details • To view details about how a job is configured query the DBA_SCHEDULER_JOBSview. • 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';

6. 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_ATTRIBUTEprocedure. • 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();

7. Modifying a Job • You can modify various attributes of a job via the SET_ATTRIBUTEprocedure. • 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; /

8. 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');

9. 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');

10. Enabling a Job • You can enable a previously disabled job via the ENABLE procedure of the DBMS_SCHEDULERpackage. • This example re-enables the RMAN_BACKUP job: SQL> exec dbms_scheduler.enable(name=>'RMAN_BACKUP');

11. 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; /

12. 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; /

13. 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; /

14. 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

15. 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

16. How cronWorks • 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 crondaemon. • This process is started on system startup by the /etc/init.d/crondscript. • You can check to see whether the cron daemon process is running with the ps command: • $ ps -ef | grepcrond | grep -v grep • root 3049 1 0 Aug02 ? 00:00:00 crond

17. 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

18. 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

19. Editing the cron Table Directly • You can edit your cron table directly with the -e (editor) option of the crontab command: $ crontab -e

20. 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>

21. Redirecting cronOutput • 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.

22. Troubleshooting cron • 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.

23. 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...

24. 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.