众所周知,一般操作系统会提供定时执行任务的方法,例如:Unix平台上提供了让系统定时执行任务的命令Crontab。但是,对于某些需求,例如:一些对数据库表的操作,最为典型的是证券交易所每日收盘后的结算,它涉及大量的数据库表操作,如果仍然利用操作系统去定时执行,不仅需要大量的编程工作,而且还会出现用户不一致等运行错误,甚至导致程序无法执行。
事实上,对于以上需求,我们可以利用数据库本身拥有的功能Job Queue(任务队列管理器)去实现。任务队列管理器允许用户提前调度和安排某一任务,使其能在指定的时间点或时间段内自动执行一次或多次,由于任务在数据库中被执行,所以执行效率很高。
任务队列管理器允许我们定制任务的执行时间,并提供了灵活的处理方式,还可以通过配置,安排任务在系统用户访问量少的时段内执行,极大地提高了工作效率。例如,对于数据库日常的备份、更新、删除和复制等耗时长、重复性强的工作,我们就可以利用任务队列管理器去自动执行以减少工作量。
目前,拥有此项功能的数据库有许多,最有代表性的是SQL Server 7.0、Oracle 8.0.5等。但是,要让任务队列管理器工作,还需要我们加以配置才能实现。SQL Server的功能配置是在一个图形化界面(GUI)中实现的,非常简单。利用OEM客户端管理工具,Oracle的配置也可以在一个图形界面中完成。然而大多数的用户更习惯于命令行的方式去操纵数据库。本文介绍如何通过命令行实现这种配置。
Oracle定时执行“Job Queue”的后台程序是SNP进程,而要启动SNP进程,首先要确保整个系统的模式是可以启动SNP进程的,这需要以DBA的身份去执行如下命令:
SNP的启动参数位于Oracle的初始化文件中,该文件放在$ORACLE_HOME/dbs路径下,如果Oracle的SID是myora8的话,则初始化文件就是initmyora8.ora,在文件中对SNP启动参数的描述部分如下:
第二行定义系统每隔N秒唤醒该进程一次。系统缺省值为60秒,正常范围为1~3600秒。事实上,该进程执行完当前任务后,就进入睡眠状态,睡眠一段时间后,由系统的总控负责将其唤醒。
下面详细讨论一下dbms_job.submit中的参数interval。严格地讲,interval是指上一次执行结束到下一次开始执行的时间间隔,当interval设置为null时,该job执行结束后,就被从队列中删除。假如我们需要该job周期性地执行,则要用‘sysdate+m’表示。
将任务加入到任务队列之前,要确定执行任务的数据库用户,若用户是scott, 则需要确保该用户拥有执行包dbms_job的权限;若没有,需要以DBA的身份将权利授予scott用户:
svrmgrl> grant execute on dbms_job to scott;
|
4.将要执行的任务写成存储过程或其他的数据库可执行的pl/sql程序段
例如,我们已经建立了一个存储过程,其名称为my_job,在sql/plus中以scott用户身份登录,执行如下命令:
sql> variable n number;
sql> begin
dbms_job.submit(:n‘my_job;’,sysdate,
‘sysdate+1/360’);
commit;
end;
/
|
系统提示执行成功。
系统打印此任务的编号,例如结果为300。
如上,我们创建了一个每隔4分钟执行一次的任务号为300的任务。可以通过Oracle提供的数据字典user_jobs察看该任务的执行情况:
sql> select job,next_date,next_sec,failures,broken from user_jobs;
|
执行结果如下:
job next_date next_sec failures broken
300 2000/10/10 11:45:15 0 N
|
这表示任务号为300的任务,下一次将在2000/10/10 11:45:15执行,此任务的执行失败记录为0次。注意:当执行job出现错误时,Oracle将其记录在日志里,失败次数每次自动加1。当执行失败次数达到16时,Oracle就将该job标志为broken。此后,Oracle不再继续执行它,直到用户调用过程dbms_job.broken,重新设置为not broken,或强制调用dbms_job.run来重新执行它。
除了以上我们讨论的submit存储过程之外,Oracle还提供了其他许多存储过程来操作任务。例如:dbms_job.change 、 dbms_job.what、dbms_job.interval可以用来修改提交的任务。要想删除该任务,只需运行dbms_job.remove(n)即可,其中n为任务号。
查看所有0条评论>>