ora-28137/ora-28140表明ols策略创建失败，主因是标签格式错误或组件（level/compartment/group）未按lbacsys.sa_components包规范创建，如level非递增整数、short_name超长或含非法字符。
oracle ols 策略创建失败：ora-28137/ora-28140 是什么信号
策略创建报 ora-28137: policy not created because of invalid label 或 ora-28140: invalid label component specified，基本说明标签格式或组件定义没对上——ols 不是“建完策略就自动生效”，它依赖一套严格分层的标签结构，而很多人直接抄示例，忽略了 lbacsys.sa_components.create_level 和 create_compartment 的执行顺序与命名约束。
实操建议：
- 先确认当前策略名未被占用：
SELECT * FROM LBACSYS.SA_POLICIES WHERE POLICY_NAME = 'MY_POLICY'; - 所有组件（level / compartment / group）必须用
LBACSYS.SA_COMPONENTS包创建，不能手工 INSERT 到底层表 - level 值必须为整数且严格递增（如 10=PUBLIC，20=CONFIDENTIAL，30=SECRET），跳号或重复会触发
ORA-28140 - compartment 和 group 的
short_name只能含字母、数字、下划线，且长度 ≤ 30 字符；大小写敏感，'HR'和'hr'是两个不同 compartment
给数据行打密级标签：SA_LABEL_ADMIN.SET_LABELS 怎么用才不丢数据
SA_LABEL_ADMIN.SET_LABELS 是给表行设标签的核心函数，但它的行为和普通 UPDATE 完全不同：它不走 SQL 引擎解析，而是由 OLS 内核直接写入隐藏列 OLS$LAB，一旦参数错，轻则标签不生效，重则整行被策略过滤掉（查不到）。
常见错误现象：执行后 SELECT 看不到数据，或者 USER_SA_SESSION.LABEL 显示正常但查询结果为空。
实操建议：
- 确保目标表已启用策略：
EXEC LBACSYS.SA_POLICY_ADMIN.APPLY_TABLE_POLICY('MY_POLICY', 'SCOTT', 'EMP'); - 标签字符串必须完全匹配已定义的完整标签（如
'L2:C1,G1'），不能省略冒号、逗号或大小写——'l2:c1,g1'会被拒绝 - 批量打标别用循环调用
SET_LABELS，改用UPDATE ... SET OLS$LAB = SA_LABEL_ADMIN.LABEL_TO_CHAR('MY_POLICY', 'L2:C1,G1')（需先授权SELECT_CATALOG_ROLE） - 打标前检查用户会话标签：
SELECT * FROM USER_SA_SESSION;，如果CURRENT_LABEL低于目标行标签，UPDATE 会静默失败
用户无法访问带标签的数据：不是权限问题，是会话标签没对齐
赋予了 SA_USER_ADMIN.SET_USER_PRIVS 权限，也执行了 SA_SESSION.SET_LABEL，但用户仍查不到数据——大概率是会话的 READ_LABEL 或 WRITE_LABEL 没设对。OLS 的访问控制基于“标签支配关系”，不是简单的“有权限就能看”。
使用场景：DBA 给用户分配了 'L2:C1' 级别，但用户想查 'L2:C1,G1' 的行，就必须把 READ_LABEL 设为至少 'L2:C1,G1'（或更高支配标签）。
实操建议：
- 用
SA_SESSION.SET_LABEL设置时，策略名必须全大写，标签字符串大小写敏感：EXEC SA_SESSION.SET_LABEL('MY_POLICY', 'L2:C1,G1'); - 不要只设
SET_LABEL，务必同步设读写标签：EXEC SA_SESSION.SET_READ_LABEL('MY_POLICY', 'L2:C1,G1');和EXEC SA_SESSION.SET_WRITE_LABEL('MY_POLICY', 'L2:C1,G1'); - 验证会话标签：
SELECT * FROM USER_SA_SESSION;，重点看READ_LABEL是否 ≥ 目标行标签（支配关系：level≥、compartment⊇、group⊇） - 临时调试可降级会话标签：
EXEC SA_SESSION.SET_LABEL('MY_POLICY', 'L1');，再查是否能看到低密级数据，快速定位是否标签越界
策略启用后性能明显下降：隐藏列 OLS$LAB 和索引缺失是主因
OLS 启用后查询变慢，尤其是大表 JOIN 或 WHERE 过滤，不是策略本身慢，而是 Oracle 在执行计划里多加了一层标签匹配谓词，并且默认不为 OLS$LAB 隐藏列建索引。
性能影响点：每次查询都要对每行计算标签支配关系，若没索引加速，全表扫描 + 标签比对开销陡增。
实操建议：
- 对高频查询字段+标签组合建函数索引：
CREATE INDEX idx_emp_dept_lab ON scott.emp (deptno, SYS.OLS_FUNCT_PKG.READ_LABEL('MY_POLICY', OLS$LAB)); - 避免在 WHERE 中用
SA_LABEL_ADMIN.LABEL_TO_CHAR转换比较，改用原生标签值或绑定变量 - 监控真实执行计划：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR);，留意是否出现access("OLS$LAB" IS NOT NULL)类似谓词，这是 OLS 插入的隐式过滤 - OLTP 场景慎用 group 层级，group 支配判断比 level/compartment 更耗 CPU，尤其 group 数量 > 5 时
标签打标不是开关一按就完事，每个组件创建顺序、每个标签字符串的大小写和分隔符、每个会话的三个标签值（current/read/write）、每张表的隐藏列索引——漏掉任何一环，数据就可能“消失”或“慢得离谱”。最常被忽略的是 READ_LABEL 和 WRITE_LABEL 没同步设置，以及用小写标签字符串调用 SET_LABELS。
