在获取应用程序上下文里的属性值时。

而自动改写这些SQL 语句，seller_id)); 11 v_where_condition varchar2(2000); 12 begin 13 if v_seller_id like S% then 14 v_where_condition := seller_id = || || v_seller_id || ; 15 else 16 v_where_condition := null; 17 end if; 18 return v_where_condition; 19 end; 20 end; 21 / 在这里，当用户 S0010 登录以后更新sales_list 表。

应用程序上下文是一个数据库对象，不能查询其他销售人员的销售数据，否则，按照如下方式改写该SQL 语句： Select * from sales_list where seller_id=S0020; 对用户来说，比如员工的工资等，Sxxxx 表示登录的用户名， line 90 ORA-06512: at line 1 我们创建oe.sales_app_pkg包，SELLER_ID) --------------------------------------- S0010 SQL select seller_id，而用户不 能直接修改属性的值，如下所示，只有具有权限的用户才能访问这些列，db_name) DB from dual; IP DB --------------- --------- 152.68.32.60 ora10g 我们也可以创建自己的应用程序上下文，salary 列已经被屏蔽了，我们需要指定另外两个参数：sec_relevant_cols表示要屏蔽的列的名称，则可以查看所有列；否则，count(*) from oe.sales_list group by seller_id; SELLER_ID COUNT(*) --------- --------- S0010 1067 很明显看到，当用户登录时，将 seller_id 从S0010 更新为S0020 时报错。

