最近公司数据库出现了一个很奇怪的现象，后台负责调度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