我们希望在Oracle数据库上创建一个ANALYTICS角色。处于此ANALYTICS角色的任何人都应该能够跨一个(或多个)模式中的任何视图进行SELECT,而不是所有模式。
例如,我们有一个名为ARIEL的模式,当我们创建新的表和视图时,我们不希望不断地将GRANTS应用于ANALYTICS角色,因此我们希望有一种方法来应用这样的授权“ GRANT选择SCHEMA_X到ANALYTICS中的所有表格“...注意ANALYTICS是一个角色,而不是一个模式。
我们的DBA说这是不可能的,我们创建的任何未来对象都需要应用授权,从而可以访问ROLE。
“我们的DBA说这是不可能的,我们创建的任何未来对象都需要应用授权,才能访问ROLE。”
你的DBA是对的。您正在搜索架构范围的权限(尚未实现)。
您的DBA是正确的,需要为每个创建的对象提供授权。可以自动执行此操作,从而基本上为您提供所需的行为。我过去做过这个。但是在实施之前我会严肃地质疑这个要求。
通常,新表不会自动在生产中创建,它们是作为构建过程的一部分创建的。构建过程的一部分涉及做一些事情,比如找出谁应该访问表。假设您正在使用某种源控制系统,这意味着您已经获得了对象授权的历史记录,您可以将这些授权中的更改与用户故事联系起来。这是件有用的事情。
如果你有动态创建新表的应用程序(比如我支持的现成应用程序)或者做其他事情,那么在构建过程中提供授权会有问题,你可以使用DDL触发器自动执行该过程。
dbms_job
在CREATE TABLE
语句提交后立即运行grant语句像这样的东西应该工作(未经测试)
CREATE OR REPLACE TRIGGER ddl_create
AFTER CREATE ON SCHEMA
DECLARE
l_job BINARY_INTEGER;
l_sql VARCHAR2(4000);
BEGIN
IF ora_dict_obj_type = 'TABLE'
THEN
l_sql := 'grant select on ' ||
ora_dict_obj_owner || '.' || ora_dict_obj_name ||
' to analytics';
DBMS_JOB.SUBMIT (
job => l_job,
what => l_sql );
END IF;
END;
由于作业是异步运行的,因此在创建表后可能需要一两秒才能运行,如果应用程序立即尝试对该对象运行查询,则可能会出现问题。您的DBA也可能会禁用作业或限制可以同时运行的作业数量,这可能会进一步延迟授权。如果触发器或工作出现问题,这是一个非常模糊的方法,它会花费一些时间来确定问题所在。当有人决定,例如,他们希望新角色自动获取新表上的insert
访问权限或者由于作业被禁用而没有发生授权时,DBA不习惯查找可能授予权限的DDL触发器。