drop table与db cache
Oracle性能优化11月 30th, 2009我们都知道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,重启一下数据库,重新执行删除用户的操作,操作很快完成。
在另一次同样的过程中,采用同样的修改参数的方式,效果同样非常明显。
这是个简单的案例,与君共享。
« 视图与权限

12月 1st, 2009 at 4:04 上午
alter system flush buffer_cache会不会有同样效果?
12月 1st, 2009 at 4:09 上午
抱歉没看仔细。原来9i用的是event trace。
为什么flush buffer_cache没效果?
老熊 Reply:
12月 1st, 2009 at 11:33 下午
@gengmao, 这个也是我纳闷的地方,或者是有效果,但不是特别明显。
12月 1st, 2009 at 10:53 上午
为什么降低db_cache_size和db_keep_cache_size的大小就能减少checkpoint的消耗时间呢?checkpoint产生的归档日志文件不会有丝毫减少啊!而且降低db_cache_size,drop table, truncate table的时候,日志归档切换时间非常短,不知道我说的对不对?
老熊 Reply:
12月 1st, 2009 at 11:56 上午
@wangliang, 这里不在于日志,在于checkpoint时搜索db cache的过程时间减少。
12月 1st, 2009 at 3:15 下午
非常好:)
12月 1st, 2009 at 10:47 下午
东西一大一多都不好搞,最近偶也在逻辑的迁移数据,如人饮水,冷暖自知。
老熊 Reply:
12月 1st, 2009 at 11:38 下午
@zhouyf, 我服务的这个客户这里,有10套以上的库要迁移,都是超过1T的库,累。
12月 3rd, 2009 at 10:36 下午
如果是RAC,只启动1个instance drop应该会快点
12月 12th, 2009 at 9:20 下午
1、是说由于把oracle内存改小了,每次checkpoint时候搜索的总量少了减少了时间么??
2、如果我内存没有调少,数据库基本不做任何操作,这样脏数据比较少,那是否删除的时间也会比较短的?
另外如果修改这两个值得话是不是也会影响数据库开启的速度?
老熊 Reply:
12月 12th, 2009 at 9:39 下午
@坏白菜,
1. 看上去正是如此
2. 测试过,在db cache很大的情况下,即使重启数据库,drop表时仍然比较慢。还测试过,在db cache开始很小的情况下,删除比较快,但是我在线把db cache设到很大,速度马上就会下降得很厉害。
其实sga小的情况下,启停数据库都会更快一些,我理解你的“开启”为启动数据库。