选择回滚段的数量和大小
可以用前面对回滚段条目的描述，为自己的数据库做类似的回滚段设计。这里要注意的是，除非数据库有着一致的事务特性，否则每个数据库的最终设计都不一样。设计过程包括确定事务量并估计事务的数量及类型。下面几节，将会在一个应用实例中示范这个过程。可以从这个事务数据中产生回滚段的合适数量、尺寸及结构。
一、事务条目数量
设计过程的第一步是确定回滚段条目数据的总量，这是任何实例都要使用的。注意，这里有两种类型的条目要予以考虑。
• 激活的条目—还没有被提交或回滚。
• 非激活、但正在被使用(IIU)的条目—已经被提交或回滚，但其数据正被另一个进程使用(例如一个冗长查询)。
那些非激活且没有被其他进程使用的回滚段条目在这些计算中并不重要。
高效管理回滚段的关键因素是使非激活、但正在被使用(IIU)的条目数据最少。作为一个数据库管理人员，没有办法发现IIU条目所使用的回滚段空间，而只有在用户报告出现了ORA-1555“snapshot too old(快照太旧)”，错误消息时，才能证明它们的存在。
要最小化回滚段中的IIU数据，需要知道何时执行那些冗长查询。如果它们恰好同时出现并带有多个事务，便会出现I I U回滚段条目的不断积累。这时，无论回滚段有多大，这种糟糕的事务分配最终会导致查询失败。
要解决这个问题，需要将全部大型查询隔离开，以便在事务活动很少时分别运行它们。这种隔离既可以最小化IIU回滚段条目数据，同时也有助于避免查询与事务之间可能出现的I/O并发冲突。
可以用前面“回滚段中的数据量”给出的查询，来确定正写入回滚段的回滚段条目数据。每一个大型事务可以使用这里讲到的方法来确定其尺寸(在测试环境中)。确定事务尺寸应当是应用程序开发中确定数据库尺寸过程的标准部分。
还应注意的是，对事务中共享的I I U回滚数据量也要实施最小化。在一个事务访问一个数据表时，另一个事务正在对这个数据表进行处理，这样就会造成大量的I I U数据。如果将其最小化，就可以分配并测量这个系统的回滚段数据需求。
二、事务数量
一旦知道回滚段条目数据的总量，就必须考虑事务的数量。根据这些事务间的相对量，将它们分成几种类型。对每一组，都要确定最大及平均事务尺寸。对这部分回滚段大小的处理，只考虑系统正常运行时出现的事务，而不考虑所有数据装载。
可创建一个表7 - 6所示的电子数据表结构。所示数据仅作参考。表中的“事务类型”一列反映的是一个动物园巡回展出的应用程序数据条目。“数量”列反映的是每一类并发事务的数量。“全部条目尺寸”列以字节形式表示这种类型的所有并发条目的总尺寸。
这里要注意的是，“数量”列指的是不同事务的数量。如果在一个事务中更新多条记录，则这个列还是按一个事务计算。
表7 - 6中列出的事务表明，用户在每10~100个记录后提交一次。例如， VISITOR_LO 事务的平均大小为40KB，这可能是10个4KB的记录或100个400字节的记录，具体情况依记录长度和提交频率而定。
根据表7 - 6中的数据，数据库中平均有35个并发事务，每一次它们平均要创建2710KB数据。
该数据库中最大的一个事务为700KB，把它作为确定回滚段大小的起点。这个事务必须适合单个回滚段。这个回滚段还将包含回滚段头部空间，并且也可能有非激活数据。若要计算能支持单个这种事务的回滚段的最小尺寸，可以用下面的计算公式。这个公式采用以下假设：
• 保留20%的回滚段空间作为自由空间。
• 将15%的回滚段空间用于IIU数据。
• 5%的回滚段空间由回滚段头区域使用。
最小可行尺寸(MPS)=最大事务尺寸×100/(100-(自由空间百分比+IIU数据空间百分比+头空间百分比))
=最大事务尺寸×100/(100-(20+15+5))
=最大事务尺寸×100/60
=最大事务尺寸×1.67
=700KB×1.67
=1170KB
由于数据库以循环方式选择回滚段，所以处理这种事务的每一个回滚段都要不小于这个规模。
任何时候需要的回滚段总空间都可以计算。这同样将用到上面的假设。
最小总尺寸(MTS)=所有条目数据总尺寸×100/(100-(自由空间百分比+IIU数据空间百分比+头空间百分比))
=所有条目数据总尺寸×100/(100-(20 + 15 + 5))
=所有条目数据总尺寸×100/60
=所有条目数据总尺寸×1.67
=2710KB×1.67
=4525KB
因此，对于这个例子来说，所有回滚段的最低空间总量，在任何时候至少为4525KB。
但应当分给这个空间多少个回滚段呢？由于回滚段的尺寸全部相同，所以最小值也就容易计算。正如你所看到的那样，每个回滚段的最小值为1170KB。所有回滚段尺寸的最小总和为4525KB。下面的式子用这两个值进行了计算，以确定所需的回滚段最小数量：
最小回滚段数量(MNRS) = 最小总尺寸/单个回滚段最小可行尺寸
= 4525KB/1170KB
= 3.87(向上舍入到4)
这将是所需回滚段数量的一个起点。注意，这个值只考虑了空间要求。
要进一步细化这个计算，则要考虑并发事务的数量。回滚段中的事务处理越少，数据库管理其空间需求的工作就越少。回滚段的最大数量是并发事务的数量(假设每个回滚段一个事务)。对于表7 - 6中所示的样本数据，这个数值为35。
回滚段的最大数量= 并发事务数量= 35
这样，产品数据库大约需要4 ~ 3 5个回滚段。若要进一步缩小范围，就必须确定每个回滚段的事务数量。每个事务现在都将适合其自己的盘区而不是回滚段本身。而要做到这一点，就必须评估事务大小的分配。
如表7-7所示，将那个动物园巡回展出中的事务分为两组。第一组的平均尺寸为40 ~ 70KB；第二组的平均值为500 ~ 700KB。由于这两组平均尺寸值之间存在巨大差别，所以不浪费空间或实施覆盖就不可能解决它们的空间要求。
条目尺寸较大的组数量非常少，在全部3 5个并发事务中仅占2个。因此可以设计处理小尺寸的条目组，而预留出空间来处理大型的意外并发条目组。因此，确定了小型条目组的尺寸也就形成了设计要求的最低范围。
对于一个小条目组，条目的总和为1510KB。这样，这个组所需的回滚段最低总规模为：
MTS = 1510KB×1.67 = 2522 KB
该组中的最小盘区尺寸是最大事务的尺寸：
最小盘区尺寸(MES)=70KB
一个70K B的盘区将处理每个小型条目事务。对于那些大型事务，它至少将需要7个覆盖段(对500KB的条目，需要8个70KB的盘区)。若要最小化大型条目事务所覆盖的盘区数量，就要考虑大一些的盘区尺寸。对于大小为125K B的盘区，被覆盖的盘区数量就很少，但对存储空间的要求也增加了。若再将盘区增大到250KB，会进一步减少被覆盖的盘区数量。不过，如表7 - 8所示，这将需要增加大量物理空间。
在表7 - 8中，对大小不同的这三种盘区进行了比较。第一种盘区为70KB，它基于计算出的最小平均尺寸。第二种盘区为125KB，意图是减少支持大型事务所需要覆盖的盘区数量；第三种盘区为250KB，旨在进一步减少支持大型事务所需要覆盖的盘区数量。
表7 - 8中的“空间需求”一栏表示，第一种盘区是每个盘区一个事务，共需要3570KB回滚段空间，但要产生16个被覆盖的盘区。对于第二种盘区，尺寸增加到125KB，所需的回滚段空间也增加到5350KB，同时被覆盖的盘区数量减少到7个。第三种盘区的尺寸再增加一倍，达到250KB，所须的回滚段空间增加到9500KB，然而被覆盖的盘区数量也减少到了3个。以上的空间需求计算全部假设一个事务对应一个盘区。这种假设也许会过高地估计了实际要求，但通常这是一个准确的起点。
从表7 - 8中可以看出，在这个例子中，只需将盘区增加2/3，便会将被覆盖的盘区数量减少一半。但是如果使盘区尺寸超过125KB，就不能如想象中那样相应地减少被覆盖的盘区数量。要注意的是，这些计算都是假设一个事务占用一个盘区，即使大型事务也是如此。
必须能够估计你的事务量，才能做到这一点。由于这个计算假设只有15%的回滚段空间用以支持IIU条，而这些条目也必须通过安排来使其最小化。为了做出这样的判断，必须能估计系统事务的类型、数量和特性。
由表7 - 8中的选项可以看出，小尺寸的盘区几乎一直是最合适的选择，因为它一般是数量最大的事务类型，而决定因素就在于事务的数量分布。在这个例子的3 5个并发事务中，有3 3个是小型事务条目，所以表中最大尺寸的盘区可以不予考虑，而只需在较小的盘区( 7 0 ~ 1 2 5 K B )之间做出选择。由于只需将盘区尺寸增加一些，便可迅速降低被覆盖的盘区数量，所以选择1 2 5 K B。要注意的是，我们总是在最小盘区尺寸( M E S )和消除全部覆盖所需要的最小盘区尺寸之间做出最佳折衷选择。而在折衷选择时我们有两点假设： 1 )需要增加的磁盘空间是可以得到的。2 )因盘区被覆盖而受到的性能影响，可以接受。
在前面的计算中，数据库全部回滚段的最小值为4525KB。一个回滚段的最小可能尺寸为1170KB，是4个回滚段的最小尺寸。
在这样的配置中， 4个回滚段中的每一个都可以一次支持9个事务(35个事务除以4个回滚段，舍入)。Oracle建议每个回滚段含4个事务。这样，根据情况差异，从每个回滚段含6个事务开始，创建6个回滚段(3 5/6，舍入)。这样就可以确定实际的空间需求。
这六个回滚段，每个都将包含一个用于回滚段头的盘区。表7 - 9列出了其盘区分配情况。
这个最终的回滚段含18个大小相等的盘区，合计2250KB。它可以处理绝大多数小型输入项事务，也可以支持型大事务。并且包含有自由空间，以便在事务量或事务负载超过预测值时提供支持。
三、确定最佳值
回滚段的optimal值必须适合事务量及管理事务所需的系统开销。这种设计也应当能在一个盘区中处理大多数事务。
因此，回滚段中的事务数量应按盘区估计。每一个回滚段所需的盘区数量为：
每个回滚段的盘区数= 每盘区中的小事务数+ ( (长事务的覆盖数+1) ×平均长事务数)
将它应用到我们的样本数据中便会是：
每个回滚段的盘区数= (33/6)+(5+1)×1=5.6+6=11.6=12(向上舍入)
最长的事务为700KB，将需要6个125KB的盘区。这就要求有5个被覆盖的盘区。由于一次只会有一个这样的事务，所以一个回滚段需要为每一个事务准备一个盘区，并且每一个覆盖上再加一个附加盘区。
使用这么多盘区可以使回滚段既可以处理分配给它们的小型输入项事务负载，也可以提供空间以支持大型事务的平均负载。表7 - 9示出了盘区的分配情况。在表7 - 9中，从盘区2到7支持6个不同事务的第一个盘区。盘区10 ~ 15处理大型事务所需的扩展。
这样，事务数据需要12个盘区。此时需要估计回滚段的系统开销要求。系统开销由三个部分组成。
回滚段开销= 回滚段头空间+ 未激活但正在使用的(IIU) + 自由空间
总是估计回滚段的头占据一个盘区(表7 - 9中的盘区1 )。
IIU空间由为应用程序安排的事务来确定。如果冗长查询与使用相同数据的联机事务同时进行，这个IIU值就应设置得高些。可能出现IIU数据量超过当前使用的事务量。
如果事务分布得合理，就不会发生冗长查询与数据事务同时进行的现象。即使这样，也可能有事务间的重叠现象。这种重叠导致产生IIU空间，通常至少要占据10%的回滚段事务量。
对于那个动物园巡回展出的例子，事务间的重叠估计为15%。
IIU空间= IIU空间百分比×数据盘区数
= 0.15 ×1 2
= 1.80
= 2 (向上舍入)
这2个盘区在表7 - 9中被示为盘区8和盘区9。
最后一个系统开销因素是自由空间。这个自由空间必须能适应最糟糕的事务分配情况。在这种情况中，两个大型事务被分配到同一个回滚段中。
一个大型事务所需要的空间已经在最小盘区量的段计算中予以考虑。因此，只需加上第二个事务出现时的覆盖数量。表7 - 7中列出的大小为500KB的事务，在盘区大小为125KB时(见表7 - 8 )，将需要4个盘区( 3个覆盖)。
自由空间盘区= 需要的附加盘最大数量 = 3
这3个盘区是表7 - 9中所示的盘区16、17和18。
回滚段的optimal值及optimal存储参数值为：
optimal = (每回滚段最小数据盘区数+ 回滚段头盘区+ 未激活但正使用+ 自由空间盘区)×盘区尺寸
= (12+1+2+3)×125KB
= 18×125KB
= 2250KB
若将回滚段的动态扩展减至最小程度，就要把minextents设置为18。这样将预先分配这个回滚段的optimal值。
