我们希望在我们的 Oracle 数据库上创建一个 ANALYTICS 角色。担任此 ANALYTICS 角色的任何人都应该能够在一个（或多个）架构中的任何视图中进行 SELECT，但不是所有架构。
例如，我们有一个名为 ARIEL 的架构，当我们创建新的表和视图时，我们不希望不断地将 GRANTS 应用到 ANALYTICS 角色，因此我们希望有一种方法来应用授权像这样“GRANT SELECT ON SCHEMA_X TO ANALYTICS 中的所有表”...注意 ANALYTICS 是一个角色，而不是一个架构。
我们的 DBA 表示这是不可能的，我们创建的任何未来对象都需要应用授权，以授予对 ROLE 的访问权限。
【问题讨论】：
“我们的 DBA 说这是不可能的，我们创建的任何未来对象都需要申请授权，以授予对 ROLE 的访问权限。”
您的 DBA 是正确的。您正在搜索架构范围的权限（尚未实现）。
【讨论】：
您的 DBA 是正确的，需要为创建的每个对象授予授权。可以自动执行此操作，这基本上可以为您提供所需的行为。我过去做过这件事。但在实施之前，我会认真质疑该要求。
一般来说，新表不会在生产环境中自动创建，它们是作为构建过程的一部分创建的。该构建过程的一部分涉及执行诸如确定谁应该有权访问表之类的事情。假设您正在使用某种源代码控制系统，这意味着您拥有对象授权的历史记录，并且您可以将这些授权中的更改与用户故事联系起来。这是一个有用的东西。
如果您的应用程序在生产环境中动态创建新表（例如我支持的现成应用程序），或者在做其他事情时在构建过程中提供授权可能会出现问题，您可以使用DDL 触发器。
dbms_job 在 CREATE TABLE 语句提交后立即运行授权语句这样的东西应该可以工作（未经测试）
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 也可能会禁用作业或限制可以同时运行的作业数量，这可能会进一步延迟授权。如果触发器或工作出现问题，这是一种非常模糊的方法，人们需要一段时间才能找出问题所在。 DBA 不习惯寻找可能正在授予特权的 DDL 触发器，例如，当某人决定希望一个新角色自动获得对新表的insert 访问权限时，或者当由于作业而未发生授予时被禁用了。
【讨论】：