管理还原数据-阿里云开发者社区

UNDO 表空间管理

1、对于DML语句来说，只要修改了数据块，Oracle数据库就会将修改前的数据块保留下来，保存在undo segment里面，而undo segment则保存在undo表空间中

2、undo的管理

自动undo管理（Oracle9i开始）AUM

手工undo管理MUM

9i以后，就建议使用AUM，因此就不再讨论MUM

一条DML语句的执行流程update t set coll=‘A’ where coll=‘B’

1、在shared pool里面进行解析，从而生成执行计划

2、根据执行计划，得出coll=‘B’的记录存放在10号数据文件的54号数据块里面

3、服务器进程首先在buffer cache寻找一个可用的undo数据块（如果一个事物已经提交，那么这个事务曾经使用过的undo数据块就可以被使用），如果没有发现，则到undo表空间里找到一个可用的undo数据块，并调入到buffer cache。假设获得的undo数据块号为24号，位于11号undo数据文件里

4、将改变前的值，也就是B放入24号undo数据块（buffer cache中）

5、由于undo数据块发生了变化（只要是数据块发生变化，那么就产生重做记录），于是产生重做记录，假设重做记录号是120

6、在buffer cache里面找到54号数据块，如果没有，则从10号数据文件调入

7、将改变后的值，也就是A放入54号数据块

8、由于数据块发生了变化，于是产生重做记录，假设重做记录号是121

9、控制权返回给用户，如果使用SQLPLUS，那么表现为光标返回

10、用户发出commit命令，触发LGWR，将120、121这两个重做记录写入联机重做日志文件中，将54号、24号两个数据块头部所记录的事务状态标记设置为已提交，控制权返回给用户，如果使用SQLPLUS，那么表现为光标返回

11、这个时侯，54号和24号数据块并不一定被DBWr写入数据文件，只有在脏数据块的数量达到一定程度的时候才会被写入

事务提交以后，该事务所使用的undo数据块就可以被覆盖，上面的例子中，第10步用户提交以后，24号undo数据块就可以被覆盖

Undo的作用

1、提供读一执性

2、回滚事务

3、实例恢复

读一致性

一个场景描述

读一致性是相对脏读而言的，表T中有10000条记录，获取所有的记录需要15分钟的时间，当前时间为9点整，用户发出一条select * from T命令，该语句在9：15完成。当用户执行该语句到9：10分的时候，另外一个用户发出了一条删除命令，将最后一条记录删除，并且进行了提交。

到9点15分的时候，用户返回了多少条记录。

如果是9999条，那么就是脏读、如果是10000条，那么就是读一致性。

Oracle不会出现脏读，提供读一致性，而且没有阻塞DML操作

Oracle如何实现读一致性呢？

1、用户在9点发出select语句的时候，服务器进程会记录9点那个时刻的SCN号（SCN号是以时间（timestamp）作为参数的一个函数返回值，调用函数（默认以timestamp为参数）随时可以返回这个时刻的SCN号，可以使用函数在SCN和timestamp之间进行转换），假设该SCN号是SCN9：00，那么SCN9：00一定大于等于记录在所有数据块头部的ITL槽中的SCN号（如果有多个ITL槽，SCN最大的那个）

2、服务器进程扫描T表的时候，会把扫描的数据块头部的ITL槽中的SCN号与SCN9：00进行比较，哪个更大。如果数据块头部的SCN小于SCN9：00，那么说明这个数据块在9：00以后没有更改过，可以直接读取，如果数据块头部的SCN号大于SCN9：00，则说明该数据块在9：00以后更改过，已经不是9：00那个时刻的数据了于是要借助undo块

3、9点10分，用户更改了T表的最后一条记录并提交（无论是否提交，只要是更改了T表，用户就会去读undo数据块），假设被更改的是N号数据块，那么N号数据块头部的ITL槽中记录的SCN被修改为SCN9：10，当服务器进程扫描到这个数据块的时候，发现ITL槽中的SCN9：10大于SCN9：00，说明该数据块在9：00以后被更新了，于是服务器进程到N号块的头部，找到SCN9：10所在ITL槽，由于ITL槽记录了对应的undo块的地址，于是服务器进程找到undo数据块，结合undo数据块给用户提供读一致性。

