oracle - 关于回滚段的一些特点及自己的理解

转自：http://www.itpub.net/

oracle中的回滚段（rollback segment）是oracle中的一个重点和难点。一下是本人在学习中的一些体会，不对的地方希望大家批评指正。回滚段一下简称为rbs。

Oracle 中的所以的I/O操作均要通过rbs进行的，rbs是针对transaction而言的。rbs实际上是数据文件，不能是临时文件。
数据段中的数据是由rbs和日志文件的整理后写进去的，用户不能直接写入数据文件中。也就是说用户不能跳过rbs而直接写入数据文件。

以下是rbs的主要特征：
1）rbs是必不可少的
rbs提供了数据的一致性。需要注意的是redo log文件仅仅是为了恢复而起作用的，redo log文件只能往下写。
2）rbs是共享的
这里的共享是指的transaction一级。虽然transaction也可以指定独享rbs。
3）rbs是循环写的（cyclical）
4）从一而终原则
某一个transaction使用了次rbs后，在没有commit或rollbak之前是不会退出的。所以要教育开发人员频繁的commit，这样可以留出来给别人使用，否则回产生竞争，导致性能下降。
5）选择的随机性
6）rbs的覆盖不能跨越
7）miniextents 是指rbs在覆盖之前的所能够分配的最小区域这是优化的重点。将此数据建大的好处有两个：
  （1）可以避免ora600错误
  （2）可以以时间换空间

补充几点个人的体会，望批评改正：
1）RBS保存数据修改前的值，即前映像(before-image or old-image)
2）概括地说有三种RBS：
  （1）用于数据字典操作的系统RBS，位于system tablespace。
  （2）用于每个实例操作的私有RBS。
  （3）用于OPS环境下的仅有RBS。
3）RBS的作用：
  （1）rollback，即当事务rollback时，将保存在RBS中的前映像复原。
  （2）read consistency，当某个事务要查询的数据正在被另一个事务修改且没有提交或回滚，
            则查询的事务必须从RBS中取出数据的原值。
  （3）recovery，当SMON进程启动进行实例恢复时使用。roll-forward时产生RBS。
4）设置RBS时的参数参考取值：
  （1）initial = 2^n
  （2）next = initial
  （3）pctincrease = 0
  （4）minexetents = 20
  （5）maxextents <> unlimited

对楼上的一点点意见:
RBS initial的值应该和block size设置相关, 我印象中是block size的倍数, 而非仅仅是2的n次幂就可以了

还可以讨论一下9i中的撤销表空间，个人感觉自动撤销（利用撤销表空间）比手工撤销（利用回退段）优秀很多，不过占用空间较多。
其实想写一份关于自动撤销与手工撤销的对比以及自动撤销的设置的文档，不知道大家需不需要。

基本概念：手工撤销管理方式
在Oracle 9i中，回退也被称为撤销管理。在Oracle 8i及以前版本中，撤销管理只能利用回退段来实现的，DBA需要以手工方式对回退段进行管理。这在Oracle 9i中称为手工撤销管理方式。

基本概念：自动撤销管理方式
在Oracle 9i中提供了一种新撤销管理方式，DBA不需要为数据库创建多个回退段，也不需要管理回退段的使用，只需要创建一个撤销表空间，其他的管理工作都可以由Oracle自动完成。这在Oracle 9i中称为自动撤销管理方式。

利用自动撤销管理功能，无需利用回退段，也无需太多的用户干预，即可有效的实现数据库的回退功能。

在Oracle 9i中，已经开始逐渐使用“撤销（Undo）”一次来代替传统的“回退（Rollback）”一词，这样不仅意义更加清晰，而且能够更好的和数据库的另一项功能——“重做（Redo）”对应起来。在本文中，如果提到手工撤销管理方式，将仍然使用“回退”一词，如果提到自动撤销管理方式，则使用“撤销”一词。两个词所代表的基本意义是相同的，但是从Oracle的官方资料看，在以后版本的Oracle中，“回退”一词将不再使用。

