在9i的数据库中排除某些表做owner级导出

在做exp的时候，我们可以做owner级的导出，导出该用户下的所有对象。owner级的导出，会导出所有的表，不太容易排除单独的一些表；而如果做table级的导出，就必须列出所有的table，且当数据库有增加新table的时候，也得把新增的table加到exp的列表中。

今天收到一个客户的要求，做owner级别的导出，但是需要排除几张大表。该需要做成定时的脚本每天执行。

其实，如果在10g中用数据泵，这个exclude很方便处理，但是在9i中，用什么方法才能把某些表单独排除呢？原来我们可以用FGAC来实现。

一、在这里，我们假设我们需要对用户mytest做owner级导出。

二、新建一个用户用于做exp的导出，新建该用户的目的是：该用户只是用来做exp导出，而不修改原来的dba用户或者application用户来做exp导出：

三、建立exclude_table 函数：

这个函数用来控制用户对某个表的访问，FGAC大致的功能是利用dbsm_rls部署一些策略（policy），这些策略会调用一些函数，比如上面我定义的那个exclude_table函数，利用函数，来使得普通执行的sql后面加上谓词。

比如，某sql是：

被细粒度权限控制之后，这个sql语句会自动在后面加上where的谓词做过滤，变成类似：

因此，当被细粒度权限控制之后，就算执行select table_name from dba_tables;也只能出现owner=’MYUSER’的表。

回到上面的exclude_table函数，大致的意思就是当操作的用户是EXPUSER的时候，就在操作的语句后面加1=2，我们知道1=2为非真，因此能select出来的结果肯定是0行。因此，这样就类似的实现了我们对某些表做exp的时候，不导出数据的目的。

好，我们继续把这个函数的功能加到mytest用户下的t1表上。我们用dbms_rls.add_policy来实现，我们先看一下这个过程的参数：

因此对于排除mytest用户下的t1表，我们可以执行：

上述的结果可以用这个sql去检查：

四、好，我们现在来测试owner级导出：
1、我们先测试一下select操作：

这里的区别已经很明显的看出来了。

2、最后我们来实现我们的需求，按照owner级的导出，却排除t1表：

我们看到t1表导出了0行(但是表结构还是被导出的)。

五、取消FGAC。
取消很容易，执行执行dbms_rls中的drop_policy即可：