进一步复杂化问题

1、9点10分，更新了数据并且进行了提交，9点11分又对该数据块进行了更新并且提交（假设数据块只有一个ITL槽）

2、那么该ITL槽记录的就是SCN9：11

3、这种情况如何处理，秘密在于undo数据块中，除了记录改变前的数据以外，因为数据块的ITL槽也发生了变化，因此也进行了记录，而ITL槽中记录了undo块的地址。9：00的时候数据块的ITL槽中记录了数据块的SCN是8：50和对应的undo块，9：10分的时候数据库的ITL槽中记录了数据块的SCN是9：10和对应的undo（undo1），9：11分的时候数据库的ITL槽中记录了数据块的SCN是9：11和对应的undo（undo2），Undo2中记录了9：10的数据，以及9：10数据的undo地址undo1，undo1中记录了9点以前的数据以及9点以前的undo数据

当用户进行查询的时候，服务器进程扫描到N号数据块，发现SCN9：11，大于SCN9：00，从ITL槽中找到undo块的地址（undo2），undo2中记录了改变前的数据和改变前的数据库的ITL槽，发现undo2对应的SCN是9：10还是大于9：00，根据undo里面记录的ITL槽的改变前信息，继续向前找，找到undo1，发现SCN是8：50，小于9：00，使用这个undo的数据

如果在向前寻找的时候，没有找到SCN小于9：00的数据（因为时间比较长，而且事务已经提交，所以回滚段可能被覆盖），数据库就会出现一个经典的错误ORA-01555（snapshoot too old），但是不会出现脏读的情况。

最核心的就是：数据块的数据发生改变，ITL槽也发生改变。这两条信息都会存储到undo中。因此如果一个undo足够的大，那么一个数据块的所有的undo数据块是可以串联起来的。可以从最近一直找到非常远的过去。从数据块开始往前找，一直找到很久以前的SCN。这个数据块所有的变化都能够找到。

ITL槽中记录着这个数据块的undo数据块的地址。

一个数据块中存储很多条数据，update、insert、delete等DML操作，都会影响数据块的SCN号。数据块的SCN号反映了数据块的变化过程。

回滚事务：错误或者rollback命令都会产生回滚

根据ITL槽中记录的undo数据块的地址，找到undo数据块，恢复数据。

实例恢复

回滚段的头部记录了事务表，每一个事务是否提交等信息都存储在里面。

根据事务表的信息进行实例恢复。

配置AUM

Oracle9i开始，我们不再使用手工的管理方式，因此“MANUAL”不再使用，使用“AUTO”

使用AUM需要配置两个参数

指定这两个参数以后，剩余的工作让Oracle来处理，例如undo segment的创建、扩展、收缩、删除等。

如果指定了undo_management，但是在指定undo_tablespace的时候，指定了一个错误的回滚表空间，实例启动的时候，会报错。

如果没有指定回滚段表空间，系统查找第一个可用的回滚段表空间，如果没有找到，那么就使用system表空间中的回滚段，这不是我们希望看到的，因为对性能影响很大。

因此两个参数都要很好的规划

事务、undo segment

发生DML操作的时候，服务器进程会选择一个undo segment，具体算法如下：

1、首先尝试将每一个undo segment绑定一个事务，也就是每个undo segment上只有一个事务使用

2、如果不能发现完全空闲的undo segment，所有的undo segment都与事务绑定

3、系统尝试将脱机的undo segment联机

4、如果没有可用的undo segment进行联机，则会尝试创建一个新的undo segment

5、如果上面的步骤都没有成功（例如没有可用空间了，不能创建undo segment），算法会尝试寻找最早使用的undo segment，这种情况下，不同的多个事务会在同一个相同的undo segment里同时进行

6、每隔12个小时会收缩一次，删除那些idle状态的extent

