grant dba to app_user 是高危操作，因dba角色含约160个系统权限（如drop any index、alter database）及数据字典查询权，赋予应用账号物理层控制权，违背最小权限原则，且在oracle和金仓等库中存在权限不一致、隐性失效等风险。
GRANT DBA TO app_user 为什么是高危操作
因为 DBA 是 Oracle 内置的全库级角色，不是“能干活就行”的权限集合，而是约 160 个系统权限的叠加体，包含 CREATE ANY TABLE、DROP ANY INDEX、ALTER DATABASE 等破坏性能力，且默认还附带对所有数据字典视图（如 DBA_TABLES、V$SESSION）的 SELECT 权限。
一旦应用账号拥有该角色，等于把数据库的物理层控制权交给了应用代码——哪怕只是 SQL 注入或配置误写，都可能触发 DROP TABLESPACE 或 CREATE LIBRARY 调用操作系统命令等越界行为。
DBA角色不等于SYSDBA，也不能替代连接能力
常见误解是“给了DBA就能连库、就能看V$视图”，但实际：
-
GRANT DBA TO app_user后，用户仍需先有CREATE SESSION权限才能登录；Oracle 12c+ 默认甚至不包含UNLIMITED TABLESPACE，建表直接报ORA-01950 - 访问
V$INSTANCE、V$DATABASE等动态性能视图，依赖的是SELECT_CATALOG_ROLE或显式SELECT权限，DBA角色虽含部分字典查询权，但不保证覆盖全部V$视图 -
SYSDBA是认证级别（连接时需AS SYSDBA），和角色无关；DBA角色用户无法执行STARTUP、RECOVER等底层操作
生产环境应用账号的真实权限需求远小于DBA
绝大多数 Web/API 应用只需要：
-
CREATE SESSION（建立连接） -
SELECT/INSERT/UPDATE/DELETE在指定 Schema 下的特定表（对象权限） - 可能需要
SELECT几个关键数据字典视图（如ALL_TAB_COLUMNS）用于 ORM 元数据发现 - 极少数场景要
EXECUTE预定义存储过程（应通过GRANT EXECUTE ON pkg_name TO app_user显式授予）
用 GRANT DBA TO app_user 实现这些，就像为开自行车配了一架战斗机——冗余权限本身就是攻击面。等保 2.0 和 PCI DSS 都明确要求“最小权限原则”，审计时直接被标为高风险项。
金仓等兼容库迁移时更易暴露问题
Oracle 迁移到金仓数据库时，GRANT DBA TO 的惯性操作会引发连锁失效：
- 金仓 Oracle 兼容模式下，
DBA角色不自动继承SELECT_CATALOG_ROLE，跨 Schema 同义词（CREATE SYNONYM）背后依赖断裂，报ERROR: permission denied to create table或 “表或视图不存在” - 角色嵌套超过 2 层时（如
APP_USER → READ_ONLY_ROLE → SELECT_ANY_DICTIONARY），金仓不传递系统权限，导致CREATE SESSION失效，连接直接拒绝 - 金仓默认不开放任何隐含权限，
DBA角色需手动补UNLIMITED TABLESPACE才能建对象，否则首次 DDL 就卡住
真正麻烦的不是授不授得了，而是授了之后权限链在不同环境里表现不一致——线上稳如狗，压测崩成渣，这种隐性落差最耗排查时间。
