Oracle默认禁止非SYS用户修改数据字典基表，本质是权限控制+只读视图封装，并非物理锁定；ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=FALSE是基础防线，设为FALSE后非SYS用户即使有SELECT ANY TABLE也无法访问sys.obj$等基表，需重启生效且生产环境严禁设为TRUE。
Oracle 默认禁止任何非 SYS 用户（包括 DBA 角色成员）直接修改数据字典基表，但这个“禁止”本质是靠权限控制+只读视图封装实现的，并非底层物理锁定。真要防住误操作，光靠默认机制远远不够——尤其当有人用 SYS 或 SYSDBA 登录后执行 UPDATE、DELETE 甚至 DROP，系统不会拦，只会按权限放行。
为什么 ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=FALSE 是基础防线
这个参数决定普通 DBA 是否能绕过数据字典视图、直连底层基表（如 obj$、tab$）。设为 FALSE 后，即使用户有 SELECT ANY TABLE，查询 sys.obj$ 也会报 ORA-00942: table or view does not exist。
- 必须在数据库启动前设置，且需重启生效：
ALTER SYSTEM SET O7_DICTIONARY_ACCESSIBILITY=FALSE SCOPE=SPFILE; -
TRUE是 Oracle 7 兼容模式，默认仅在极老版本或迁移遗留场景启用，生产环境严禁保留 - 注意：该参数不影响
SYS用户本身，它只限制其他用户对SYS模式下基表的访问路径
如何确认当前数据字典保护是否真正生效
不能只看参数值，得实测访问行为。用一个带 DBA 角色但非 SYS 的账号执行：
SELECT COUNT(*) FROM sys.tab$;
如果返回 ORA-00942，说明保护起效；若返回数字，说明要么参数没生效，要么账号实际是 SYS 或用了 AS SYSDBA 连接。
- 检查连接方式：
SELECT SYS_CONTEXT('USERENV', 'SESSION_USER') FROM DUAL;看是否真是SYS - 查当前会话权限：
SELECT * FROM SESSION_ROLES WHERE ROLE = 'DBA'; - 确认参数已加载：
SHOW PARAMETER O7_DICTIONARY_ACCESSIBILITY
DBA 用户仍能删改字典视图？那是权限设计问题
数据字典“视图”（如 DBA_TABLES、ALL_OBJECTS）本身是只读的，但它们依赖的底层基表（tab$、obj$）才是关键。DBA 用户删不了 DBA_TABLES，但若拥有 UPDATE ANY TABLE 且 O7_DICTIONARY_ACCESSIBILITY=TRUE，就可能更新 sys.tab$ —— 这会导致元数据错乱，数据库无法启动。
- 立即回收高危权限：
REVOKE UPDATE ANY TABLE FROM dba_user; - 禁止授予
SELECT ANY DICTIONARY给非审计/运维专用账号（它等价于可读所有sys.对象） - 生产库中，
DBA角色应仅赋予必要人员，且日常维护尽量用普通账号+GRANT ... WITH ADMIN OPTION按需临时授权
Database Vault 能否彻底锁死字典修改
不能。Oracle Database Vault 主要管控应用数据和业务 Schema，对 SYS 模式下的核心字典表无直接保护能力。它的规则引擎不拦截 SYS 用户发起的 DML，也不覆盖数据字典自身的访问控制逻辑。
真正能加固的点是：用 Database Vault 创建“禁止修改 SYS 模式下指定对象”的命令规则（Command Rule），但前提是该规则绑定到 SYS 用户本身——而 SYS 用户默认绕过所有 Vault 规则。所以实践中，Vault 更适合封堵 DBA 对业务表的越权访问，而非替代 O7_DICTIONARY_ACCESSIBILITY。
最易被忽略的是：很多人以为设了 O7_DICTIONARY_ACCESSIBILITY=FALSE 就一劳永逸，却忘了检查是否还有账号以 SYS AS SYSDBA 长期登录并执行 DDL/DML。这种连接方式下，任何字典保护形同虚设。
