在oracle 数据库中，执行计划任务的工具通常都是dbms_job 包。这个包使用简单，历史悠久，目前还在广泛使用中。坦率地讲，这个包的功能满足了绝大部分应用的计划任务运行需要，所以生命力才这么强。
但是，我们这里还是要说一下它的不足之处。
在dbms_job 使用中，我们需要知道每一次job 执行的时间，，用于判断该job 调用的存储过程执行时间。这里你会说，这个在存储过程里也可以实现的，在存储过程中，执行前后加个时间戳记录到日志表中就可以实现。
是的。以前我们在处理这类需求时也是这么做的。
但从oracle 10.1 版本开始，oracle 开发了一个新的包dbms_scheduler 。这个包挺复杂的，以至于我在初次学习之后，就没再去用它了。功能太强大了，其实很多我们不需要的。
我们就有这个需求，看看dbms_scheduler 是如何解决的。
在sqlplus 中，使用dbms_scheduler.create_job 创建计划任务，用于调度一个存储过程。
存储过程很简单，我为这个测试而创建的，就是向一张表里插入数据。
create table t1 as select sysdate as aa from dual;
create or replace procedure sp_test_t1 as
begin
insert into t1 selectd sysdate from dual;
commit;
end;
这个存储过程没有输入输出参数，是为了job 调用方便。如果实际运行过程中有参数，我们就写一个存储过程封装它，再放入job 中调用。
例如：
create procedure gather_gtja_stats
as
begin
sys.dbms_stats.gather_schema_stats(ownname => 'gtja',estimate_percent => 30,method_opt => 'for all indexed columns size auto',cascade => true,options => 'gather');
end;
使用dbms_scheduler.create_job 创建一个job, 调用存储过程sp_test_t1 ，执行间隔2 分钟。这里的job_name 名称可以自己定义，这个摆脱了dbms_job 中job 号不能自定义的缺点。
exec dbms_scheduler.create_job(job_name => 'job_sp_test_t1',job_type => 'stored_procedure',job_action =>'sp_test_t1' ,start_date => sysdate ,repeat_interval => 'freq=minutely; interval=2');
该命令执行成功后，可以在*_scheduler_jobs 中看到job 的配置值。
select * from dba_scheduler_jobs;
select * from user_scheduler_jobs where job_name='job_sp_test_t1';
使用该命令新建的job ，默认是不执行的，需要将其状态改成可执行状态。
exec dbms_scheduler.enable(name => 'job_sp_test_t1');
可以删除重建它。
exec dbms_scheduler.drop_job(job_name => 'job_sp_test_t1');
exec dbms_scheduler.create_job(job_name => 'job_sp_test_t1',job_type => 'stored_procedure',job_action => 'sp_test_t1',start_date => to_date('2012-06-12 15:30:00','yyyy-mm-dd hh24:mi:ss') ,repeat_interval => 'freq=daily');
这个创建过程而言，其实和dbms_job 创建job 的差别不大，但dbms_scheduler 可配置的地方就太多了。执行时间间隔非常非常灵活，这里不做详述了，具体请看oracle 官方文档。
dbms_scheduler 针对每一次job 执行，都做了详细记录，因此，可以查询到每一次job 执行的时间了。
具体可以查看两类视图*_scheduler_job_log 和*_scheduler_job_run_details 。
select * from dba_scheduler_job_log;
select * from dba_scheduler_job_run_details;
如果嫌日志太多了，可以使用purge_log 去清理。
execute dbms_scheduler.purge_log;
这个dbms_scheduler 包的功能太多了，用起来也累，所以很多人还是选择dbms_job 。
看到关于这两个包的不同点的介绍，摘录下来，留着参考。
at first glance it looks like only other names with more human readable schedules fordbms_scheduler , compared to dbms_job . when looking slightly better, there are loads of differences, even in oracle 10gr1. currently we are in 11gr2. every release dbms_scheduler gets more enhancements, where dbms_job has been static for many years.
differences
dbms_scheduler has logging dbms_scheduler has external jobs dbms_scheduler has job chains dbms_scheduler has job event handling (can raise and react upon events) dbms_scheduler has resource manager integration dbms_scheduler has human readable calendar syntax dbms_scheduler can combine different calendars in a new one in 11g extra
dbms_scheduler has remote external jobs dbms_scheduler has light weight jobs - generate many low overhead jobs in one tx dbms_scheduler can send mail on job completion dbms_scheduler jobs can have multiple targets dbms_job can only run pl/sql type of jobs in the current database.
i hope this (in complete list) h