1．撤销管理方式
从Oracle 9i开始，撤销管理功能可以通过两种方式实现，即手工撤销管理方式和自动撤销管理方式：
手工撤销管理方式  即利用回退段来进程撤销管理。这是与以前版本相兼容的方式。如果将初始化参数UNDO_MANAGEMENT设置为MANUAL，Oracle将使用手工撤销管理方式。
自动撤销管理方式  自动撤销管理方式只能在Oracle 9i中应用。要应用自动撤销管理功能，Oracle需要为每个实例创建一个撤销表空间（Undo Tablespace），并且将初始化参数UNDO_MANAGEMENT设置为AUTO。

提示：
为了简化管理操作，并提高回退管理的效率，建议在Oracle 9i中使用自动撤销管理方式。
自动撤销管理功能的实现是基于撤销表空间的。在使用DBCA创建数据库时，会自动创建一个默认的撤销表空间UNDOTBS。用户也可以创建自己的撤销表空间。实例所使用的撤销表空间由初始化参数UNDO_TABLESPACE指定。
在自动撤销管理方式下，由Oracle来负责为事务在撤销表空间中分配回退条目存储空间。在撤销表空间中的存储结构被称为撤销段（Undo Segment），它的结构和存储特性与前面所介绍的回退段类似，只是完全由Oracle来自动管理和维护。

2．自动撤销管理方式的注意事项
在自动撤销管理方式下，有两个问题需要特别注意：

如果某个事务在执行过程中出现异常，它有可能会用光所有的撤销存储空间。在手工撤销管理方式中，为了避免这种情况的发生，DBA通常会为回退段设置一个较小的MAXEXTENTS参数，然后再使用SET TRANSACTION USE ROLLBACK SEGMENT语句来为那些规模较大的事务显式分配更大的回退存储空间。这种方法虽然有效，但是却比较繁琐。而在自动撤销管理方式下，可以通过设置UNDO_POOL初始化参数来解决这个问题。DBA可以将数据库用户分为若干个资源使用者组，然后再为对个组所能使用的撤销空间进行限制。当组中所分配的撤销空间使用完毕后，组中的用户将暂时无法再执行更新事务，直到组中其他的用户释放撤销空间。

提示：
UNDO_POOL参数的默认值为UNLIMITED，这时用户所能使用的撤销空间将不受限制。

如果某个查询会延续很长的时间，它可能会失败。这是因为用于保证读一致性的撤销记录可能已经丢失。任何活动的事务（未提交的事务）都有可能覆盖已提交事务保存在撤销段中的撤销信息。在手工撤销管理方式中，由于回退段使用循环写入方式，已提交事务的回退信息并不会立即丢失，而是一直保存到被其他事务覆盖为止。在自动撤销管理方式下，为了解决这个问题，允许DBA对已提交事务的撤销信息的保存时间进行控制。通过延长撤销记录的保存时间，可以避免有用的撤销信息被覆盖。

失效撤销信息的保留时间可以通过初始化参数UNDO_RETENTION来进行设置。比如，如果将UNDO_RETENTION参数设置为1800，所有已提交的事务的撤销记录至少会在撤销段中保留30分钟。这样就保证了那些持续执行时间在30分钟以内的查询不会因为丢失撤销信息而产生“快照太旧（Snapshot too old）”错误。

3．更改撤销记录保留时间例子
为了避免产生快照太旧错误，DBA需要将UNDO_RETENTION参数设置为一个较大的值。DBA可以在实例运行期间动态改变UNDO_RETENTION参数的值。比如，可以通过下面的语句将撤销记录保留时间更改为20分钟：
ALTER SYSTEM SET UNDO_RETENTION = 1200;
DBA可以通过动态性能视图V$UNDOSTAT来查看撤销表空间的使用情况。在V$UNDOSTAT视图中将可以查看事务的撤销统计信息，比如实例所使用的撤销空间大小等。

犀牛呀，还有RBS的数量如何选择好像没有讨论。

一些总结如下：
一个实例可以仅使用私有回退段，也可以仅使用公用回退段，还可以同时使用私有回退段和公用回退段。当实例打开数据库时，它将按照如下规则获取所需的回退段：

