Hello DBA

自从Oracle提供了undo自动管理的功能后，管理undo就变成了一个简单的工作，只需要设置一个足够大的undo表空间和undo_retention参数。但是我们如何衡量undo的空间是否足够了呢？首先我们了解Oracle申请undo空间的过程。

当一个事物需要undo空间时，执行以下步骤：

1.在没有active transaction的undo segment上分配一个extent，oracle尽可能将事物分布在所有的undo segment上。

2.如果没有找到online的segment，则尝试去找offline的segment，并online它。

3.如果没有找到，则创建一个新的undo segment.

4.如果空间不允许，在当前的undo segment上尝试重用expired状态的extent.

如果一个已经运行的事物，需要更多的undo空间时，执行以下步骤：

1.如果当前的extent有free block，则使用它们。

2.如果当前的extent没有free block，并且下一个exent是expired状态，则使用下一个extent.

3.如果下一个extent不是expired状态，那么尝试从undo tablespace获取空间，如果有空闲空间，则为当前的segment分配新的extent.

4.如果没有空闲空间，需要从offline segment上偷extent，先从offline segment上deallocate extent，然后加到当前的undo segment上。

5.如果没有offline segment，则从online segment上偷extent，同样从online segment 上deallocate extent，然后加到当前的undo segment上。

6.尝试扩展数据文件。

7.尝试重用当前undo segment上unexpired状态的extent，如果所有的exetent都繁忙（包含未提交的事务)，则下一步。

8.尝试从offline的segment上偷取unexpired状态的extent.

9尝试从online的segment上偷取unexpired状态的extent.

10.报错ORA-30036：unable to extend segment by %s in undo tablespace ‘%s’

从10g开始，Oracle增加了新的特性，根据undo tablespace的大小和undo的使用状况自动计算undo retention，目的是为了保留尽可能多的undo，v$UNDOSTAT.TUNED_UNDORETENTION字段就反映了这个信息，通过dba_undo_extents表中的status字段，我们可以看到大部分extent处于unexpired状态。所以在10g中，就算我们将undo tablespace设置的足够大，undo_retention设置的足够小，观察dba_free_space和dba_undo_extents，free space和expired extent都是非常小的，但这并不代表undo空间不够用了，根据上面提到的Oracle申请undo空间的过程来看，这些空间都是可以重用的。但是如果设置了Guaranteed UNDO Retention，那情况就不同了，因为Oracle要保证unexpired状态的extent不被覆盖。这个特性可以用_undo_autotune这个隐含参数关闭。

可以通过v$undostat这个视图来判断undo空间是否足够，下面的这个SQL可以计算每秒需要的UNDO大小：

SELECT (UR * (UPS * DBS)) + (DBS * 24) AS “Bytes”
FROM (SELECT value AS UR FROM v$parameter WHERE name = ‘undo_retention’),
(SELECT (SUM(undoblks)/SUM(((end_time – begin_time)*86400))) AS UPS FROM v$undostat),
(select block_size as DBS from dba_tablespaces where tablespace_name=
(select value from v$parameter where name = ‘undo_tablespace’));

一般可以通过以下几个因素来确定undo tablespace的大小：数据库类型（OLTP or DSS)，每秒消耗的undo，SQL查询时间（ORA-1555)等等。

–EOF–