7、DML操作需要undo时，发现空间不够，则会唤醒SMON进行一次收缩，将undo segment里面暂时没有使用的extent拿过来使用

Oracle 在提供一致性读的过程中，具体的步骤如下

1、确认读时刻的SCN

2、搜寻所有的数据块的SCN要求小于读时刻的SCN

3、如果搜寻的SCN小于读时刻的SCN，直接读取

4、如果搜寻的SCN大于读时刻的SCN，根据数据块里面的ITL槽里面记录的undo信息，找到改变前的数据、如果SCN还是大，顺着ITL槽信息串联起来的undo块继续向前找

5、如果没有找到小于读时刻的SCN的数据块，那么就报错ORA-01555

事务提交以后，undo回滚段就可以被覆盖，而且我们在寻找undo数据块的时候，这个被寻找的undo数据块很可能已经被提交，因此出现ORA-01555错误不可避免。Oracle是如何来解决这个问题的呢？

Oracle定义了一个参数undo_retention

这个参数以秒为单位，表示当事务提交或者回滚以后，该事务所使用的undo 块里的数据需要保留多长时间。

当保留的时间超过undo_retention所指定的时间以后，该undo块才能够被其他事务覆盖。

当我们使用AUM的时候，并且设置了undo_retention以后，undo块的状态就存在4种

Active：表示正在使用该数据块的事务还没有提交或者回滚

Inactive：该数据块上没有活动的事务，该状态的undo可以被其他事务覆盖

Expired：该数据块持续inactive的时间超过undo_retention所指定的时间

Freed：该数据块是空的，从来没有被使用过

在AUM模式中，事务可以在不同的undo segment之间动态交换undo空间，也就是在不同的undo segment里交换extents。

我们来看一下，一个事务需要更多的undo空间的时候，是如何进行处理的？

1、获取undo表空间里可用的、空的extents（segment的最小分配单元是extent）

2、获取其他undo segment里的expired状态的extents

3、如果undo表空间里的数据文件启用了自动扩展，则数据文件进行自动扩展

4、如果undo表空间里的数据文件没有启用自动扩展，则获取undo segment里的inactive状态的extents

5、如果还是没有获得可用空间，报空间不足的错误

1、undo表空间中一共存在5个undo segment

2、每个undo segment包括7个extents

3、当使用US5的事务需要额外的空间的时候，首先使用两个F状态的extent，如果还不够用，继续使用US4里面三个F状态的extents，如果还不够用，使用US3里面X状态的extents，如果还不够用，继续使用US1里面I状态的extent，如果还不够用，报空间不足的错误。

假设上面的数据文件没有配置自动扩展

1、AUM里面分配extent的方式是高效率的，而且尽量避免使用I状态的extent。

2、在Oracle10g里面，如果undo表空间足够，那么Oracle会将undo信息保留的时间与当前运行时间最长的查询所需要的时间相同（一个很好的优势，最大限度的避免了ORA-01555）

3、默认情况下，Oracle每隔30秒就收集统计信息来自动调整undo retention，收集的信息包括运行时间最长的查询与产生undo的速度

我们通过设置undo_retention为0，那么就使用上面的自动调整功能，而且以900秒为最低限

如果我们设置了undo_retention，那么就使用这个参数作为undo_retention的值，不再支持动态的调整undo_retention

4、如果undo_retention设置为0，则实例会获取运行时间最长的那个查询所需要的时间，例如N秒，然后将undo信息保留N秒，当undo表空间尺寸太小时，而不能保留这个最长时间，则尽可能的利用现有空间来让undo保留的时间尽可能的长，并不会立刻扩展undo数据文件，除非要覆盖的undo信息是在900秒以内发生的，才会去扩展数据文件。

管理undo表空间

1、一些常规性的操作，例如添加数据文件、重命名数据文件、将数据文件联机或者脱机，和普通的表空间操作没什么两样。

可以通过EM来进行操作

2、一个数据库可以有多个undo表空间，但是在一个时刻，只能有一个undo表空间起作用，通过参数undo_tablespace设置来指定一个undo表空间