平日里正常使用的execute immediate 'insert into .....'今天突然不能使用了。报错
ORA-01031: insufficient privileges
ORA-06512: at "LHY.JF_TEST", line 25
--查看是不是没有insert any tables权限
select * from session_privs where privilege like '%insert%';
insert any tables;
在前面加了一个测试,是可以插入的。但是就是后一句无论如何都不行。见图。
一开始搜到的提示是:
You are trying to do a select, update, insert, ...
Sometimes it can be that you have the privileges, but you still get this error.
This might occur if you try to use a privilege granted via a role inside a pl/sql program.
Whenever you try to compile a pl/sql program (procedure, function, package, ...), roles are disabled, and thus any privilege you were granted via a role are also disabled.
You will have to grant the privilege directly to the user instead of via a role.
说明不能用role来控制权限。应该把insert any table 直接给该用户。不能通过role赋权。
自己不是DBA放弃了这个方法。感兴趣的兄弟可以自己试试。
后来看到一篇帖子:
我们知道,用户拥有的role权限在存储过程是不可用的。遇到这种情况,我们一般需要显式进行系统权限,如grant create table to suk;但这种方法太麻烦,有时候可能需要进行非常多的授权才能执行存储过程,实际上,oracle给我们提供了在存储过程中使用role权限的方法:修 改存储过程,加入Authid Current_User时存储过程可以使用role权限。
我们知道,用户拥有的role权限在存储过程是不可用的。如:
SQL> select * from dba_role_privs where grantee='SUK';
GRANTEE GRANTED_ROLE ADMIN_OPTION DEFAULT_ROLE
------------ ------------ ------------ ------------
SUK DBA NO YES
SUK CONNECT NO YES
SUK RESOURCE NO YES
用户SUK拥有DBA这个role
再创建一个测试存储过程:
create or replace procedure p_create_table
is
begin
Execute Immediate 'create table create_table(id int)';
end p_create_table;
然后测试
SQL> exec p_create_table;
begin p_create_table; end;
ORA-01031: 权限不足
ORA-06512: 在"SUK.P_CREATE_TABLE", line 3
ORA-06512: 在line 1
可以看到,即使拥有DBA role,也不能创建表。role在存储过程中不可用。遇到这种情况,我们一般需要显式进行系统权限,如grant create table to suk;
但这种方法太麻烦,有时候可能需要进行非常多的授权才能执行存储过程。实际上,oracle给我们提供了在存储过程中使用role权限的方 法:
修改存储过程,加入Authid Current_User时存储过程可以使用role权限。
create or replace procedure p_create_table
Authid Current_User is
begin
Execute Immediate 'create table create_table(id int)';
end p_create_table;
再尝试执行:
SQL> exec p_create_table;
PL/SQL procedure successfully completed
已经可以执行了。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/wh62592855/archive/2009/11/21/4849813.aspx