dba 是数据字典中真实存在的角色，可查、可授、可撤；sysdba 是登录身份标识，不存于数据字典，依赖密码文件，权限独立于数据库状态，且以它登录时会话用户恒为 sys。
dba 是一个真实存在的 role，sysdba 不是 role，也不是权限集合，而是一种登录身份标识 —— 它不存于数据字典，不走授权视图，也不依赖数据库是否已打开。
DBA 角色能查到、能授、能撤
DBA 是 Oracle 数据字典里明确定义的 Role，跟普通用户一样物理存在：
-
SELECT * FROM DBA_ROLES WHERE ROLE = 'DBA'能查出结果 -
GRANT DBA TO scott之后，DBA_ROLE_PRIVS视图中立刻出现记录 -
REVOKE DBA FROM scott后该记录消失，权限即时失效 - 它只在数据库正常打开、数据字典可用时才起作用 —— 实例启动但数据库未 MOUNT 时，DBA 角色根本不可用
SYSDBA 权限查不到、授不了、撤不掉（靠密码文件）
SYSDBA 不是 Role，所以：
-
SELECT * FROM DBA_ROLES WHERE ROLE = 'SYSDBA'返回零行 -
DBA_ROLE_PRIVS里永远找不到 SYSDBA 相关记录 -
GRANT SYSDBA TO scott实际只是把scott写入 Oracle 密码文件（orapw$ORACLE_SID），不是写进数据字典 - 撤销必须用
REVOKE SYSDBA FROM scott，且需重启实例或刷新密码文件才能生效；若密码文件损坏或丢失，即使用户存在，SYSDBA 也失效 - 数据库处于 NOMOUNT 状态时，
CONN / AS SYSDBA仍可连接并执行STARTUP MOUNT—— 这正是它和 DBA 的分水岭
以 SYSDBA 登录后，你根本不是你自己
无论用哪个用户名加 AS SYSDBA 登录，实际会话用户都是 SYS：
-
CONN scott/tiger AS SYSDBA→SHOW USER显示USER is "SYS" - 所有创建的对象默认归属
SYS模式，不是scott模式 - 执行
SELECT * FROM V$PWFILE_USERS才能看到哪些用户被允许以 SYSDBA 身份登录 - 而
CONN scott/tiger（无 AS SYSDBA）才是真正的scott用户上下文，哪怕他已被授予 DBA 角色
DBA 做不了的事，SYSDBA 才能碰
DBA 角色无法触及数据库生命周期底层操作：
-
STARTUP/SHUTDOWN IMMEDIATE：DBA 用户执行报ORA-01031: insufficient privileges -
CREATE DATABASE或DROP DATABASE：仅 SYSDBA 允许 -
ALTER DATABASE ARCHIVELOG：DBA 无权执行 -
RESTORE DATABASE或RECOVER DATABASE：DBA 可以做表级恢复，但不能做库级恢复 - 甚至
CREATE SPFILE FROM PFILE：DBA 用户会提示权限不足，SYSDBA 才行
真正容易被忽略的是：SYSDBA 的有效性完全独立于数据库状态，而 DBA 的一切能力都建立在数据库已 OPEN 的前提上。很多运维事故源于混淆了“能连上”和“能干活”——CONN / AS SYSDBA 成功不代表 SELECT * FROM DBA_TABLES 就能跑通，反之亦然。
