GRANT DBA TO username 直接授予Oracle内置DBA角色，含约160个系统权限（如ALTER SYSTEM、DROP ANY TABLE）及所有DBA_*数据字典视图SELECT权限，但不含SYSDBA/SYSOPER特权。
GRANT DBA TO 会直接赋予什么权限
执行 grant dba to username; 不是给“dba头衔”，而是把 oracle 内置的 dba 角色完整授予该用户。这个角色包含约 160 个系统权限（如 alter system、drop any table、create user），以及对所有数据字典视图（dba_*）的 select 权限。
它不等于 SYSDBA，也不带操作系统级特权（比如启动/关闭实例），但已足以让该用户绕过绝大多数对象级权限控制，删库、改参数、导出全库元数据都可行。
- 必须由
SYS或具备GRANT ANY ROLE权限的用户执行 - 无需重启数据库，授权立即生效
- 被授用户仍需显式连接：例如
sqlplus username/password@db as sysdba才能用SYSDBA；而DBA角色本身不改变连接方式
常见误操作：ALTER USER GRANT DBA 是错的
ALTER USER username GRANT DBA; 这条语句根本不存在，Oracle 会报 ORA-02145: missing STORAGE clause 或直接语法错误。DBA 是角色（role），不是用户属性，只能用 GRANT 语句赋予，不能通过 ALTER USER 修改。
容易混淆的点：
-
ALTER USER username DEFAULT ROLE ALL;只影响当前会话默认启用哪些已授予的角色，不授予权限本身 -
ALTER USER username QUOTA UNLIMITED ON users;是配表空间配额，和 DBA 权限无关 - 真正要授 DBA，只有一条路：
GRANT DBA TO username;
为什么 grant connect, resource, dba to user 是冗余且危险的
很多脚本或教程里写 GRANT CONNECT, RESOURCE, DBA TO username;，这其实多此一举：
-
DBA角色已隐含包含CONNECT和RESOURCE的全部权限（包括CREATE SESSION、CREATE TABLE等） - 重复授予不会报错，但会让权限审计变混乱——查
DBA_ROLE_PRIVS会看到三条记录，实际只有DBA在起作用 -
RESOURCE角色本身已被标记为“legacy”，Oracle 官方文档建议避免单独使用
更干净的做法是：先确保用户有 CREATE SESSION（否则连不上），再单授 DBA：
GRANT CREATE SESSION TO username; GRANT DBA TO username;
生产环境里最容易被忽略的两个检查点
授完 DBA 后，很多人以为万事大吉，但以下两点常被跳过，导致后续排查困难：
- 确认用户是否真能访问数据字典：
SELECT COUNT(*) FROM DBA_USERS;—— 若报ORA-00942: table or view does not exist，说明该用户没被授予SELECT_CATALOG_ROLE，而DBA角色本应自带；此时需检查是否在非 CDB 环境下误用了 PDB 权限模型，或密码文件未同步 - 检查
V$PWFILE_USERS视图：虽然DBA不依赖密码文件，但如果用户后续想用as sysdba登录，就必须出现在该视图中；而GRANT DBA TO不会自动将其写入，必须额外执行GRANT SYSDBA TO username;并确认REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
权限一旦授予，撤回也简单：REVOKE DBA FROM username;，但要注意：如果该用户已用 DBA 创建了其他用户或对象，这些不会自动清理。