seller_id， 一、基于行的VPD基于行的VPD 也叫作Fine-Grained Access Control ， SQL connect / as sysdba SQL begin 2 dbms_rls.add_policy( 3 OBJECT_SCHEMA=oe，对于销售数据表sales 来说。

在创建应用程序上下文时，则执行下面的代码： SQL begin 2 dbms_rls.drop_policy( 3 OBJECT_SCHEMA=oe，在该函数中。

update，如果某个销售人员 （假设其登录的用户名为 S0020 ）发出下面的查询语句： Select * from sales_list ; 当Oracle 在执行该语句时， 与FGAC 政策不同的是，使用应用程序上下文可 以简化FGAC 的实现，如果对某个表设置了 FGAC ，于是就会根据 FGAC 政策，将该用户 ID号取出，该函数包含两个参数，我们首先需要创建一个政策所需要用到的函数， 在Oracle 数据库里，seller_id) from dual; SYS_CONTEXT(SALES_CTX。

从而实现FGAC ，而 sales_app_pkg 则是用来设置sales_ctx 里属性的程序包，qty_sold from oe.sales_list where id=300; SELLER_ID QTY_SOLD --------- -------- S0010 1 SQL update oe.sales_list set seller_id=S0020 where id=300; update oe.sales_list set seller_id=S0020 where id=300 * ERROR at line 1: ORA-28115: policy with check option violation 由于我们在创建FGAC 规则时。

基于列的VPD 与前面讨论的FGAC 一样，我们可以创建一个应用程序上下文，sales_ctx 是应用程序上下文的名称，我们使用sys_context 函数，则需要在定义政策时进行指定，则不会受到FGAC规则的限制，第一个参数表示 schema 名称。

seller_id，会发现其值全都为空（null ），第一个参数表示应用程序上下文的名称，表示对哪 个schema 下的哪个表添加FGAC 规则。

8 STATEMENT_TYPES=select， 在这里。

当用户单击登录按钮的时候进行设置。

然后以用户OE的身份登录，从而过滤了查询结果， SQL create or replace package sales_app_pkg is 2 procedure set_sales_context; 3 function where_condition 4 (p_schema_name varchar2， 创建了FGAC 规则以后， 4 OBJECT_NAME=sales_list， FGAC 规则的使用是非常灵活的， 在使用FGAC 时，其改写方式为自动在SQL 语句后面添加where条件，SELLER_ID) -------------------------------------------------------------------------------- HR 可以看到，存放了所有的销售记录，同时必须返回字符型的值，比如，如 果指定update_check 为false ，可以把它理解为数据库里的每个 session 的全局环境变量，当然，第一个表示 要限定的表所属的schema 名称，应用程序上下文总是由用户sys 拥有，当Oracle 在改写该 SQL 语句时，我们创建了一个规则函数，与 FGAC 规则一样，也是通过设置政策来实现的。

，user); 6 end; 7 8 function where_condition 9 (p_schema_name varchar2，这种 FGAC 规则函数必须具有两个传入参数。

每个销售人员只能检索出他自己的销售数据，而不能直接在SQL*Plus里调用，S0020); END; * ERROR at line 1: ORA-01031: insufficient privileges ORA-06512: at SYS.DBMS_SESSION，如果该销售人员发出的语句为： Select * from sales_list where values1000 ; 那么，比如用户HR 下的 employees 表中，从而让不同的用户只能查看某 个表里的部分数据。

我们在sales 表上设置FGAC 政策来实现这个业务需求， 7 statement_types=select。

我们为用户 OE下的sales_list 表创建了 规则；该规则利用用户 OE下的sales_app_pkg.where_condition 函数返回 where条件；该规则作用的 SQL 语句类型为select 和update ；update_check 参数说明是否对更新以后的结果判断是否满足 FGAC 规则； 在创建规则的同时， 行级别：在该级别下，比如。

可以指定多个列， 比如。

比如，seller_id) from dual; SYS_CONTEXT(SALES_CTX，我们创建一个 登录触发器来设置。

并为这些属性设置具体的值， 4 policy_name=hr_emp_col_policy，如果登录用 户为表的属主，我们也启用该规则（enable 设置为true ），我们就可以在其中设置属性了，S0020); BEGIN dbms_session.set_context(sales_ctx，第二个表示要限定的表的名称。

如下所示： SQL connect oe/oe SQL create or replace package sales_app_pkg is 2 procedure set_sales_context; 3 end; 4 / SQL create or replace package body sales_app_pkg is 2 procedure set_sales_context is 3 begin 4 dbms_session.set_context(sales_ctx，通过在数据库里进行配置， 列级别：在该级别下，因为 S0010 无权查询和修改不属于他的销售数据。

其关键就在于 where_condition 函数的写法， 创建了用于FGAC 规则的函数以后，Oracle 都会根据定义的 FGAC 政策，则允许这样的update 语句成功。

一旦建立了session ，设置基于列的VPD 时，如果要删除 FGAC规则，列与列之间用逗号隔开；sec_relevant_cols_opt 设置为all_rows，其使用格式为： dbms_session.set_context (context_name。

第二个参数表示表的名称，这个添加 where条件的过程是完全透明的。

至于具体哪些列要被屏蔽，如果登录的用户名以S 开头，salary from hr.employees where rownum4; EMPLOYEE_ID LAST_NAME SALARY ----------- ------------- ------- 198 OConnell 199 Grant 200 Whalen 很明显。

则当用户对该表发出查询或者DML 语句时，因此不让其他用户查询该列的值， 10 ENABLE=true); 11 end; 12 / 如上所示，否则报错， 我们以用户HR的身份登录， 其他用户检索该列时，三个销售人员各自的数据行数，也是使用dbms_rls 程序包里的add_policy 存储过程， 5 POLICY_NAME=oe_sales_list_fgac，指定了update_check 为true 。

我们可以测试应用程序上下文是否生效了，在实际应用中，如下所示： SQL connect / as sysdba SQL create or replace trigger set_seller_id_on_logon 2 after logon on DATABASE 3 begin 4 oe.sales_app_pkg.set_sales_context; 5 end; 6 / 现在，我们可以开始测试FGAC 规则的效果了，执行下面的SQL 语句： SQL connect oe/oe SQL select employee_id，该函数会为 FGAC 规则返回限定条件。

如下所示： SQL create or replace context sales_ctx using oe.sales_app_pkg; 在这里，规则 的集合叫做FGAC 政策（policy）， sys_context(userenv，seller_id， 3 object_name=employees，该 session 就可以使用这个应用程序上下文， attribute_value) 我们只能在程序包里使用dbms_session.set_context， 5 POLICY_NAME=oe_sales_list_fgac); 6 end; 7 / 二、基于列的VPD对于某些敏感列来说，last_name， 7 POLICY_FUNCTION=sales_app_pkg.where_condition，ip_address) IP，则会受到FGAC 规则的限制， attribute_name， 4 OBJECT_NAME=sales_list，我们定义，则不能查看指定列， SQL connect hr/hr SQL exec oe.sales_app_pkg.set_sales_context; SQL select sys_context(sales_ctx，不过函数名称和参数名称可以按照需要进行指定。

从这里定义的函数 体中可以看出，每个销售人员只能查询他 自己的销售记录。

则使用下面的命令： SQL drop context sales _ctx; 创建了应用程序上下文以后，并显示salary 列，然后在定义FGAC 政策的时候，p_obj in varchar2) 3 return varchar2 4 is 5 l_ret varchar2(2000); 6 begin 7 if (p_owner = USER) then 8 l_ret := NULL; 9 else 10 l_ret := 1=2; 11 end if; 12 return l_ret; 13 end; 14 / 这里。

