[原]Oracle数据库的Ctrl+Z > Undo
pan_tian发表于 2015-06-18 18:38:50
什么是Undo？
UNDO是Oracle中的一个很重要的机制，在对数据库进行修改的时候，Oracle会将数据块上修改之前的数据（称为前映像，Old Image）保存在回滚段中，这样当我们需要进行回滚(rollback)的时候就很容易能从回滚段中将之前的数据取出来将数据块上面的数据还原回来。
如果我们要对表（table）中的一个数据进行修改，在修改之前，先把老的映像（old image）放到undo segment上面。然后再在table中放入new image 。假如过程失败，我们还可以把undo 上的old image 再拿回来放在原先的位置，从而使这件事儿看起来像没发生过一样。
Undo segment 是保存在表空间上的。Undo 大小是固定的，既然是固定的也就是有限的。如果保存的记录非常多，那么它就会被占满，新记录的数据会覆盖掉最早的数据。所以用一个圆形的盘片能更加形象的表示。数据从一个位置开始写入，当写满一圈后，最新的数据就会覆盖最早写入的数据。
Undo的作用
提供回滚事务（Transaction Rollback）、提供一致性读（Read Consistent）以及事务恢复（Transaction Recovery）。
Transaction Rollback事务反转， Transaction recovery 事务恢复。事务反转与事务恢复的效果是一样的。事务反转是人主动去做的，人在操作的过程中反悔了，相当于我在写文档时按个ctrl+z 。事务恢复是机器自动完成的，比如在事务进行过程中简拼突然断电了，下次重启服务之后，系统自动回滚。
1、回退事务（Transaction Rollback）
当执行DML操作修改数据时,UNDO数据被存放到UNDO段,而新数据则被存放到数据段中,如果事务操作存在问题,旧需要 回退事务,以取消事务变 化.假定用户A执行了语句UPDATE emp SET sal=1000 WHERE empno=7788后发现,应该修改雇员7963的工资,而不是雇员7788的工资,那么通过执行ROLLBACK语句可以取消事务变化.当执行 ROLLBACK命令时,oracle会将UNDO段的UNDO数据800写回的数据段中.
2、读一致性（Read Consistent）
用户检索数据库数据 时,oracle总是使用用户只能看到被提交过的数据(读取提交)或特定时间点的数据(SELECT语句时间点).这样可以确保 数据的一致性.例如,当用户A执行语句UPDATE emp SET sal=1000 WHERE empno=7788时,UNDO记录会被存放到回滚段中,而新数据则会存放到EMP段中;假定此时该数据尚未提交,并且用户B执行SELECT sal FROM emp WHERE empno=7788,此时用户B将取得UNDO数据800,而该数据正是在UNDO记录中取得的.
3、事务恢复（Transaction Recovery）
事 务恢复是例程恢复的一部分,它是由oracle server自动完成的.如果在数据库运行过程中出现例程失败(如断电,内存故障,后台进程故障等),那么当重启oracle server时,后台进程SMON会自动执行例程恢复,执行例程恢复时,oracl会重新做所有未应用的记录.回退未提交事务.
关于一致性读
一致性读是相对于脏读（Dirty Read）而言的。假设某个表T中有10000条记录，获取所有记录需要15分钟时间。当前时间为9点整，某用户A发出一条查询语句：select * from
T，该语句在9点15分时执行完毕。当用户A执行该SQL语句到9点10分的时候，另外一个用户B发出了一条delete命令，将T表中的最后一条记录删除并提交了。那么到9点15分时，A用户将返回多少条记录？
如果返回9999条记录，则说明发生了脏读；如果仍然返回10000条记录，则说明发生了一致性读。很明显，在9点钟那个时间点发出查询语句时，表T中确实有10000条记录，只不过由于I/O的相对较慢，所以才会花15分钟完成所有记录的检索。对于Oracle 数据库来说，没有办法实现脏读，必须提供一致性读，并且该一致性读是在没有阻塞用户的DML的前提下实现的。
T，该语句在9点15分时执行完毕。当用户A执行该SQL语句到9点10分的时候，另外一个用户B发出了一条delete命令，将T表中的最后一条记录删除并提交了。那么到9点15分时，A用户将返回多少条记录？
如果返回9999条记录，则说明发生了脏读；如果仍然返回10000条记录，则说明发生了一致性读。很明显，在9点钟那个时间点发出查询语句时，表T中确实有10000条记录，只不过由于I/O的相对较慢，所以才会花15分钟完成所有记录的检索。对于Oracle 数据库来说，没有办法实现脏读，必须提供一致性读，并且该一致性读是在没有阻塞用户的DML的前提下实现的。
我们从上面的流程图来理解一下oracle是如何保证读一致性的。
当我们执行一个事务的时候，oracle会分配一个SCN编号，这个编号是递增的。下一个事务的编号一定比当前事务的编号大。上图中执行第一个事务分配的编号为10023，在这个事务执行的过程中，另一事务对SCN 编号为10008和10021的数据块进行了修改。用来替换的数据块SCN编号为10024 ，而被替换掉的数据块会被保存到undo 上面。当第一个事务执行到被修改过的数据块时，发现10024比10023大，这个时候就会到undo segment上找比自己SCN号小的数据块进行读，于是发找到了SCN号为10008和10021两个块。这样就有效的保证了读一致性。
当然，会有一种特殊情况，也就是undo segment 太小，最多放100条数据，可一下子来了120条数据，那么最先写入的20条数据被最后写入的20条数据覆盖。这个时候就会报错，这也是为什么要对数据据进行调优的原因。
当我们执行一个事务的时候，oracle会分配一个SCN编号，这个编号是递增的。下一个事务的编号一定比当前事务的编号大。上图中执行第一个事务分配的编号为10023，在这个事务执行的过程中，另一事务对SCN 编号为10008和10021的数据块进行了修改。用来替换的数据块SCN编号为10024 ，而被替换掉的数据块会被保存到undo 上面。当第一个事务执行到被修改过的数据块时，发现10024比10023大，这个时候就会到undo segment上找比自己SCN号小的数据块进行读，于是发找到了SCN号为10008和10021两个块。这样就有效的保证了读一致性。
当然，会有一种特殊情况，也就是undo segment 太小，最多放100条数据，可一下子来了120条数据，那么最先写入的20条数据被最后写入的20条数据覆盖。这个时候就会报错，这也是为什么要对数据据进行调优的原因。
著名的ORA-01555快照过旧的问题
ORA-01555: snapshot too old: rollback segment number string with name "string" too small错误很可能就是因为Undo的存储空间太小造成的。
Undo的配置参数
看看undo配置信息：
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0
Connected as system@ptian
SQL> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
SQL>
Connected as system@ptian
SQL> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
SQL>
AUTO:表示undo 为自动管理模式。
900:表示在900秒内，undo上的数据不能被覆盖。
UNDOTBS1:是当前正在使用的undo表空间。
900:表示在900秒内，undo上的数据不能被覆盖。
UNDOTBS1:是当前正在使用的undo表空间。
Undo配置参数含义
UNDO_MANAGEMENT undo的管理模式，分自动和手动，从Oracle 9i开始，Oracle引进了AUM（Automatic Undo Management），9i中默认是MANUAL，10g中默认是AUTO。
UNDO_MANAGEMENT undo的管理模式，分自动和手动，从Oracle 9i开始，Oracle引进了AUM（Automatic Undo Management），9i中默认是MANUAL，10g中默认是AUTO。
UNDO_RETENTION 规定多长时间内，数据不能被覆盖。这个参数设置回滚段中的被提交或回滚的数据强制保留时间，单位是秒。请注意，这个参数和1555错误有非常大的关系。但是，需要提醒的是，并不是回滚段中的数据超过这个时间以后就会被清除掉，而是等到后面事务产生的回滚数据覆盖掉“超期”数据。所以这就是为什么我们往往看到系统的回滚表空间占有率始终是100%的原因了。
UNDO_TABLESPACE 当前正在被使用的undo表
UNDO表空间总大小
UNDO表空间下也以段的形式存储数据，每个事务对应一个段，这种类型的段通常被称为回滚段，或者UNDO段。默认情况下，数据库实例会初始化10个UNDO段，这主要是为了避免新生成的事务对UNDO段的争用。
UNDO表空间的总大小就是UNDO表空间下的所有数据文件大小的总和：
SQL> select tablespace_name,contents from dba_tablespaces where tablespace_name='UNDOTBS1';
TABLESPACE_NAME CONTENTS
------------------------------------------------------------ ------------------
UNDOTBS1 UNDO
SQL> select tablespace_name,sum(bytes)/1024/1024 mb from dba_data_files where tablespace_name='UNDOTBS1' group by tablespace_name;
TABLESPACE_NAME MB
------------------------------------------------------------ ----------
UNDOTBS1 100
监控UNDO表空间使用情况
作为管理员来说，针对UNDO表空间更重要的是日常的监控工作，监控常用到以下的视图：
a).DBA_ROLLBACK_SEGS
DBA_ROLLBACK_SEGS describes rollback segments.
b).V$ROLLSTAT
V$ROLLSTAT contains rollback segment statistics.
c).V$TRANSACTION
V$TRANSACTION lists the active transactions in the system.
d).V$UNDOSTAT
V$UNDOSTAT displays a histogram of statistical data to show how well the system is working. The available statistics include undo space consumption, transaction concurrency, and length of queries executed in the instance. You can use this view to estimate the amount of undo space required for the current workload. Oracle uses this view to tune undo usage in the system. The view returns NULL values if the system is in manual undo management mode.
Each row in the view keeps statistics collected in the instance for a 10-minute interval. The rows are in descending order by the BEGIN_TIME column value. Each row belongs to the time interval marked by (BEGIN_TIME, END_TIME). Each column represents the data collected for the particular statistic in that time interval. The first row of the view contains statistics for the (partial) current time period. The view contains a total of 576 rows, spanning a 4 day cycle.
e).DBA_UNDO_EXTENTS
DBA_UNDO_EXTENTS describes the extents comprising the segments in all undo tablespaces in the database. This view shows the status and size of each extent in the undo tablespace.
DBA_UNDO_EXTENTS.STATUS有三个值：
ACTIVE 表示未提交事务还在使用的UNDO EXTENT，该值对应的UNDO SEGMENT的DBA_ROLL_SEGMENTS.STATUS一定是ONLINE或PENDING OFFLINE状态，一旦没有活动的事务在使用UNDO SEGMENT，那么对应的UNDO SEGMENT就变成OFFLINE状态。
EXPIRED 表示已经提交且超过了UNDO_RETENTION指定时间的UNDO EXTENT。
UNEXPIRED 表示已经提交但是还没有超过UNDO_RETENTION指定时间的UNDO EXTENT。
UNDO表空间下也以段的形式存储数据，每个事务对应一个段，这种类型的段通常被称为回滚段，或者UNDO段。默认情况下，数据库实例会初始化10个UNDO段，这主要是为了避免新生成的事务对UNDO段的争用。
UNDO表空间的总大小就是UNDO表空间下的所有数据文件大小的总和：
SQL> select tablespace_name,contents from dba_tablespaces where tablespace_name='UNDOTBS1';
TABLESPACE_NAME CONTENTS
------------------------------------------------------------ ------------------
UNDOTBS1 UNDO
SQL> select tablespace_name,sum(bytes)/1024/1024 mb from dba_data_files where tablespace_name='UNDOTBS1' group by tablespace_name;
TABLESPACE_NAME MB
------------------------------------------------------------ ----------
UNDOTBS1 100
监控UNDO表空间使用情况
作为管理员来说，针对UNDO表空间更重要的是日常的监控工作，监控常用到以下的视图：
a).DBA_ROLLBACK_SEGS
DBA_ROLLBACK_SEGS describes rollback segments.
b).V$ROLLSTAT
V$ROLLSTAT contains rollback segment statistics.
c).V$TRANSACTION
V$TRANSACTION lists the active transactions in the system.
d).V$UNDOSTAT
V$UNDOSTAT displays a histogram of statistical data to show how well the system is working. The available statistics include undo space consumption, transaction concurrency, and length of queries executed in the instance. You can use this view to estimate the amount of undo space required for the current workload. Oracle uses this view to tune undo usage in the system. The view returns NULL values if the system is in manual undo management mode.
Each row in the view keeps statistics collected in the instance for a 10-minute interval. The rows are in descending order by the BEGIN_TIME column value. Each row belongs to the time interval marked by (BEGIN_TIME, END_TIME). Each column represents the data collected for the particular statistic in that time interval. The first row of the view contains statistics for the (partial) current time period. The view contains a total of 576 rows, spanning a 4 day cycle.
e).DBA_UNDO_EXTENTS
DBA_UNDO_EXTENTS describes the extents comprising the segments in all undo tablespaces in the database. This view shows the status and size of each extent in the undo tablespace.
DBA_UNDO_EXTENTS.STATUS有三个值：
ACTIVE 表示未提交事务还在使用的UNDO EXTENT，该值对应的UNDO SEGMENT的DBA_ROLL_SEGMENTS.STATUS一定是ONLINE或PENDING OFFLINE状态，一旦没有活动的事务在使用UNDO SEGMENT，那么对应的UNDO SEGMENT就变成OFFLINE状态。
EXPIRED 表示已经提交且超过了UNDO_RETENTION指定时间的UNDO EXTENT。
UNEXPIRED 表示已经提交但是还没有超过UNDO_RETENTION指定时间的UNDO EXTENT。
用EM管理Undo数据
EM中选择“相关链接">“指导中心" （Advisor Central）
选择“自动还原管理”（Automatic Undo Management）
Undo和Redo的区别
undo:撤销，也就是取消之前的操作。
redo:重做，重新执行一遍之前的操作。
redo:重做，重新执行一遍之前的操作。
详细比较见Oracle Undo & Redo：http://blog.csdn.net/pan_tian/article/details/7802414
redo与undo如何协作保证数据完整与安全性
(摘自《Oracle+9i&10g编程艺术：深入数据库体系结构》)
以一个例子来说明一下（一个事务包含一组sql语句）：
insert into t(x,y) values(1,1);
update t set x = x+1 where x = 1;
delete from t where x = 2;
1.INSERT
对于第一条INSERT INTO T语句，redo和undo都会生成。所生成的undo信息足以使INSERT“消失“。INSERT INTO T生成的redo信息则足以让这个插入”再次发生“。
插入发生后，系统状态如图所示。
这里缓存了一些已修改的undo块、索引块和表数据块。这些块得到重做日志缓冲区中相应条目的“保护“。
假想场景一：系统现在崩溃
系统现在崩溃是没什么关系的。SGA会被清空，但是我们并不需要SGA里的任何内容。重启动时就好像这个事务从来没有发生过一样。没有将任何已修改的块刷 新输出到磁盘，也没有任何redo刷新输出到磁盘。我们不需要这些undo或redo信息来实现实例失败恢复。
假想场景二：缓冲区缓存现在已满
在这种情况下，DBWR必须留出空间，要把已修改的块从缓存刷新输出。如果是这样，DBWR首先要求LGWR将保护这些数据库块的redo条目刷新输出。DBWR将任何有修改的块写至磁盘之前，LGWR必须先刷新输出与这些块相关的redo信息。这 是有道理的——如果我们要刷新输出表T中已修改的块，但没有刷新输出与undo块关联的redo条目，倘若系统失败了，此时就会有一个已修改的表T块，而 没有与之相关的redo信息。在写出这些块之前需要先刷新输出重做日志缓存区，这样就能重做（重做）所有必要的修改，将SGA放回到现在的状态，从而能发 生回滚。（也就是任何一条修改记录持久化到数据文件的时候，必须先把它对应的redo条目持久化到磁盘文件，以保证这个过程的可逆性。你可能会问，redo不是前滚吗，可逆应该是回滚，怎么跟redo有关系呢？其实是redo段里面包含了undo段的信息）
2.UPDATE
UPDATE所带来的工作与INSERT大体一样。不过UPDATE生成的undo量更大；由于存在更新，所以需要保存一些“前“映像。系统状态如下图所示。
块缓冲区缓存中会有更多新的undo段块。为了撤销这个更新，如果必要，已修改的数据库表和索引块也会放在缓存中。我们还生成了更多的重做日志缓存区条目。下面假设前面的插入语句生成了一些重做日志，其中有些重做日志已经刷新输出到磁盘上，有些还放在缓存中。
假想场景一：系统现在崩溃
启动时，oracle会去读取重做日志文件，会发现有一些redo文件对应的修改记录还没有持久化到数据文件。然后发现这些redo文件是一个事务里面的，于是得回滚这个事务。步骤如下：
a. 根据redo文件，进行数据前滚，会在内存中构造出undo块、已修改的表块，以及已修改的索引块。
b. 根据undo块进行数据回滚，回滚到插入前的数据状态。
3.DELETE
同样，DELETE会生成undo，块将被修改，并把redo发送到重做日志缓冲区。这与前面没有太大的不同。实际上，它与UPDATE如此类似，所以我们不再啰嗦，直接来介绍COMMIT。
4.COMMIT
在此，Oracle会把重做日志缓冲区刷新输出到磁盘，系统状态如下图所示。
假设目前已修改的块放在缓冲区缓存中；有一些块已经刷新输出到磁盘上，有一些还没有。但是如果重做这个事务所需的全部redo都安全地存放在磁盘上，那么修改就是永久的了，即使有一些修改的块还没有刷新输出到磁盘上。（commit并不是把所有的修改持久化到了数据文件，而是所有的redo文件持久化到磁盘文件，只要所有的重做日志文件持久化到磁盘，这些修改就是永久的了。）如果从数据文件直接读取数据，可能会看到块还是事务发生前的样子，因为很有可能DBWR还没有（从缓冲区缓存）写出这些块。这没有关系，如果出现失败，可以利用重做日志文件来得到最新的块。
参考
《Oracle+9i&10g编程艺术：深入数据库体系结构》