|
|
由于回滚段的扩展和回收是昂贵代价的操作,通常我们是要避免的。如果存在大的查询,就算不会去写回滚段,但是由于一致读,我们也可以参照前面内容,知道如果这期间事务繁忙回滚段被循环使用覆盖过,可能出现著名的ORA-01555错误。又由于事务产生的时候除非人为指定使用哪个回滚段,否则事务使用哪个回滚段对于我们应用来说是透明的,同时我们能指定事务使用哪个回滚段但并不能阻止别的事务不使用某个回滚段,这样我们就必须认识到,回滚段设置成大小不一致是不合适的,几乎是没有意义的,因为瓶颈总是决定于最小的一个回滚段(这类似于木桶原理,决定装水量的多少是由最短的片所决定的)。所以我们应该统一回滚段的大小。那通常对于一个系统来说,几百M的磁盘空间甚至几G的磁盘空间根本不是问题,所以我们没有理由在这里研究回滚段到底是使用4M大小还是10M大小,我们根据能提供的磁盘空间的估计,完全可以设置回滚段为50M/100M甚至更大的大小,这主要决定于在大查询运行期间每个回滚段上可能的事务生成量,以及单个事务可能产生的回滚数据的大小。假如系统偶尔存在批量作业的时候可能使得某个回滚段扩展到1G,但平常我们的回滚段大小在50M就不会出现回缩现象。那这个特定的时候如果数据库不繁忙只有大作业我们可以创建几个很大的回滚段,然后是其他回滚段offline,等批作业完成然后再online其他回滚段,使大回滚段offline。当然可能的话也可以指定批作业使用大的回滚段。或者,我们可以为所有回滚段设置optimal为50M,任其特定时刻扩展然后回缩(注意所有回滚段的optimal必须设置一样大小)。
对于回滚段除了按照我们对系统状况估计进行创建、删除外,还有使回滚段联机和脱机,我们要注意的是如果回滚段处于联机并且里面有活动事务的时候,若想使回滚段脱机(offline),则这时回滚段处于一种悬置的状态,也就是新的事务将不能使用该回滚段,而原有的事务继续存在,等待回滚段中所有事务完毕后,回滚段成为脱机状态。 |
|