Job长时间运行不能退出的分析

今天接到公司运维人员反映说在一台DB上执行grant execute on DBMS_LOCK to xxx操作特别慢，等待了很长时间都不能执行完成。
我登录到数据上执行了一下，5分钟后，执行还没用完成，便手动结束了。然后尝试执行grant别的权限，发现很快就执行完成了， 只有执行grant execute on DBMS_LOCK to xxx的时候特别慢。再次执行，在大约10分钟后，抛出错误ORA-04021: timeout occurred while waiting to lock object SYS.DBMS_LOCK。看来是由于DBMS_LOCK包被锁了，导致执行grant慢。
从v$access视图中查看到占用DBMS_LOCK的用户：
SQL> select * from v$access where object like '%LOCK%';

SID OWNER OBJECT TYPE
---------- ---------- ------------------------------ ------------------------
34 SYS DBMS_LOCK PACKAGE
34 SYS DBMS_LOCK_ALLOCATED TABLE
34 SYS DBMS_LOCK_ID CURSOR

通过SID查找到进程，发现是一个JOB正在执行。该JOB是实现复制事务推送的PUSH进程。

从v$session中还查询到：
SQL> select sid,last_call_et from v$session where sid=34;

SID LAST_CALL_ET
---------- ------------
34 37329

该JOB已经执行了10个多小时。

但是查询该job的定义：
SQL> select * from dba_jobs where job=11;

JOB NEXT_DATE NEXT_SEC INTERVAL
---------- ----------------- ---------------- --------------------------------------------------
WHAT
------------------------------------------------------------------------------------------------------------------------------------
11 20080129 12:15:10 12:15:10 /*5:Secs*/ sysdate + 5/(60*60*24)
declare rc binary_integer; begin rc := sys.dbms_defer_sys.push(destination=>'SDWTDB1', delay_seconds=>5, parallelism=>1); end;

从中可以看出，该job的执行间隔是5秒钟，现网中需要复制的事务虽然多但是也不需要连续推送10个小时，而且从服务器的CPU观察，复制量远没用达到服务器的负荷，性能还不错。那么job运行这么长时间不退出，不正常。

考虑到dbms_defer_sys.push过程中delay_seconds参数的作用。job在执行完成后并不立即退出，还需要等待delay_seconds秒后，再次检查复制队列，如果为空，则退出退出。它的作用是避免在一个循环快的程序中频繁调用job。
观察现网中复制事务出现的速度，基本上每秒钟都用新的复制事务出现，这样，job在执行完后，过5秒，发现又有新的事务，再执行，再过5秒检查，再发现新的事务，再执行，再等5秒...... 如此循环，job不能退出。
尝试将delay_seconds参数修改为0,然后再观察，发现job每隔5秒执行一次，并且马上退出。再查询此时复制事务积压的情况，只有不到10个，比修改前平均积压50个快很多。

因此可知，Job长时间不能退出的原因是push过程的delay_seconds参数设置为5造成的。在复制事务出现比较频繁的数据库中，建议将该参数修改为0.

Job能迅速退出后，在执行grant execute on DBMS_LOCK to xxx，很快退出。

至此，问题得到解决。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11422417/viewspace-998679/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11422417/viewspace-998679/