静态策略。
有时业务操作可以确保谓词更加静态。例如,在上下文敏感的策略类型示例中,我们将用户所见的最大余额定义为一个变量。当 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 中对谓词进行高速缓存,并在会话中重用该谓词,而不必重新执行策略函数。策略函数类似于以下形式:
|
而策略定义为:
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 中,各行如下所示:
|
不允许 Michelle 查看余额超过 1600 的帐户。当她执行类似以下的查询时:
select * from accounts;
|
acctno 2 的余额超过 1600,它已禁止显示。对于 Michelle 而言,表中只有两行,而不是三行。当她执行类似以下的查询时:
select count(*) from accounts;
该查询只计算表中的记录数,输出是二,而不是三。
| 广告合作:400-664-0084 全国热线:400-664-0084 Copyright 2010 - 2017 www.my8848.com 珠峰网 粤ICP备15066211号 珠峰网 版权所有 All Rights Reserved
|