DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_SQL执行后START_ID为NULL的权限排查咨询

看起来你碰到了一个环境差异导致的棘手问题——在个人电脑/虚拟机上执行CREATE_CHUNKS_BY_SQL后，start_id能正常返回1，但到了业务环境里就变成NULL了，而且你怀疑是权限缺失导致的，我来帮你梳理几个排查方向：

首先聚焦权限相关的排查点： #

• 检查DBMS_PARALLEL_EXECUTE包的完整权限：虽然你能成功创建任务，但可能业务环境里的用户只拿到了部分执行权限，建议确认是否给用户直接授予了EXECUTE ON SYS.DBMS_PARALLEL_EXECUTE权限（尽量避免通过角色间接授予，部分场景下角色权限在PL/SQL块中可能不生效）。
• MANAGE SCHEDULER权限：Oracle的DBMS_PARALLEL_EXECUTE依赖Scheduler组件，创建任务块时需要写入元数据的权限，尝试给用户授予MANAGE SCHEDULER权限后再测试，看是否能解决问题。
• 查询对象的权限确认：你的测试SQL是查询SYS.DUAL，虽然这是公共对象，但有些严格的业务环境可能限制了普通用户对SYS schema对象的访问，确认执行用户是否有SELECT ON SYS.DUAL的直接权限。
• 视图底层权限排查：你能查询DBA_PARALLEL_EXECUTE_CHUNKS但返回NULL，可能是这个视图依赖的底层表（比如SYS.PARALLEL_EXECUTE_CHUNKS$）没有给用户授权，这种情况比较少见，但可以作为补充排查点。

除了权限，这些环境差异点也值得检查： #

• Oracle版本一致性：对比个人环境和业务环境的Oracle数据库版本，不同版本的DBMS_PARALLEL_EXECUTE可能存在行为差异，比如某些旧版本对常量查询的块生成逻辑有bug。
• 任务状态与错误日志：先查询任务的状态，确认是否有异常：

  SELECT task_name, status, error_message FROM dba_parallel_execute_tasks WHERE task_name = 'TASK_TEST';
  

  同时检查Scheduler的运行日志或者数据库alert日志，看创建块的过程中是否有未抛出的异常信息。
• 替换测试SQL验证：尝试用一个实际业务表的查询来替代SYS.DUAL的常量查询，比如：

  sys.DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_SQL('TASK_TEST','SELECT id column_1, id column_2 FROM your_test_table WHERE rownum <=1',false);
  

  如果这样能正常生成start_id，说明业务环境对常量查询的块生成逻辑有特殊限制。

你的测试代码如下，方便参考：

begin
--sys.dbms_parallel_execute.drop_task(task_name => 'TASK_TEST');
sys.dbms_parallel_execute.create_task(task_name => 'TASK_TEST');
sys.DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_SQL('TASK_TEST','SELECT 1 column_1, 2 column_2 FROM sys.dual',false);
end;
/

查询验证语句：

select start_id from sys.dba_parallel_execute_chunks;
-- 业务环境返回NULL（不符合预期）
-- 个人环境返回1（符合预期）

备注：内容来源于stack exchange，提问作者iltermutlu