自定义业务角色必须用create role显式声明，批量授权需基于数据字典驱动、dbms_assert.enquote_name防注入、minus排重，否则易触发ora-01932或ora-00942；预定义角色权限过粗且版本行为不一致，应从最小权限起步，禁用select any table，授前查role_sys_privs确保无系统权限，授后用dba_role_privs反查缺口生成精准grant语句，动态拼接必须用enquote_name包裹对象名以兼容大小写与特殊字符，新权限对已连接会话不生效，需重连或set role all激活。
直接给结论：自定义业务角色必须用 CREATE ROLE 显式声明，批量授权不能靠人工拼 SQL 字符串，得用数据字典驱动 + DBMS_ASSERT.ENQUOTE_NAME 防注入 + MINUS 排重，否则极易触发 ORA-01932 或 ORA-00942。
怎么创建安全的业务角色（非预定义）
预定义角色如 CONNECT、RESOURCE 不适合业务隔离——它们权限粒度太粗，且随 Oracle 版本变化行为不一致。自定义角色要从最小权限起步：
- 用
CREATE ROLE app_read_role IDENTIFIED BY "Sec@2026"创建带口令的角色（可选，但建议用于敏感场景） - 立即授予必要对象权限，例如
GRANT SELECT ON schema_a.orders TO app_read_role，不要依赖后续补授 - 避免授予
SELECT ANY TABLE这类 ANY 权限，它绕过所有 Schema 边界，在 CDB/PDB 架构下尤其危险 - 检查角色是否被误授了系统权限：
SELECT * FROM ROLE_SYS_PRIVS WHERE role = 'APP_READ_ROLE'，空结果才是理想状态
如何批量把角色授给多个用户且不重复报错
直接写 GRANT app_read_role TO user1, user2, user3 看似简单，但生产环境常见三类失败：
- 用户不存在 → 报
ORA-01917: user or role 'XXX' does not exist - 角色已授予 → 报
ORA-01921: role name 'XXX' conflicts with another user or role name（实际是重复授） - 用户在 CDB 级创建但未加
C##前缀 → 在 PDB 中执行失败
稳妥做法是查 DBA_ROLE_PRIVS 反推缺口：
SELECT 'GRANT app_read_role TO ' || grantee || ';'
FROM dba_role_privs
WHERE role = 'APP_READ_ROLE'
AND grantee IN ('USER1', 'USER2', 'USER3')
MINUS
SELECT 'GRANT app_read_role TO ' || grantee || ';'
FROM dba_role_privs
WHERE grantee IN ('USER1', 'USER2', 'USER3') AND granted_role = 'APP_READ_ROLE';
生成的语句只包含真正缺失的授权项。
为什么动态拼接 GRANT 语句必须用 DBMS_ASSERT.ENQUOTE_NAME
Oracle 对大小写敏感的对象名（如表名 CustomerOrders）强制要求双引号，而 DBA_TAB_PRIVS.owner 字段返回的是纯字符串，不含引号。若脚本写成：
'GRANT SELECT ON ' || owner || '.' || table_name || ' TO app_user'
遇到 owner='SCHEMA_A'、table_name='MyTable' 就会生成 GRANT SELECT ON SCHEMA_A.MyTable TO app_user，执行时报 ORA-00942。
正确写法是：
DBMS_ASSERT.ENQUOTE_NAME(owner) || '.' || DBMS_ASSERT.ENQUOTE_NAME(table_name)
它会自动包裹为 "SCHEMA_A"."MyTable"，兼容所有命名风格。注意：该函数对非法标识符会直接抛异常，比手工加引号更安全。
新授权对已连接会话不生效，这点最容易被忽略
即使 GRANT 执行成功，当前已连上的应用连接不会自动获得新权限。典型现象是 Java 应用重启前一直报 ORA-01031: insufficient privileges。
- 用户需手动执行
SET ROLE ALL激活新授角色（仅对当前会话） - 若角色带口令，需
SET ROLE app_read_role IDENTIFIED BY "Sec@2026" - 长期方案是让应用使用短连接，或在连接池初始化 SQL 中加入
SET ROLE
另外，CDB 级角色（如 C##APP_ROLE）在 PDB 中默认不可见，必须先在 PDB 中 CREATE SYNONYM 或显式 GRANT 到本地用户。
