VPD策略函数返回值必须是合法SQL布尔表达式，需显式转换上下文值、避免空值、禁用隐式转换；SEC_RELEVANT_COLS在VPD后执行，不可依赖被掩码列；context须每次查询前刷新；策略函数严禁查表或调用非DETERMINISTIC函数。
VPD 策略里怎么写 WHERE 条件才真正生效
vpd（virtual private database）策略函数返回的 where 字符串，不是 sql 拼接模板，而是被 oracle 自动注入到查询谓词中的动态过滤条件。很多人写成 'user_id = ' || sys_context('my_ctx', 'current_user_id')，结果发现没过滤、报错或漏数据。
关键点：返回值必须是合法的 SQL 布尔表达式，且不能含外部绑定变量；所有上下文值必须先用 sys_context() 取出并显式转类型，否则隐式转换可能失败或绕过索引。
- 必须用单引号包裹字符串字面量，比如
'status = ''active'''（注意两个单引号转义） - 数值型上下文要显式
TO_NUMBER(sys_context(...))，避免字符比较导致全表扫描 - 不要返回空字符串或
NULL，Oracle 会跳过该策略——想“无过滤”得返回'1=1' - 如果依赖多个上下文项（如租户+角色），用
AND连接，别用逗号或换行
SEC_RELEVANT_COLS 和 VPD 同时用会互相干扰吗
会。当你在 ADD_POLICY 里设了 sec_relevant_cols 参数（比如 'dept_id, salary'），Oracle 会在 SELECT 中自动把未授权列置为 NULL，但这个动作发生在 VPD 过滤之后。也就是说：VPD 先筛行，SEC_RELEVANT_COLS 再抹列——顺序固定，不可调换。
常见踩坑：用户看到一堆 NULL，以为是 VPD 没生效，其实是列级控制把数据藏了。更麻烦的是，如果 VPD 策略本身依赖这些被掩码的列（比如用 salary > 10000 做过滤），那策略会失效——因为此时 salary 已被置为 NULL，条件恒假。
- 只在确实需要列级脱敏时才启用
SEC_RELEVANT_COLS，多数场景靠 VPD 行级过滤就够了 - 若必须共用，确保 VPD 策略不引用任何被
SEC_RELEVANT_COLS掩码的列 - 调试时用
DBMS_RLS.SHOW_POLICY查看策略实际挂载状态，比看代码更可靠
Context 变量怎么保证每次查询都实时刷新
Oracle 的 sys_context('namespace', 'attribute') 读的是当前会话的 context 值，但它不会自动感知应用层变化。常见问题是：用户 A 登录后 context 设为 'user_id'='101'，后续切换到用户 B，但忘记重设 context，导致 VPD 仍按 101 过滤。
根本原因在于 context 是会话级的，不是事务级或语句级。所以不能靠“一次设置、长期有效”，而必须在每次业务逻辑入口处显式刷新。
- 在应用连接池获取连接后、执行业务 SQL 前，立刻执行
DBMS_SESSION.SET_CONTEXT - 避免在存储过程中用
DBMS_SESSION.SET_CONTEXT后直接查表——除非你确认该过程在新会话中运行 - 测试时用
SELECT sys_context('my_ctx', 'user_id') FROM DUAL手动验证，别只信日志输出 - 如果用连接池（如 UCP、Hikari），务必配置
connectionInitSql或自定义ConnectionCustomizer来初始化 context
VPD 策略函数里能调用 PL/SQL 包或查表吗
能，但非常危险。Oracle 要求策略函数必须是「纯读」且「无副作用」的，一旦函数里出现 DML、DDL、自治事务、甚至某些系统包调用（如 UTL_HTTP），就会报 ORA-28113: policy predicate has error。
更隐蔽的问题是性能：策略函数在每条 SQL 执行前都会调用，如果它内部查了一张大表或做了复杂计算，整个查询延迟会指数上升——而且无法走索引，因为 Oracle 把它当黑盒处理。
- 策略函数体应控制在 10 行以内，只做 context 取值 + 简单拼接
- 绝对不要在策略函数里调用自定义 PL/SQL 函数，除非该函数标有
DETERMINISTIC且不含任何上下文依赖 - 如果真需要动态查配置（比如从
user_permissions表取权限规则），提前把结果缓存到 context 中，策略函数只读 context - 上线前用
EXPLAIN PLAN对比加策略前后的执行计划，重点看是否多了FILTER步骤和全表扫描
最常被忽略的一点：VPD 不会自动处理 INSERT/UPDATE/DELETE 的行级校验。你写了 SELECT 策略，不代表用户不能 INSERT 一条属于别人的数据——除非你额外为 DML 定义策略，且逻辑要和 SELECT 严格对称。这事容易拖到上线后才发现。
