直接授予SELECT ANY TABLE不可行，因其权限过大违反最小权限原则、审计不通过且无法限定schema；推荐用DDL触发器监听CREATE TABLE并动态授权，或使用角色继承机制实现可控的自动授权。
为什么直接 GRANT SELECT ANY TABLE 不行
很多人第一反应是给用户授 SELECT ANY TABLE，看似一劳永逸。但它在生产环境里基本不可用：权限过大，违反最小权限原则；审计不通过；且无法控制到具体 schema，比如你只想让只读用户查 app_user 下的表，但这个系统权限会让他看到 sys、system 甚至其他业务用户的表。
触发器 + DBA_TAB_COLUMNS 是最稳的自动同步方案
Oracle 没有“新建表自动授权”的原生机制，但可以通过 DDL 触发器监听 CREATE TABLE 事件，并在表创建后立即执行 GRANT SELECT。关键点在于：必须用 AFTER CREATE ON SCHEMA 级别触发器，且仅对目标 schema 生效。
- 触发器需定义在目标业务 schema（如
app_user）下，不能建在sys或system下，否则会因权限不足报ORA-01031: insufficient privileges - 触发器体内不能直接写
GRANT，必须用DBMS_SQL或EXECUTE IMMEDIATE动态执行，且调用者需有ADMINISTER DATABASE TRIGGER权限 - 要过滤掉临时表、物化视图日志表等非业务对象，建议检查
DBA_TAB_COLUMNS中该表是否存在有效列（COUNT(*) > 0），避免对空表或系统生成表误授权
示例触发器片段（以 app_user 为源 schema，ro_user 为目标只读用户）：
CREATE OR REPLACE TRIGGER app_user.trg_grant_on_create
AFTER CREATE ON app_user.SCHEMA
WHEN (ora_dict_obj_type = 'TABLE')
DECLARE
v_sql VARCHAR2(500);
BEGIN
v_sql := 'GRANT SELECT ON app_user.' || ora_dict_obj_name || ' TO ro_user';
EXECUTE IMMEDIATE v_sql;
EXCEPTION
WHEN OTHERS THEN
NULL; -- 避免建表失败被触发器拖垮
END;
用 Oracle 12c+ 的角色继承机制更轻量
如果业务 schema 固定、表结构稳定，推荐用角色代替逐表授权。先创建一个角色（如 app_read_role），把所有当前表的 SELECT 权限授给它，再把这个角色授予 ro_user。后续新增表时，只需把新表权限加到该角色，无需改触发器或重跑脚本。
- 角色方式不依赖触发器，规避了 DDL 触发器在 RAC 环境中可能的节点间同步延迟问题
- 但要求 DBA 或运维人员主动维护角色权限，适合发布流程规范、DDL 变更受控的团队
- 注意：角色权限在会话中不会自动刷新，
ro_user需重新连接或执行SET ROLE才能生效新权限
最容易被忽略的坑：PDB 和权限传播
如果你的 Oracle 是 12c 及以上版本，且运行在多租户（CDB/PDB）架构下，ro_user 必须建在和业务表相同的 PDB 里，否则即使触发器成功执行了 GRANT，也会因容器隔离导致权限无效。另外，GRANT 语句中必须显式写出 schema 名（如 app_user.table_name），不能省略——省略会导致权限被授给当前 session 的 default schema，极大概率不是你想要的目标 schema。
