忽略掉 where 子句，谓词就具有两个不同的部分：在等式操作符之前的部分 (am_name) 和等式操作符之后的部分 ('SCOTT')。在大多数情况下，后面的部分更象是变量，因为它是由用户的数据提供的（如果用户是 SCOTT，则其值为 'SCOTT'）。在等号前面的部分是静态的。因此，即使函数不必为生成适当的谓词而对每行求出策略函数的值，由于了解前面部分的静态性以及后面部分的动态性，也可以提高性能。在 10g 中，可以在 dbms_rls.add_policy 调用中使用 "context_sensitive" 类型的策略作为参数来实现这种方法：
policy_type => dbms_rls.context_sensitive
在另一个示例中，我们有一个称为 ACCOUNTS 的表，它拥有几列，其中一列是 BALANCE，表示帐户余额。假设允许某个用户查看低于某特定余额的帐户，而该余额由应用程序上下文所决定。我们并不在策略函数中将此余额值固定，而是3是根据应用程序上下文确定，如：
create or replace vpd_pol_func
(
p_schema in varchar2,
p_table in varchar2
)
return varchar2
is
begin
return 'balance < sys_context(''vpdctx'', ''maxbal'')';
end;
应用程序上下文 VPDCTX 的属性 MAXBAL 可以在会话的前期设定，而函数在运行时可以容易地获得该数值。
请仔细注意该示例。谓词有两部分：小于号之前的部分和之后的部分。之前的部分是“balance”一词，它是文字符。后面的部分从某种程度而言是静态的，因为应用程序上下文变量在改变之前一直是常量。如果应用程序上下文属性不变，则整个谓词是常量，因此不需要重新执行函数。如果策略类型定义为对上下文敏感，则 Oracle 数据库 10g 可以识别此情况以用于优化。如果在会话期间没有发生会话上下文的变化，则不重新执行该函数，从而显著提高了性能。
静态策略。 有时业务操作可以确保谓词更加静态。例如，在上下文敏感的策略类型示例中，我们将用户所见的最大余额定义为一个变量。当 web 应用程序中的 Oracle userid 由许多 web 用户共享，并且应用程序基于这些用户的权限来设置该变量（应用程序上下文）时，这种方法很有用。因此，web 用户 TAO 和 KARTHIK 都是以用户 APPUSER 连接到数据库的，二者可以在其会话中拥有两个不同的应用程序上下文的值。此时 MAXBAL 的值并不依赖于 Oracle userid，而是依赖 TAO 和 KARTHIK 各自的会话。
在静态策略的情况下，谓词更具有可预测性，其说明如下。
LORA 和 MICHELLE 分别是 Acme Bearings 和 Goldtone Bearings 的帐户管理员。当他们连接数据库时，他们使用自己的 id，并且只应该看到属于他们的那些行。在 Lora 方面，谓词变成 where CUST_NAME = 'ACME'；而对于 Michelle，则是 where CUST_NAME = 'GOLDTONE'。在这里，谓词依赖于他们的 userid，因此他们所创建的任何会话在应用程序上下文中始终具有相同的值。
10g 可以利用这种情况，在 SGA 中对谓词进行高速缓存，并在会话中重用该谓词，而不必重新执行策略函数。策略函数类似于以下形式：
create or replace vpd_pol_func
(
p_schema in varchar2,
p_table in varchar2
)
return varchar2
is
begin
return 'cust_name = sys_context(''vpdctx'', ''cust_name'')';
end;
而策略定义为：
policy_type => dbms_rls.static
这种方法确保策略函数只执行一次。即使应用程序上下文在会话中改变，也从不重新执行该函数，使得此过程的速度非常快。
建议将静态策略用于在几个用户中托管应用程序的情况。在这种情况下，单个数据库拥有几个用户的数据。当每个用户登录时，登录后触发器可以设置用于策略函数的应用程序上下文的值，以便快速生成谓词。
但是，将策略定义为静态也是一把双刃剑。在以上的示例中，我们假设应用程序上下文属性 VPDCTX.CUST_NAME 的值在会话中不改变。如果这种假设不正确，将会怎样呢？如果该值改变，策略函数将不会执行，因此在谓词中将不会使用新值，而返回错误的结果！因此，在将策略定义为静态时要非常小心；您必须绝对确信该值不会改变。如果您不能作这种假设，则最好将策略定义为对上下文敏感。
共享策略类型。 为了重用代码并最大限度地利用已经分析过的代码，您可以决定为几个表使用通用的策略函数。例如，在上述示例中，我们可能对于不同类型的帐户拥有不同的表 — SAVINGS 和 CHECKING — 但是规则仍然是相同的：限制用户查看余额超过其授权范围的帐户。这种情况要求为 CHECKING 和 SAVINGS 表上的策略使用统一的函数。该策略创建为 context_sensitive。
假设事件按如下顺序发生：
1. 连接会话
2. 设置应用程序上下文
3. select * from savings;
4. select * from checking;
即使应用程序上下文在第 3 步与第 4 步之间没有改变，策略函数也会重新执行，因为现在所选择的表已经不同。这不是我们所希望的情况，因为策略函数相同，不需要重新执行该函数。
10g 中的新功能是能够在对象间共享策略。在上述示例中，您可以将这些策略的策略类型定义为：
policy_type => dbms_rls.shared_context_sensitive
将策略声明为 "shared" 可以在以上所示的情况中不再执行该函数，从而提高了性能。
选择性的列
现在设想一种情况，只有在选择了特定列时才会应用 VPD 策略。在上述示例的表 ACCOUNTS 中，各行如下所示：
ACCTNO ACCT_NAME BALANCE
------ ------------ -------
1 BILL CAMP 1000
2 TOM CONNOPHY 2000
3 ISRAEL D 1500
不允许 Michelle 查看余额超过 1600 的帐户。当她执行类似以下的查询时：
select * from accounts;
她将看到：
ACCTNO ACCT_NAME BALANCE
------ ------------ -------
1 BILL CAMP 1000
3 ISRAEL D 1500
acctno 2 的余额超过 1600，它已禁止显示。对于 Michelle 而言，表中只有两行，而不是三行。当她执行类似以下的查询时：
select count(*) from accounts;
该查询只计算表中的记录数，输出是二，而不是三。
但是，此时我们可以决定将安全策略稍微放松一些。在本查询中，Michelle 不能查看帐户余额等秘密数据；她只是计算表中所有记录的数目。在与安全策略一致的情况下，我们可以允许此查询计算所有记录的数目，无论是否允许她查看这些记录。如果需要这样，则在对 10g 的 dbms_rls.add_policy 的调用中的另一个参数允许实现此功能：
sec_relevant_cols => 'BALANCE'
现在，当用户选择列 BALANCE 时，无论是显式选择还是隐含在 select * 中，VPD 策略都会介入，对行作出限制。否则将会选择表中所有的行，因为在查询中用户只选择了总计行数，而没有选择列 BALANCE。如果将以上参数设置为所示的形式，则查询
select count(*) from accounts;
将显示三列，而不是两列。但是查询：
select * from accounts;
仍将只返回两条记录，与预期的情况相同。
列屏蔽
现在，让我们对当前的示例再增加些要求。我们不禁止显示那些余额高于阈值的行，而是希望显示所有的行，同时屏蔽那些数值超过阈值的余额列。与安全性相关的列仍然是 BALANCE。
不允许 Michelle 看到余额超过 1600 的帐户。当她执行类似以下的查询时：
select * from accounts;
她将只看到两行，acctnos 1 和 3。但是，我们可能希望她看到：
ACCTNO ACCT_NAME BALANCE
------ ------------ -------
1 BILL CAMP 1000
2 TOM CONNOPHY <null>
3 ISRAEL D 1500
注意，显示都所有行，但是 acctno 2 的列 BALANCE 的值显示为空（显示为 <null>），它的余额实际上是 2000，超过阈值 1600。这种方法称为“列屏蔽”，可以通过在对 dbms_rls.add_policy 的调用中指定参数来实现：
sec_relevant_cols_opt => dbms_rls.all_rows
在只有某些特定列值很重要的情况下，这种策略才可能非常有用，并且不需要复杂的自定义代码。它也是一种很好的变通方法，不需要对存储数据进行加密。
结论
在 Oracle 数据库 10g 中，VPD 已经发展为一种功能非常强大的特性，它能够支持多种需求，例如基于策略有选择性地屏蔽列，只在访问特定列时应用策略等。利用应用程序特有的性质，还可以通过多种类型的策略来提高策略的性能，使得该特性适用于多种情况。
有关 VPD 和 dbms_rls 程序包的更多信息，请参阅 PL/SQL 程序包和类型参考的第 79 章以及 Oracle 数据库安全指南。您还可以阅读由我与 Don Burleson 合著的一本关于该主题的书籍 Oracle 保密安全性审计 (Rampant TechPress)。
下一周：自动段管理
返回系列索引
