undo表空间的作用和管理

一、UNDO的产生

dml操作会产生undo的数据块。
update时, server process会在 databuffer中找到该记录的记录块,没有就从datafile中找并读入 data buffer。在修改之前,先放到undo段 active状态,并在数据块头记录undo段中该数据块的位置,读写这个块时会占用事务槽,会将该事务号记录在数据块的头部。然后进行 update,并将该块放到 dirty list检查点队列,等待dbwr进行写操作。

二、UNDO的作用

还原段的引入，主要是为了解决三个问题。

1 事务恢复：在进行DML操作时，insert、update、delete操作时，undo段记录事务的反向操作并且redo日志也记录undo段的操作，既redo保护undo段的信息。当实例关闭或意外崩溃后，再次open时实例需要对没有commit的事务进行回滚，完成事务的恢复。
2 事务回滚：用户进行DML操作后没有进行commit，需要修改前的数据。只要该操作在undo段保护的时间内，此时执行rollback操作可以回滚到最近记录点或上一次commit操作后的状态，恢复到数据修改前的状态。
3 读一致性：当进行DML操作时，undo段会记录数据变更前的状态（通过构造原数据的一致性数据块）。如果用户还没有进行commit操作，其他人查询此条数据会看到数据变更前的状态。因为其他用户读到的数据是undo段中原数据块中的数据，保证没有commit的数据读取的一致性。

4 倒叙查询: flashback query、 flashback table
10G后增加了新特性一一闪回。利用undo已经提交的块,闪回数据库和表。已经提交的块 inactive数据是不能提交的,但可以倒回到某个时间点。
SQL>select name, flashback_on from v$database;

我们常常会忽略对它的监控，这会导致UNDO表空间可能出现以下问题：
1).空间使用率100%，导致DML操作无法进行。
2).告警日志中出现大量的ORA-01555告警错误。
3).实例恢复失败，数据库无法正常打开。

三、undo参数解析

SQL> show parameter undo;

NAME                     TYPE     VALUE
------------------------------------ ----------- ------------------------------
undo_management              string     AUTO
undo_retention                 integer     900
undo_tablespace              string     UNDOTBS1

1 初始化参数undo_management

该初始化参数用于指定UNDO数据的管理方式.如果要使用自动管理模式,为AUTO；如果使用手工管理模式,为MANUAL。

使用自动管理模式时,oracle会使用undo表空间管理undo管理；使用手工管理模式时,oracle会使用回滚段管理undo数据。
如果使用自动管理模式时,如果没有配置初始化参数UNDO_TABLESPACE。Oracle会自动选择第一个可用的UNDO表空间存放UNDO数据,如果没有可用的UNDO表空间,oracle会使用SYSTEM回滚段存放UNDO记录,并在ALTER文件中记载警告

2 undo_retention

该参数是一个时间值。说明当还原段中的事务在提交后继续保留的时间，为flashback等工具进行如闪回数据等操作，该参数默认值为900秒，可以动态修改。
当保留时间超过undo_retention所指定的时间以后，该undo块才能够被其他事务覆盖。当我们使用AUM的时候，并且设置了undo_retention以后，undo块的状态就会存在如下4种情况：

active：活跃的，表示正在使用该数据块的事务还没有提交或回滚。
inactive：不活跃的，表示该数据块上没有活动的事务，该状态的数据块可以被其他事务覆盖。
expired：达到时间上限的，表示该数据块持续inactive的时间已经超过了undo_retention所指定的时间，如果没有freed、
freed：已经释放的，表示该数据块是空的，从来没有使用过。

查看Oracle自动调整undo_retention的值可以通过以下查询获得：

select to_char(begin_time,'mm/dd/yyyy hh34:mi:ss') begin_tiem,TUNED_UNDORETENTION from v$undostat;

undo表空间获取空间的申请顺序
freed=>expired=>自动拓展（必须该参数为yes状态才可以）=>inactive（下面详细解释此种状态的覆盖）=>ORA-30036
而且在使用数据块时尽量使用相对更短的连续extent，如不足时才使用更连续的extent。这样能够减少碎片的产生。并且尽量不去覆盖inactive状态的数据块，如果空间足够会最大限度的保存此种状态的数据块包含的信息。

数据查询出现ORA-1555的原因，和如何避免出现？
ORA-1555错误的出现，共有两种原因。
首先解释一下Oracle在数据变更后，如何保证原始数据能够在变更数据不提交的情况下如何得到保护。
原始数据已经被update、delete等DML操作，但变更数据还未进行commit，此时Oracle通过UNDO段构造与原数据相同的一致性数据块，保证其他用户数据不会出现脏读。但在commit后该事务占用的回滚段事务状态会被标记为不活跃的（inactive），回滚段中此区段可以被覆盖重用。
a、回滚段数据被覆盖
出现原因：如果一个查询需要使用已经变更为inactive并且被覆盖的回滚段一致性读块内的数据，想实现一致性读，那么此时就会出现Oracle著名的ORA-01555错误。原因有SQL语句执行时间太长、UNDO表空间过小、事务量过大，提交过于频繁，导致执行SQL过程中进行一致性读时，修改的原数据（UNDO数据）在UNDO表空间中已经被覆盖，不能构造一致性读块。
避免出现的方法：尽量加大回滚段的容量，尽量将undo_retention参数内的提交后保留时间设置更大一些。如果需要保证原数据在retention保留时间内绝对能够查找，那么在保证回滚段容量足够用的前提下可以将表空间参数中加入 retention guarantee以保证原数据的不被任何情况的覆盖。优化出错的SQL和尽量将大事务分割成小事务，并且不进行频繁的提交。