最近公司数据库出现了一个很奇怪的现象,后台负责调度scheduler的进程bidb_j000_* 总是莫名其妙的丢失,其实丢失也不能说明有问题,控制这些子进程的后台进程是 ora_cjq0_bidb,他会衍生出需要job的进程,但是我发现select * from dba_SCHEDULER_JOB_LOG order by log_id desc里面sys自带的一些scheduler也被hang住了,log的时间停留在9-25日,之后就再也没有了。
1.后台进程
$ps -ef|grep ora_
oracle@BI-DB-HIS:/oracle/admin/bidb/bdump$ ps -ef|grep ora_|grep bidb
oracle 1445 1 0 Aug 24 ? 0:11 ora_reco_bidb
oracle 1435 1 0 Aug 24 ? 1:10 ora_mman_bidb
oracle 1437 1 0 Aug 24 ? 22:46 ora_dbw0_bidb
oracle 1439 1 0 Aug 24 ? 31:33 ora_lgwr_bidb
oracle 1441 1 0 Aug 24 ? 14:13 ora_ckpt_bidb
oracle 1423 1 0 Aug 24 ? 8:49 ora_pmon_bidb
oracle 1496 1 0 Aug 24 ? 0:41 ora_q000_bidb
oracle 1448 1 0 Aug 24 ? 6:09 ora_cjq0_bidb
oracle 1458 1 0 Aug 24 ? 0:28 ora_qmnc_bidb
oracle 1433 1 0 Aug 24 ? 2:14 ora_psp0_bidb
oracle 1443 1 0 Aug 24 ? 4:56 ora_smon_bidb
oracle 1450 1 0 Aug 24 ? 7:19 ora_mmon_bidb
oracle 1452 1 0 Aug 24 ? 18:38 ora_mmnl_bidb
2.dba_SCHEDULER_JOB_LOG
select * from dba_SCHEDULER_JOB_LOG order by log_id desc
LOG_ID LOG_DATE OWNER JOB_NAME JOB_SUBNAME JOB_CLASS OPERATION STATUS
1 2195 26-9月 -09 03.00.00.377508 上午 +08:00 SYS PURGE_LOG DEFAULT_JOB_CLASS RUN SUCCEEDED
2 2194 25-9月 -09 10.01.15.568103 下午 +08:00 SYS AUTO_SPACE_ADVISOR_JOB AUTO_TASKS_JOB_CLASS RUN SUCCEEDED
3.临时解决方案
由于sys以及用户创建的scheduler都无法再执行了,因为没有任何反应,所以有两种临时解决方案:
(1) kill ora_cjq0_bidb
kill掉这个进程以后,一会会自动又生成一个ora_cjq0_bidb进程,相应的后台负责scheduler的进程也会被启动了。
(2) 手工创建一个scheduler,然后执行,也可以触发hang住的cjq0进程
--1.setup test environment:
SQL> create user jobtest identified by jobtest;
SQL> grant dba to jobtest;
SQL> connect jobtest/jobtest
SQL> alter session set nls_language = american;
SQL> alter session set nls_date_format= 'DD-MM-YY HH24:MI:SS';
SQL> create table jobtest ( a date);
--2.setup of a simple job inserting a value into a testable every 1 minutes:
SQL> BEGIN
DBMS_SCHEDULER.create_job (
job_name => 'runtest_job',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN insert into jobtest values (sysdate); commit; END;',
start_date => SYSDATE,
repeat_interval => 'SYSDATE + 1/1440' ,
enabled => TRUE,
auto_drop => FALSE);
End;
/
--3.setting the event 10046
SQL> alter session set max_dump_file_size=unlimited;
SQL> alter session set timed_statistics = true;
SQL> alter session set events '10046 trace name context forever, level 4';
SQL> begin
DBMS_SCHEDULER.RUN_JOB(job_name => 'runtest_job');
end;
/
SQL> exit;
(3) 重启db
metalink还在查询原因,说不好是什么问题,这种问题出现的频率是1个月一次,而且以前是一台数据库,现在有一个单节点的数据库也出现了这个问题,希望不是oracle的bug,有哪位朋友遇到过类似的问题,如果解决了的,希望可以support一下,谢谢。
SR Number 21864790.6 Open Date 21-SEP-09 01:28:37
Support Identifier 15681367 Name Lei Zhang
Severity 2 Last Update 22-SEP-09 07:12:44
Product Oracle Server - Enterprise Edition Product Version 10.2.0.4
SR Reference n/a BUG Reference n/a
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9252210/viewspace-617213/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/9252210/viewspace-617213/