GRANT DBA TO 授予的是 Oracle 内置 DBA 角色，含约 160 个系统权限及数据字典 SELECT 权限，但不含 SYSDBA/SYSOPER 特权，且非最小权限，生产环境应避免滥用。
Oracle 中 GRANT DBA TO 实际授予的是什么权限
它不是“超级管理员”这个模糊概念的等价物，而是授予 dba 角色——一个 oracle 内置角色，包含约 160 个系统权限（如 create any table、drop any index、alter database），以及对数据字典视图的 select 权限。但注意：dba 角色不包含 sysdba 或 sysoper 系统特权，无法执行启动/关闭数据库、恢复控制文件等底层操作。
常见错误现象：GRANT DBA TO user1; 后，用户仍无法 STARTUP 或访问 V$INSTANCE —— 因为那需要 AS SYSDBA 连接，和角色无关。
-
DBA是角色（role），不是权限（privilege）本身，必须通过SET ROLE DBA或登录时启用（取决于DEFAULT ROLE设置）才能生效 - 授予前需确认目标用户已存在，且执行者拥有
GRANT ANY ROLE权限（通常只有SYS或已授该权限的用户能操作） - Oracle 12c 及以后，
DBA角色默认不包含UNLIMITED TABLESPACE，需单独授予，否则用户建表可能报ORA-01950: no privileges on tablespace
为什么不能直接用 GRANT DBA TO 替代最小权限原则
因为 DBA 是全库级高危角色：它允许用户删任意表、改任意存储过程、导出所有用户数据，甚至通过 CREATE LIBRARY + 外部函数执行操作系统命令（在旧版本中曾被用于提权）。生产环境直接授 DBA，等于交出数据库的物理控制权。
使用场景仅限于：DBA 自己管理账号、临时排障账号、隔离的开发测试库。绝不可用于应用连接账号或第三方工具账号。
- 替代方案更安全：
GRANT CREATE SESSION, CREATE TABLE, SELECT ANY DICTIONARY TO user1;按需组合 - 若需部分 DBA 能力，可复制
DBA角色内容，新建受限角色（如去掉DROP ANY *类权限） - Oracle 12c+ 支持权限分析（
DBMS_PRIVILEGE_CAPTURE），可先捕获真实使用权限，再精准授权
GRANT DBA TO 在不同 Oracle 版本中的兼容性差异
语法本身从 Oracle 7 一直保留至今，但行为有隐性变化。最关键是 12c 引入的“公共用户/本地用户”模型，以及 19c 对角色激活的限制增强。
- 在 CDB 环境下，
GRANT DBA TO c##user必须由CDB$ROOT中的SYS执行，且该角色只在根容器生效；若要给 PDB 用户授 DBA，必须在对应 PDB 中以SYS AS SYSDBA登录后执行 - Oracle 18c 起，默认禁用
DBA角色中的EXEMPT ACCESS POLICY权限，防止绕过 RLS（行级安全）策略 - 某些云托管 Oracle（如 AWS RDS）禁止普通用户执行
GRANT DBA TO，即使你是主账号，后台也拦截该语句
执行 GRANT DBA TO 后必须检查的三件事
授完不等于完事。权限生效有延迟环节，且容易因配置疏漏导致“看似授予，实则无效”。
- 检查角色是否设为默认：
SELECT DEFAULT_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'USER1' AND GRANTED_ROLE = 'DBA';若为FALSE，用户登录后需手动SET ROLE DBA; - 确认用户能连库：
sqlplus user1/pass@db成功后，运行SELECT * FROM SESSION_ROLES;看DBA是否在列表中 - 验证关键能力是否真可用：比如尝试
CREATE TABLE t AS SELECT * FROM all_objects WHERE ROWNUM=1;，而不是只查DBA_TABLES（后者可能因SELECT_CATALOG_ROLE已有而误判）
最容易被忽略的是角色默认状态和容器范围——CDB/PDB 切换、DEFAULT ROLE 设置、连接时是否指定了服务名，这三者任一出错，都会让 GRANT DBA TO 形同虚设。
