计划作业监控Oracle数据库

威海职业学院 赵永华

UNIX/Windows等操作系统中都提供了“计划任务”，它主要用于夜间备份文件等工作场合。在Oracle等数据库中的“计划作业”（DB Job）的作用与其异曲同工。

也许有人会问，为什么不直接利用操作系统的计划任务去执行数据库的计划任务呢？您只要从事过相关的实际工作就会明白，操作系统的计划任务往往难以胜任数据库的计划任务，比如在启动作业之际，操作系统往往无法验证此时数据库是否处于运行状态。再者，假如此时发生了意外事件，该如何阻止运行中的作业也颇为棘手。

Oracle计划作业

Oracle10g版中提供了一种针对存储过程（即Jobs）的运行机制，就是在特定时间段内处理后台进程。

Oracle数据库自身就能够请求计划过程，在该时段内若数据库发生意外故障也不要紧，只要数据库启动后，该过程也会随之运作，此时并不要求提供Password。

当然，该过程要求用户具有相应权限。假如您不想让它运行，只要将作业状态设为“Broken”即可。

这里牵涉到Oracle作业队列在预定时间里按计划执行PL/SQL例程，以及周期性执行作业的内容。

我们从多个数据目录都可以看到Oracle Job Queue的相关信息，包括dba_jobs、user_jobs、dba_jobs_running。Oracle内置包dbms_job便可用于计划性作业，当Oracle数据库安装时所产生的这种API对所有Oracle用户都具有公开的调用许可。

在执行计划作业之前，需要确认相关数据库处理作业的设置工作已经完成，其中的一个重要标志是，作业队列已经具有指定的后台处理（可以启动处理作业），它需要对数据库文件init.ora中的初始化参数job_queue_processes进行设置。

假如作业未能按计划正常运行，我们要做的第一件事情就是检查作业队列号，即检查初始化参数job_queue_processes。

下列SQL语句可显示job_queue_processes的初值：

      SQL>show parameter job_queue_processes
      Name Type Value
      job_queue_processes integer 100

在实际应用中，该参数值应当比期望运行的并行作业的数更大些，可以设置的最大值是1000。

Oracle运行项目实例

某电信系统工作日访问服务往往达每秒数千个之多，此时运营商需要对数据库性能进行监控，对一些关键设置参数的改变能够及时觉察。我们不妨将其所处理业务的关键参数整理成一个具体数据库表（如表1）。

表1 关键参数

这里，访问网关需要对服务运行中的每次请求计算开始时间Start_Time与结束时间End_Time。假定我们将一分钟内累积的数据汇总放入另一个表（如表2），该表将用于与关键设置值进行比较，一旦出现非正常值就发出警报。

表2 一分钟内积累的数据汇总

这里的任务发生在数据库内部，它独立于其他在线系统。而且，这项任务可以作为一种计划型的数据库作业，它有自己的控制表用于收集故障信息再提供给由Oracle所管辖的独立的计划类表，这个控制表含有的数据窗体独立于运行窗体。

这里的DB作业如同一个批处理程序，不断采集数据，以离线方式进行分析，它并不会影响在线系统如网关访问。

在实际项目中，DB Job采用了一个控制表去保持时间轨迹。该表名为Control_ TB（如表3），时间轨迹由其中的列Prev_Timestamp记录。

表3 Control_TB

数据库Job会从表3 取得Prev_Timestamp，结束时间End_Time为Prev_Timestamp+ Data_Collection_Interval（如表4）。而当作业执行成功后，它就会用End_Time更新Prev_Timestamp，DB Job会通过以下算式计算将要处理的数据块所需时间：

表4 PM_Delta_Config

      No_of_chunks=REPEAT_
      INTERVAL/DATA_CO LLECTION_INTERVA

这样，当数据库作业每次被唤醒时，就需要n分钟处理数据，此处的n分钟将会设置为PM_Delta_Config（如表4）中的“data_collection_interval”。

凡此种种，在实际中是通过一个PL/SQL例程实现的，它的功能是从表1中汇总数据，而将处理结果放置到表2中。由于篇幅所限，代码从略。