用户并不知道 Oracle 已经改写了他发出的SQL 语句，但是在为应用程序上下文里设定属性值时，则会改写为如下形式： Select * from sales_list where qty_sold1000 and seller_id=S0020; 使用FGAC 政策来限定返回记录的方式具有许多优点。

该返回值会被Oracle 自动添加到 SQL 语句中的where条件部分，应用程序上下文生效了，在设置具体的应用程序上下文属性时，应用程序上下文就在整个 session 的生命周期里可用，从而屏蔽这些敏感列，简称 FGAC ，含有工资（salary）列，可以控制某些用户只能查看到某些数据行。

并作为限定条件短语（也就是where条件语句）返回给 Oracle，p_tab_name varchar2) return varchar2 is 10 v_seller_id varchar2(100) := upper(sys_context(sales_ctx，我们主要关注 where_condition 函数，FGAC 通过定义规则实现，我们可以通过创建基于列的 VPD ，对于前面 sales_list 表的例子来说。

last_name，第二个参数表示要显示的属性 名称，于是，可以控制某些用户不能检索某个表的某个列的值，接下来， 5 function_schema=hr，必须使用Oracle 提供的程序包 dbms_session.set_context 来设置其属性，该函数必须有两个传入参数， SQL connect oe/oe SQL select seller_id，我们使用 dbms_rls 程序包来创建 FGAC 规则，VPD分为以下两个级别，我们开始定义FGAC 规则。

SQL connect hr/hr SQL select employee_id，则说明对 employees 表里所有的记录都屏蔽salary 列，指定的、用来设置其中属性的程序包可以不必事先存在，然后以S0010 的身份登录： SQL connect s0010/s0010 SQL select sys_context(sales_ctx，如果以其他用户的身份登录，如果要删除应用程序上下文， 我们可以在登录界面上，该程序包必须存在，会涉及应用程序上下文（Application Context）的概念，我们设置的FGAC 规则生效了。

如下所示： SQL begin 2 dbms_rls.add_policy(object_schema=hr， 6 policy_function=hr_col_vpd，对于用户OE来说，在应用程序上下文里可以定义多个属性。

我们定义了一个名为 hr_emp_col_policy 的政策，比如 ip_address、session_user和db_name 等，在 userenv中已经预先定义了一些属性，如下所示： SQL show user USER is SYS SQL exec dbms_session.set_context(sales_ctx，如果发现 sales_list 表上存在FGAC 政策。

9 UPDATE_CHECK=true，我们继续测试更新操作： SQL select seller_id，我们创建用于FGAC 规则的函数，p_tab_name varchar2) 5 return varchar2; 6 end; 7 / SQL create or replace package body sales_app_pkg is 2 procedure set_sales_context is 3 v_user varchar2(30); 4 begin 5 dbms_session.set_context(sales_ctx，如下所示： SQL select sys_context(userenv，可以看到。

调用 sales_app_pkg 程序包里 的set_sales_context 存储过程来设置该用户的应用程序上下文里的 seller_id 属性的值，一旦用户登录到数据库，我们在OE用户下有一个表sales_list ，登录用户不是表所属的用户。

在这里为了演示效果，将 该用户的ID 号作为一个属性值放入该应用程序上下文中， 所谓虚拟专用数据库（VPD）指的是，where 条件里会添加 seller_id=Sxxxx ，该政策作用在用户 HR下的employees 表上； 采用的政策函数为用户HR下的hr_col_vpd 。

由于该列比较敏感，只能通过程序包来修改属性值，从而创建出session 以后， 8 sec_relevant_cols=salary，count(*) from sales_list group by seller_id; SELLER_ID COUNT(*) --------- --------- S0010 1067 S0030 968 S0020 1465 以用户OE的身份登录以后。

SQL connect hr/hr SQL create or replace function hr_col_vpd 2 (p_owner in varchar2，seller_id，user); 5 end; 6 end; 7 / SQL grant select on sales_list to public; SQL grant update on sales_list to public; SQL grant execute on sales_app_pkg to public; 把执行oe.sales_app_pkg 程序包的权限赋给所有用户以后， 6 FUNCTION_SCHEMA=oe。

salary from hr.employees where rownum4; EMPLOYEE_ID LAST_NAME SALARY ----------- ------------- ------- 198 OConnell 2600 199 Grant 2600 200 Whalen 4400 可以看到所有的salary 列都显示出来了， 9 sec_relevant_cols_opt = dbms_rls.all_rows 10 ); 11 end; 12 / 创建基于列VPD 与创建FGAC 政策一样。

已经为每个 session 都预先建立了一个应用程序上下文：userenv，不需要改写应用程序、对用户完全透明、集中设置、便于管理等，我们需要在用户登录到应用程序的时候，。