我的oracle笔记-06 之 有限CR

到了现在，我们已经可以来完整地描述ORACLE是如何构造页面CR的了。我们假设这个构造过程是从CUR页面开始的，系统首先对该页面进行Cleanout，然后Rollback掉所有未提交的事务（但不包括你自己），最后Rollback掉所有提交的事务，直到当前所有事务的CommitSCN都<=你的SnapshotSCN。注意到你实际上并不会去修改CUR页面，所以在更多的时候，你需要首先Clone。

   每次都从CUR页面开始构造CR显然是一种低效的设计，它会极大地增加回滚段的访问压力，更重要的是，CUR版本只有一个，因此上述处理在RAC环境中，将是一个悲剧。

   所以我们很自然地希望，当我们构造一个CR页面时，我们可以利用系统当前已经构造出来的CR页面作为我们的起点。要完成这样的优化，我们需要仔细地设计。

   首先，我们要保证，候选的CR页面上不会Rollback掉在我的SnapshotSCN开始之前的提交，这意味着我将丢失部分实际上可见的更新，因此，我们需要CR页面的构造者纪录所有被它Rollback掉的提交事务中CommitSCN中的最小值（CR_SCN）。对于你来说，只有那些CR_SCN>=你的SnapshotSCN的CR页面才来拿来作为你的起点。事实上，系统会从满足这个条件的所有CR页面中，依次选择下一个CR_SCN离你的SnapshotSCN最近的页面作为这场选拔赛的出场顺序。

   但这还不够，接下来我们需要保证，候选的CR页面上不会Rollback掉你的更新，但问题在于，如果不访问CUR页面，你无法知道你是否在该页面上进行了更新。所以你会先考虑，如果我从来没有进行过更新（Env_UBA = 0），那么这个页面对我来说肯定是安全的；如果不是，那我希望当初构造这个CR页面的人告诉我，当初Rollback过了哪些活跃事务，里面有没有我。这里会有几种情况：

   1）如果该CR页面上没有Rollback过任何活跃事务（CR_XID = 0），那么安全。

   2）如果该CR页面上只Rollback过一个事务（记录在CR_XID中，且CR_SFL = 0），如果这个事务不是我，那么安全；如果是我，那么我需要考虑，这是否是我在前面某个较早时刻构造出的一个CR页面，然后接下来我又进行了某些更新，因为你无法知道这些更新是否发生在这个页面的CUR版本上，所以只有当你没有再进行过任何更新（ENV_UBA < CR_UBA）时，你才能保证这个CR页面是安全的。

   3）如果该CR页面上Rollback过两个或者更多的事务，你别指望ORACLE会把这些事务全部记录下来，事实上，这时候系统只记录谁CR了这个页面（记录在CR_XID中，且CR_SFL= 1），和前面的处理一样，如果这个事务是你，而你在这之后没有再进行过任何更新（ENV_UBA <CR_UBA），那么安全；否则，你已经不可能知道是否安全了，所以放弃吧。

我喜欢把这种能够利用已有的CR版本来构造新的CR版本的方法称为有限CR，不用每次都从CUR版本开始？听上去真是一种不错的设计，它极大地消减了页面级CR在最差情况下对系统性能的影响。在RAC环境中，有限CR构成了CacheFusion的基础。

转载自：http://blog.sina.com.cn/s/blog_d3bf72ff0101o080.html