前几天创建了个发邮件的存储过程，想把数据库每天的运行情况自动发到邮箱，没想到第二天就出了问题，在dbms/trace目录下产生了大量的xxx_j000_xxx.trc文件，一分
前几天创建了个发邮件的存储过程，想把数据库每天的运行情况自动发到邮箱，美国服务器，没想到第二天就出了问题，在dbms/trace目录下产生了大量的xxx_j000_xxx.trc文件，一分钟产生2个。alter日志报ora-12012、ora-06576错误，出现sys.process_etl2、dbms_scheduler、emd_maintenance.remove_em_dbms_jobs的内容。
--1.查询job：
select * from dba_jobs t;
what =process_etl2 的job=88，直接删除88的job。
或 ： sql> exec dbms_job.remove(job#); --移去job号
这个job已经删除了，但是trace文件还是照样产生。
--2. 删除em的job：
sql> exec emd_maintenance.remove_em_dbms_jobs;
trace文件还是照样产生。
--3. 查询process_etl2的对象：
select * from sys.dba_objects t where t.owner = 'sys' and object_name = 'process_etl2';
显示状态status=valid, 类型object_type=job，timestamp 的值不断的变化，看来这个job还是在执行，香港虚拟主机，但是查dba_jobs 试图已经看不到了。
--4. 必须删除process_etl2这个对象：
begin
dbms_scheduler.drop_job (
job_name => 'process_etl2',
force => true);
end;
--5. 再次查询process_etl2的对象：
select * from sys.dba_objects t where t.owner = 'sys' and object_name = 'process_etl2';
--已经没有了，trace目录下已经不产生相应文件了 。
--6. 总结：这个 scheduler email是11gr2的增强功能，在没有充分了解这个之前还是不能随便拿来使用的，可能会产生意想不到的结果。
--7. dbms_scheduler的create_job如下：
--建job：
begin
dbms_scheduler.create_job (
job_name => 'process_etl2',
job_type => 'stored_procedure',
job_action => 'process_etl2',
start_date => systimestamp,
repeat_interval => 'freq=minutely; bysecond=0',
enabled => true);
end;
---原过程见下：
procedure create_job(
job_name in varchar2,
schedule_name in varchar2,
job_type in varchar2,
job_action in varchar2,
number_of_arguments in pls_integer default 0,
job_class in varchar2 default 'default_job_class',
enabled in boolean default false,
auto_drop in boolean default true,
comments in varchar2 default null,
credential_name in varchar2 default null,
destination_name in varchar2 default null);
procedure drop_job(
job_name in varchar2,
force in boolean default false,
defer in boolean default false,
commit_semantics in varchar2 default 'stop_on_first_error');
本文出自 “srsunbing” 博客，香港服务器租用，请务必保留此出处