这个权限问题其实是Oracle存储过程执行时的常见坑——核心原因是存储过程的权限上下文和你手动执行SQL时不一样。你手动能插临时表，但存储过程不行，大概率是权限授予的方式或者存储过程的权限继承规则在搞鬼，咱们来一步步解决：

核心原因拆解 #

Oracle存储过程默认采用DEFINER权限模式（即存储过程创建者的权限），而且这种模式下不会继承通过角色授予的权限——哪怕你手动执行时用DBA角色能操作所有表，存储过程里也认不到这些角色权限。而你手动执行SQL时是用当前用户的所有权限（包括角色授予的），所以能正常操作临时表。

解决方案一：直接授予存储过程创建者对象权限 #

如果想保持默认的DEFINER模式，你需要给存储过程的创建用户直接授予所有涉及表的操作权限（不能通过角色）：

假设存储过程是由USER_X创建的，用拥有DBA权限的用户执行以下授权语句：

-- 授予源表的查询和删除权限
GRANT SELECT, DELETE ON crpdta.f59pt021 TO USER_X;
-- 授予临时表的插入和查询权限
GRANT INSERT, SELECT ON tmptbl_fr59pt021 TO USER_X;
-- 授予历史表的插入权限
GRANT INSERT ON crpdta.F59PT021_HTR TO USER_X;

授权完成后重新编译存储过程，再执行应该就没问题了。

解决方案二：改用调用者权限模式执行存储过程 #

如果你希望存储过程用当前调用者的权限执行（和你手动操作时的权限一致），可以修改存储过程的定义，加上AUTHID CURRENT_USER声明：

create or replace Procedure SP_PE_MIG_PT021 AUTHID CURRENT_USER AS
BEGIN
savepoint inicio;
--Insersión de datos de seis meses atrás a la fecha actual
insert into tmptbl_fr59pt021 
select * from (
    select * from crpdta.f59pt021 
    where jde_date(PT59DTPT) <= (select add_months(To_date(current_date),-6) from dual) 
    and trim(PTIDPTPY) = '0010490' 
) ;
insert into crpdta.F59PT021_HTR select * from tmptbl_fr59pt021;
--Eliminar datos de la tabla origen
delete from crpdta.f59pt021 
where jde_date(PT59DTPT) <= (select add_months(To_date(current_date),-6) from dual) 
and trim(PTIDPTPY) = '0010490';
commit;
end SP_PE_MIG_PT021;

这种方式下，存储过程会继承你手动操作时的所有权限（包括角色授予的），因为它用的是调用者的权限上下文，刚好匹配你手动能操作临时表的场景。

额外排查点 #

如果还是有问题，可以检查：

• 确认临时表tmptbl_fr59pt021是会话级临时表（GLOBAL TEMPORARY TABLE ... ON COMMIT PRESERVE ROWS），如果是事务级的，存储过程里的commit会清空临时表，但这不是权限问题，不过可以顺便确认下。
• 检查jde_date函数是否有执行权限，确保存储过程创建者或调用者有权限调用这个自定义函数。

内容的提问来源于stack exchange，提问作者Harold S Rpo