数据库保险库（Database Vault）在Oracle 19c中通过内核级策略引擎实时阻断未授权访问，即使SYS/DBA用户也无法绕过Realm隔离直接操作敏感数据，实现真正的超级用户权限隔离。
什么是数据库保险库（Database Vault）在 Oracle 19c 中的实际作用
数据库保险库不是给 dba 加个密码，而是从根本上阻止 system、sys 甚至拥有 dba 角色的用户绕过应用逻辑直接删表、改数据。它通过策略引擎在内核层拦截操作，即使你用 sqlplus / as sysdba 登录，只要没被显式授权进某个“域（realm）”，照样查不了敏感表。
关键点在于：它不依赖应用层控制，也不靠审计日志事后追责，而是实时阻断——这才是真正意义上的超级用户权限隔离。
启用 Database Vault 前必须确认的 3 个前提条件
Oracle 19c 默认不启用 Database Vault，且不能在已运行的 CDB 中动态开启。常见失败都源于这三点没检查：
- 数据库必须是企业版（Standard Edition 不支持），执行
SELECT * FROM v$version;确认版本字符串含Enterprise Edition - 必须使用独立的
DVOWNER和DVACLSADM管理账户（不能复用SYS或SYSTEM），且这两个用户需在创建数据库时或使用catdv.sql脚本初始化后存在 - CDB 级别启用前，所有 PDB 必须处于
MOUNTED状态；若用 DBCA 创建数据库，勾选 “Configure Enterprise Manager and Database Vault” 才会自动配置底层组件
创建 Realm 隔离敏感对象的典型步骤
Realm 是 Database Vault 的核心隔离单元。比如你要保护 HR.EMPLOYEES 表，不能只加个 ACL，得走完整策略链：
- 先用
DVSYS.DBMS_MACADM.CREATE_REALM创建 realm，例如'HR_Data_Realm'，注意enabled => FALSE初始要关着，避免误锁 - 用
DVSYS.DBMS_MACADM.ADD_OBJECT_TO_REALM加入对象，类型必须精确到'TABLE'、'VIEW'，schema 名和对象名区分大小写 - 用
DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM显式授权用户或角色，比如只允许HR_APP_USER查询，连HR_ADMIN角色默认也没权限 - 最后调
DVSYS.DBMS_MACADM.ENABLE_REALM，此时任何未授权访问都会报错ORA-47401: Realm violation for object HR.EMPLOYEES
为什么 DBA 还能绕过 Realm？常见配置疏漏点
很多人启用后发现 SYS 仍能删表，不是 Database Vault 失效，而是没关掉“隐式特权通道”：
-
SYS用户默认属于DV_OWNER角色，该角色有REALM AUTHORIZATION权限——这意味着它天然可进出所有 Realm。解决办法：用DVSYS.DBMS_MACADM.REMOVE_AUTH_FROM_REALM把SYS从具体 Realm 中移出，而不是依赖角色继承 - 如果开启了
Oracle Label Security，且策略与 Database Vault 冲突，可能触发静默降级。检查V$DV_STATUS视图中的OLS_ENABLED字段是否为FALSE - 使用
ALTER SYSTEM SET ENABLE_DV=TRUE SCOPE=SPFILE后必须重启实例，仅ALTER SYSTEM CHECKPOINT没用；PDB 中还需单独执行ALTER PLUGGABLE DATABASE OPEN并验证DV$REALM视图是否可见
最易被忽略的是：Database Vault 策略只对 SQL 引擎生效，对直接读取数据文件的 OS 层操作（如用 dd 拷贝 datafile）完全无感——它保护的是访问路径，不是存储本身。
