VPD策略函数必须返回VARCHAR2类型的合法WHERE条件字符串；需先创建应用上下文并赋值，否则过滤失效；sec_relevant_cols参数启用列级掩码（12c+），object_type应为'TABLE'且object_schema须写真实属主。
VPD 策略函数必须返回 VARCHAR2 类型的 WHERE 条件字符串
oracle 的 dbms_rls 包依赖策略函数动态拼接 sql 过滤条件，这个函数不能返回布尔值、数字或 null —— 必须是合法的 sql 片段（如 'dept_id = sys_context(''hr_ctx'', ''dept_id'')'），且最终会被拼进查询的 where 子句里。返回空字符串或仅空格，会导致全表可见；返回无效语法（比如漏引号、多逗号）则在首次访问时抛 ora-28113: policy predicate has error。
- 策略函数里避免用
SELECT ... INTO查询用户属性，优先用SYS_CONTEXT获取应用上下文，减少解析开销 - 不要在策略函数中调用 PL/SQL 包过程或写日志——它可能被反复执行，影响性能
- 测试时用
EXPLAIN PLAN查看实际执行计划，确认 VPD 条件是否被下推到基表扫描层
添加策略前必须先创建应用上下文并赋值
VPD 本身不管理用户身份，它只读取上下文（CONTEXT）。如果你跳过这步，策略函数里调用 SYS_CONTEXT('HR_CTX', 'dept_id') 永远返回 NULL，结果就是过滤条件失效，用户看到全部数据。
- 先执行
CREATE CONTEXT HR_CTX USING hr.ctx_pkg;，再创建包hr.ctx_pkg提供set_dept过程 - 应用登录后必须显式调用
hr.ctx_pkg.set_dept(10)，否则上下文为空 —— Web 应用常在这里漏掉初始化 - 上下文名称（如
HR_CTX）区分大小写，策略函数里写的名称必须完全一致，否则静默失败
DBMS_RLS.ADD_POLICY 的 sec_relevant_cols 参数会触发 FGA 式列级过滤
当设置 sec_relevant_cols => 'SALARY,SSN'，Oracle 不仅做行过滤，还会对指定列自动加掩码：非授权用户查出来是 NULL（即使策略函数没限制行）。这不是 VPD 默认行为，而是开启“列级敏感控制”的开关，且要求 policy_function 返回的条件中不能包含这些列的显式过滤逻辑，否则冲突。
- 该参数启用后，
SELECT *和SELECT SALARY都会把SALARY返回为 NULL，除非用户在策略中被明确授权访问 - 和普通 VPD 策略不同，这种模式下无法用
UPDATE绕过 —— 列值在查询层就被截断了 - 注意兼容性：
sec_relevant_cols在 Oracle 12c 及以后才支持完整列掩码，11g 只能配合sec_relevant_cols_opt做简单隐藏
策略作用范围容易误配：对象类型选错导致策略不生效
object_type 参数不是指表名类型，而是指策略挂载的目标对象种类。填 'TABLE' 行得通，但填 'VIEW' 或 'SYNONYM' 就可能失效 —— 因为 VPD 策略只绑定到基表（base table），视图或同义词上加策略不会自动透传。
- 如果业务走的是视图
emp_vw，策略必须加在底层表employees上，而不是emp_vw -
object_schema必须写真实属主，比如表属于HR，就不能写成current_schema或省略 - 策略默认对
SELECT/INSERT/UPDATE/DELETE全部生效，如只需控制查询，务必显式设statement_types => 'SELECT'，否则 DML 可能意外被拦截
真正麻烦的不是写策略，而是验证它是否在所有访问路径下都生效 —— 比如通过 DB Link、物化视图日志、或者 APEX 的内置查询引擎，VPD 策略可能被绕过或延迟应用。
