没有提示权限不足或者语法错误就查看现有的job运行数和查看job参数，逐渐排查了～ 

show parameter job_queue_processes

select * from dba_jobs_running;

哎，oracle原厂排查了一个月了

这个问题网上有很多答案，大多都是说允许同时运行的job数量设置少了。但实际上默认值是很大的，一般也不会有人去修改。

alter system set job_queue_processes=100 scope=both;

另外还有一种答案就是执行这段

begin
dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE');
end;
/

我上次遇到这个问题，这两种方法都不适用，所以请看下面。

如果是windows的话，看下windows服务里的schedule_job服务是不是开了。

如果是linux的话，存在一个这样的可能，就是oracle进程是直接被kill，然后再启动时，有些服务进程无法正常初始化，这个schedule_job就容易出现这种情况(但很遗憾，虽然我可以100%复现这个场景，但没想出怎么解决)

另外，在mos文档中还有个这样的方案
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=154714830375243&parent=EXTERNAL_SEARCH&sourceId=PROBLEM&id=1190580.1&_afrWindowMode=0&_adf.ctrl-state=2hpr48may_53

CAUSE
The Database Scheduler feature is not active.

SOLUTION
From a SQL*Plus session
1- Log in as SYS
2- Startup Database in upgrade mode:
SQL> startup upgrade
3- Activate the scheduler.
SQL> exec dbms_ijob.set_enabled(true);
4- Restart the Database
SQL> shutdown immediate
SQL> startup
5- Re-run the Job

不是这个原因

1.cdb和pdb都检查job参数了？
2.bug

因为一体机PDB开始处于受限模式(Restricted)，然后设置了非受限模式也不管用

这种情况我也遇到过哈，刚创建新的PDB就是受限模式了，重启服务器重启数据库都不行，而且改不过来。

后来我发现，原来是我的数据文件的文件夹是使用了软链接挂载了其他磁盘格式的存储（比如windows docker内的数据库挂载宿主机文件夹作为数据文件及配置文件目录），我就把这个挂载取消，直接用服务器自己的存储空间，果然就不是受限模式了