在本文的第一部分，简单的讨论了如何正确地设置Oracle 11g的撤消表空间令其达到最佳效果。这一部分将为大家解密Oracle撤消表空间里会出现的一些典型错误。

　　对于很多开发人员和数据库管理人员来说，撤消表空间往往是带来混乱和疑惑的根源之一。对于撤消表空间引起的诸多问题，数据库管理人员的应对之策往往是修正一下错误的代码，而从来没有真正地了解撤消表空间的内部机制，也不去弄清楚为什么要修正这些代码。所以下面我们会剖析在撤消表空间里会出现的最基本的一些错误。通过打破撤消机制，来让错误无所遁形。

　　首先要牢记，撤消表空间不是什么让人避之唯恐不及的瘟神，UNDO只是Oracle存储的一些用来回滚或进行撤消操作的数据信息。而且，所有的UNDO问题都来源于用户在数据库内部执行的两类DML操作之一，这两类操作简单地说就是：

　　修改DML操作：插入(INSERT)、更新(UPDATE)和删除(DELETE)

　　查询DML操作：选择(SELECT)

　　确实就是这么简单。我们可以简单地认为在数据库内部只有查询 SQL和更新SQL。通常情况下，如果撤消表空间设置调整得当的话，这两类SQL操作就能够共存并共同顺利执行。但是，只要撤消表空间的设置出现一些微小的瑕疵，就会把一切搅乱得一塌糊涂，不论是对单独的更新 SQL而言，还是对不得不试图重构正在发生变化的更新SQL的查询SQL而言。下面我们就来解决这个难题。

　　我们首先创建一个撤消表空间，容量要小，且代表了还没有切换到自动撤消管理的数据库。注意，这里没有使用AUTOEXEND ON从句。SQL语句如下：

　　SQL> CREATE UNDO TABLESPACE undotbs2
　　DATAFILE '/oradata/db11FS/undotbs02.dbf' SIZE 2M;

　　SQL> alter system set undo_tablespace=undotbs2;
 
　　如上所示，我们引入了一个2M大小的静态撤消表空间。当我们开始执行更新SQL操作使其数据容量接近2M时，问题很快就会出现。由于我们没有启用撤消表空间的AUTOEXTEND功能，因此撤消表空间在执行更新操作会话时无法自动扩展容量，所以我们会很快收到Oracle发来的传票：

　　ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS2'

　　这个ORA-30036错误和另外一个执行查询操作的会话一点关系都没有，只和执行更新SQL操作的会话有关。当我们碰到该类型的错误时，要分析起来很简单，一个原因，两个解决方法。原因就是更新会话(很可能正在执行更新操作的会话不止一个)没有为应用程序定义符合撤消表空间可用空间大小的作业单元，基本上就是数据更新太多了，撤消表空间那小小的龙王庙不堪重负了。想要纠正这个错误，你可以选择增加撤消表空间的大小，也可以选择修改应用程序的作业单元(增加更多的提交)。因为存取代码往往比较困难，所以通常会选择增加撤消表空间大小这条路。只是要牢记，增加空间大小并不是一劳永逸的解决办法。我们应该意识到应用程序并没有正确地定义作业单元这个问题的存在，而且这有可能会在接下来的其他操作中导致更严重的问题出现，特别是在接下来要谈到的查询(SELECT)会话中。

　　当有查询会话试图使用数据库而同时更新会话也在进行的时候，就会引发另外一个问题。因为更新会话正在用新数据覆盖撤消表空间的旧数据，所以查询会话将无法正确提取结果集。Oracle里有一个叫“读一致性(read consistency)”的特性，该特性是这样描述的：当查询会话开始从Oracle数据库的表查询数据时，会保持并返回该查询语句开始执行时的行值。如果撤消表空间被过多的更新操作所覆盖，那么要维持这个特性就需要耗费大量的撤消表空间，因此可能会出现以下的错误提示：

    ORA-01555 caused by SQL statement below (SQL ID: 4fwzm0uu3kx8w, Query Duration=15 sec, SCN:0x0000.00181a0e):

　　这就是为什么我们要启用AUTOEXTEND的原因。下面来看看正确的设置和操作方式及其得到的结果。利用本文的第一部分所描述的方法，首先创建一个可自动扩展的撤消表空间：

　　CREATE UNDO TABLESPACE undotbs2 DATAFILE '/oradata/db11FS/undotbs02.dbf' SIZE 2M AUTOEXTEND ON;
　　SQL> SELECT dt.tablespace_name, dt.contents,

　　ddf.file_name, ddf.bytes/1024/1024 size_MEG

　　FROM dba_tablespaces dt,

　　dba_data_files ddf

　　WHERE dt.tablespace_name = ddf.tablespace_name

　　AND dt.contents = 'UNDO';

　　TABLESPACE_NAME CONTENTS FILE_NAME SIZE_MEG

　　--------------- --------- ----------------------------------- --------

　　UNDOTBS1 UNDO /oradata/db11FS/undotbs02.dbf 2
 
　　接着，执行两个对话，其中一个执行大量更新操作，另外一个执行长时间运行的SELECT语句。

　　SQL> INSERT & UPDATE a bunch of rows
　　SQL>> SELECT from those rows being INSERTed and UPDATEd
 
　　两个对话都成功并顺利地执行完毕后，我们可以重新查询撤消表空间的大小，从返回结果可以看到已经扩展为11.5M了。没有出现任何错误，也不需要担心空间大小的管理。

　　SQL> SELECT dt.tablespace_name, dt.contents,
　　ddf.file_name, ddf.bytes/1024/1024 size_MEG

　　FROM dba_tablespaces dt,

　　dba_data_files ddf

　　WHERE dt.tablespace_name = ddf.tablespace_name

　　AND dt.contents = 'UNDO';

　　TABLESPACE_NAME CONTENTS FILE_NAME SIZE_MEG

　　--------------- --------- ----------------------------------- ----------

　　UNDOTBS2 UNDO /oradata/db11FS/undotbs02.dbf 11.5