我们都知道drop table, truncate table时都会先做一次checkpoint，将被删除对象的脏块写入磁盘。
客户有一套系统，Oracle 9.2.0.8，需要做数据迁移，由于种种原因，采用的是逻辑迁移的方式。由于库比较大，超过了1.5T，而停机时间又有限，因此在正式迁移之前需要做大量的测试，测试的目的，一方面是看迁移流程上是否存在问题，另一方面是看迁移的时候，哪个地方会存在性能瓶颈，并进行优化，同时估算实施迁移时间。
第一次测试后，需要把测试产生的大量用户及其对象全部删除，删除用的是drop user username cascade。不幸的是这种方式删除得相当地慢。一个9000多个表的用户，删除了1个半小时才删除了4000多个表。为什么这么慢？有没有办法提高速度？
drop table既然要做checkpoint，那么在db cache非常大的情况下，这需要消耗的时间是比较长的。如果能够减少这个时间无疑将大幅提高速度。首先尝试做一次checkpoint，将buffer cache全部刷新出去：
alter system checkpoint;
alter session set events 'immediate trace name flush_cache level 1';
发现没什么效果。
由于db_cache_size有50GB左右，db_keep_cache_size有6G左右。重新设置参数，将db_keep_cache_size设为0，将db_cache_size设为200M，重启一下数据库，重新执行删除用户的操作，操作很快完成。
在另一次同样的过程中，采用同样的修改参数的方式，效果同样非常明显。
这是个简单的案例，与君共享。
前几天客户遇上这样一个问题，某个用户A将视图的SELECT给予另一个用户B，但是用户B查询这个视图时，仍然报错：ORA-01031: 权限不足。这是怎么一回事呢？下面来模拟一下这个过程：
有三个用户test1,test2,test3， 三个用户都具有DBA色色权限。
用TEST1用户创建一个表T1，并将其查询权限授予TEST2：
SQL> create table t1 as select * from all_objects;
表已创建。
SQL> grant select on t1 to test2;
授权成功。
用TEST2用户创建一个视图，视图的基表是TEST1.T1，并将查询权限授予TEST3：
SQL> create view v_t1 as select * from test1.t1;
视图已建立。
SQL> grant select on v_t1 to test3;
授权成功。
TEST3用户查询视图TEST2.V_T1：
SQL> select * from test2.v_t1 where rownum<1;
select * from test2.v_t1 where rownum<1
*
ERROR 位于第 1 行:
ORA-01031: 权限不足
可以看到报了权限不足的错误，就算这里TEST3用户有DBA权限。
这到底是怎么回事呢？
其实视图的权限，有两点需要引起注意：
1. 视图中，类似于定义者权限的存储过程，是屏蔽了角色权限的。比如如果TEST1没有显式地将T1表的SELECT权限给予TEST2，那么TEST2在创建视图V_T1时也会报ORA-01031错误，即使TEST2用户拥有DBA角色权限。
2.如果在用户A的视图中，引用了其他用户B的表，用户A将视图的访问权限给予用户C，那么就变相地将用户B的表的访问权限给予了用户C，因此，用户A必须有将用户B的表的访问权限转授用户C的权限，也就是用户B在授予A权限时，必须使用with grant option。
显然这里正是由于第2点的原因，导致用户TEST3不能访问视图。用户TEST1执行下面的操作，将解决这个问题：
SQL> grant select on t1 to test2 with grant option;
授权成功。
对于视图的UPDATE，DELETE权限，同样是如此。
在测试时，有一个现象，有点意思。就是如果用户TEST2没有显式地把V_T1的SELECT权限授予TEST3，而TEST3在有SELECT ANY TABLE或DBA权限时，则查询这个视图时不会报权限不足的错误。由于有SELECT ANY TABLE权限的存在，所有的用户表都可以被访问。但是显式授予表的权限时，似乎表的权限有更高的优先级，并且没有跟系统权限和角色权限进行结合。或者版本不同，表现得不一样，在我的测试中，是Oracle 9.2.0.8 for Windows。
privilege, view