——规则1  实例必须至少获取一个回退段。如果仅有一个实例访问数据库，将为它分配SYSTEM回退段。如果同时有多个实例访问同一个数据库，除了将SYSTEM回退段作为各个实例的公用回退段来使用外，还必须至少为每个实例再分配一个非SYSTEM回退段。如果非SYSTEM回退段的数目不足，实例将无法启动。

——规则2  实例所需回退段的总数按照下面的公式进行计算：
CEIL(TRANSACTIONS/TRANSACTIONS_PER_ROLLBACK_SEGMENT)
TRANSACTIONS和TRANSACTION_PER_ROLLBACK_SEGMENTS是两个初始化参数。TRANSACTIONS参数指定实例所能支持的最大并行事务数目，TRANSACTIONS _PER_ROLLBACK_SEGMENT参数指定每个回退段所支持的最大并行事务数目。
计算出TRANSACTIONS和TRANSACTION_PER_ROLLBACK_SEGMENTS的商后，通过SQL函数CEIL得到大于这个商的最小整数。比如，实例的TRANSACTIONS参数值为155，TRANSACTIONS_PER_ROLLBACK_SEGMENT参数值为10，那么实例将在打开数据库时尽量获取16个回退段，计算方法为(CEIL(155/10)=16。

——规则3  在获取了SYSTEM回退段后，下一步，实例将试图获取由初始化参数ROLLBACK_SEGMENTS参数所指定的私有回退段。这个分配是强制性的，即使ROLLBACK_SEGMENTS参数所指定的私有回退段数目超过了规则2中计算出的所需回退段数目，实例仍然会获取所有指定的私有回退段。

——规则4  如果在规则3中实例已经获取的私有回退段数目等于或大于在规则2中计算出的所需回退段数目，分配过程到此为止。否则，实例将尝试申请公有回退段，以补偿所差的数目。

比如，利用规则2计算出实例需要使用12个回退段，而在ROLLBACK_SEGMENTS参数中指定了“rb01，rb02，……，rb09”共9个私有回退段，实例将首先获取这9个私有回退段，然后再试图获取3个公有回退段，以满足实例所需。

initialization parameters file(in o9i)

我也正在试用o9i的Undo space, 经 Felix指点对这一新概念又有了更进一步理解，非常感谢。
不过我在修改UNDO_MANAGEMENT，UNDO_TABLESPACE等初始化参数时，发现o9i的启动中又多了一个概念spfile(server parameter file)，它是对应initSID.ora(text file)的一个binary file,名字为spfileSID.ora，在执行startup command时缺省使用得就是 spfileSID.ora(在不指定pfile时)，所以只改initSID.ora，而启动数据库时又没指定pfile参数，则修改不会生效。

嘻嘻，一些简单了解如下

传统上，Oracle在启动实例时将读取本地的一个文本文件，利用从中获取的初始化参数设置来对实例和数据库进行配置，这个文本文件即称为“初始化参数文件（Initialization Parameter File，简称为PFILE）”。如果要对初始化参数进行修改，必须首先关闭数据库，然后在初始化参数文件中进行编辑，再重新启动数据库使改动生效。

从Oracle 8i开始，有许多初始化参数都成为了动态参数，也就是说可以在数据库运行期间利用ALTER SYSTEM（或ALTER SESSION）语句来修改初始化参数，并且不需要重新启动数据库修改就可以立即生效。但是使用ALTER SYSTEM语句对初始化参数进行的修改并不能保存在初始化参数文件中。因此，在下一次启动数据库时，Oracle依然会使用初始化参数文件中的参数设置来对实例进行配置。如果要永久性的修改某个初始化参数，DBA必须通过手工方式对初始化参数文件进行编辑。这就为初始化参数的管理带来了不便。

另外，在Oracle 8i与以前版本中，无论是启动本地数据库还是远程数据库，都会读取本地的初始化参数文件，并使用其中的设置来配置数据库。也就是说如果DBA需要以远程方式启动数据库，必须在本地的客户机中保存一份初始化参数文件的备份。

由于存在上述两个问题，就会使DBA的管理工作更加复杂。因此，在Oracle 9i中提供了“服务器端初始化参数文件（Server-Side Initialization Parameter File，SPFILE）”特性。使用这个特性则能够很好地解决这些问题，简化DBA的管理工作。

服务器端初始化参数文件是一个二进制格式的文件，它始终存放在数据库服务器端。这样如果DBA需要远程启动实例，他不再需要在客户机中保留一份初始化参数文件，实例会自动从服务器中读取服务器端初始化参数文件的内容。这样做的另一个优势是能够确保同一个数据库的多个实例都具有完全相同的初始化参数设置。

此外，如果在数据库的任何一个实例中使用ALTER SYSTEM语句对初始化参数进行了修改，在默认情况下（SCOPE=BOTH），都会被永久地记录在服务器端初始化参数文件中。这样当下一次启动数据库时，这些修改将会自动继续生效。因此，DBA无需对初始化参数文件进行手工编辑，就能够保证使用在数据库运行过程中对初始化参数的修改不会丢失。另外值得一提的是，从Oracle 9i开始，由于引入了服务器端初始化参数文件特性，这也为Oracle数据库自我性能调整（Self-Tuning）的实现提供了基础。

警告：
服务器端初始化参数文件是二进制格式的。尽管能够打开它查看其中的内容，但是任何用户都不应当手工对其中的内容进行编辑，否则实例将无法启动。

在使用DBCA创建数据库的过程中，DBCA在默认情况下将自动应用服务器端初始化参数文件。此外，用户也可以通过使用CREATE SPFILE语句为数据库手工创建服务器端初始化参数文件。
在启动数据库时必须提供一个初始化参数文件（无论是文本初始化参数文件还是服务器端初始化参数文件）。因此，在执行STARTUP语句时，它将按照如下顺序寻找初始化参数文件：

·        首先检查是否使用SPFILE参数指定了服务器端初始化参数文件。

·        再检查是否使用了PFILE参数指定了文本初始化参数文件。

·        如果没有使用SPFILE参数或PFILE参数，则在默认位置寻找默认名称的服务器端初始化参数文件。

·        如果没有找到默认服务器端初始化参数文件，则在默认位置寻找默认名称的文本初始化参数文件。



   利用ALTER SYSTEM语句可以在数据库运行过程中修改初始化参数的值。如果实例启动时使用的是一个传统的文本初始化参数文件，利用ALTER SYSTEM语句修改的初始化参数仅在当前实例中有效，用户所做的更改不会被记录在初始化参数文件中。如果要永久性地修改初始化参数，必须手工编辑初始化参数文件。而如果在实例启动时使用的是服务器端初始化参数文件，则可以省去手工编辑初始化参数文件的麻烦。

  在使用ALTER SYSTEM语句时，可以在SET子句中通过SCOPE选项来设置ALTER SYSTEM语句的影响范围。所谓影响范围，即ALTER SYSTEM语句对参数的修改是仅对当前实例有效（记录在内存中），还是永久有效（记录在服务器端初始化参数文件中）。
SCOPE选项可以被设置为3个值：

·        SCOPE=SPFILE  对参数的修改仅被记录在服务器端初始化参数文件中。该选项同时适用于动态初始化参数与静态初始化参数。修改后的参数只有在下一次启动数据库时更改才会生效。

·        SCOPE=MEMORY  对参数的修改仅被记录在内存中。对于动态初始化参数，更改将立即生效，并且由于修改并不会被记录在服务器端初始化参数文件中，在下一次启动数据库时仍然会使用修改前的参数设置。对于静态初始化参数，不能使用这个SCOPE选项。

·        SCOPE=BOTH  对参数的修改将同时被记录在内存中和服务器端初始化参数文件中。对于动态初始化参数，更改将立即生效，并且在下一次启动数据库时将使用修改后的参数设置。对于静态初始化参数，不能使用这个SCOPE选项。如果数据库使用了服务器端初始化参数文件，在执行ALTER SYSTEM语句时，Oracle默认地将SCOPE选项设置为BOTH。


另外，关于具体的操作，比如如何创建SPFILE，如何导出SPFILE，以及如何在数据字典中查询SPFILE中的参数（V$SPFILEPARAMETERE好像是这个）等等可以参见9i的文档，里面很详细的，上面这些文字大部分也是文档中翻译来的。