有关Oracle中虚拟专用数据库的虚拟(2)

在另一个示例中，我们有一个称为 ACCOUNTS 的表，它拥有几列，其中一列是 BALANCE，表示帐户余额。假设允许某个用户查看低于某特定余额的帐户，而该余额由应用程序上下文所决定。我们并不在策略函数中将此余额值固定，而是3是根据应用程序上下文确定，如： UM!V37B  
MRa9?"T'  
aJ=Elwg5qN  
　　create or replace vpd_pol_func {pK4 'Gu  
　　( yWb fc<-  
　　p_schema in varchar2, .I:C1m-'
g  
　　p_table in varchar2 }(BhO\8O  
　　) 8)>-4Dt%  
　　return varchar2 xIAEVm+m  
　　is YD+`#Jv  
　　begin ;vZ Ee B  
　　return 'balance < sys_context(''vpdctx'', ''maxbal'')'; 6RQIzJG\E  
　　end; s'9
[v[  
yBqVE
e:  
)>_7P  
　　 ;M{#t<!?  
应用程序上下文 VPDCTX 的属性 MAXBAL 可以在会话的前期设定，而函数在运行时可以容易地获得该数值。 &_*7CAE  
l $
jy*r8  
请仔细注意该示例。谓词有两部分：小于号之前的部分和之后的部分。之前的部分是“balance”一词，它是文字符。后面的部分从某种程度而言是静态的，因为应用程序上下文变量在改变之前一直是常量。如果应用程序上下文属性不变，则整个谓词是常量，因此不需要重新执行函数。如果策略类型定义为对上下文敏感，则 Oracle 数据库 10g 可以识别此情况以用于优化。如果在会话期间没有发生会话上下文的变化，则不重新执行该函数，从而显著提高了性能。 zK>X^
 
vd,roR'  
静态策略 C V1>I 3  
g~\ C<n  
有时业务操作可以确保谓词更加静态。例如，在上下文敏感的策略类型示例中，我们将用户所见的最大余额定义为一个变量。当 web 应用程序中的 Oracle userid 由许多 web 用户共享，并且应用程序基于这些用户的权限来设置该变量（应用程序上下文）时，这种方法很有用。因此，web 用户 TAO 和 KARTHIK 都是以用户 APPUSER 连接到数据库的，二者可以在其会话中拥有两个不同的应用程序上下文的值。此时 MAXBAL 的值并不依赖于 Oracle userid，而是依赖 TAO 和 KARTHIK 各自的会话。 |Hr&{i0F!  
xX%I%P6U  
在静态策略的情况下，谓词更具有可预测性，其说明如下。 v/:!v>9=1h  
z0Px@Y:D  
LORA 和 MICHELLE 分别是 Acme Bearings 和 Goldtone Bearings 的帐户管理员。当他们连接数据库时，他们使用自己的 id，并且只应该看到属于他们的那些行。在 Lora 方面，谓词变成 where CUST_NAME = 'ACME'；而对于 Michelle，则是 where CUST_NAME = 'GOLDTONE'。在这里，谓词依赖于他们的 userid，因此他们所创建的任何会话在应用程序上下文中始终具有相同的值。 d5AfZytJz  
zY&vtOj  
10g 可以利用这种情况，在 SGA 中对谓词进行高速缓存，并在会话中重用该谓词，而不必重新执行策略函数。策略函数类似于以下形式： /vhDqG#.]L  
?m#;]&qvhj  
q.kq &=  
　　 thq5`a*  
　　create or replace vpd_pol_func BsTgT(&x  
　　( sTDVN+3t:  
　　p_schema in varchar2, vn$PK{"~F~  
　　p_table in varchar2 w3!U :"u  
　　) , `A5.  
　　return varchar2 gK Z  
　　is Z<=>So F=  
　　begin IAhW NdW1  
　　return 'cust_name = sys_context(''vpdctx'', ''cust_name'')'; HBhtf-(vM  
　　end; k ks#FJA  
60+r q![  
z2U$Ch  
　　 ? YA88<  
而策略定义为： VZ f;  
x?RFX#Y  
policy_type => dbms_rls.static LP
saigf  
iq@40tey  
这种方法确保策略函数只执行一次。即使应用程序上下文在会话中改变，也从不重新执行该函数，使得此过程的速度非常快。 6Qle#T<9  
cQB->h  
建议将静态策略用于在几个用户中托管应用程序的情况。在这种情况下，单个数据库拥有几个用户的数据。当每个用户登录时，登录后触发器可以设置用于策略函数的应用程序上下文的值，以便快速生成谓词。 A[pT'gD+  
mw.% d  
但是，将策略定义为静态也是一把双刃剑。在以上的示例中，我们假设应用程序上下文属性 VPDCTX.CUST_NAME 的值在会话中不改变。如果这种假设不正确，将会怎样呢？如果该值改变，策略函数将不会执行，因此在谓词中将不会使用新值，而返回错误的结果！因此，在将策略定义为静态时要非常小心；您必须绝对确信该值不会改变。如果您不能作这种假设，则最好将策略定义为对上下文敏感。