undo tablespace management

redo是重做，那么undo就是回滚或回退，用于确保数据的一致性。

官网定义翻译如下：oracle数据库创建及管理用于回滚或取消数据库改变的表空间。

undo信息包括了事务操作的记录，更主要的是事务提交前的数据记录，这些记录统称为undo数据。

undo数据库用于以下五方面：

1、当使用rollback语句时回滚事务；

2、恢复数据库；

3、提供读一致性；（当用户查询正在被修改的数据时，可以到undo里查找。）

4、使用oracle闪回查询分析更早时间点的数据。

5、使用oracle闪回特性恢复逻辑上的损坏（和第二点的区别？）

undo表空间有两种管理方式：auto 和 manual，可查看undo_management参数。

1、auto：使用undo tablespace，此时表空间里有多个undo_segment（一般有10个），可通过dba_segments查看。

2、manual：使用回滚段rollback segment，这个回滚段位于system表空间里，会影响数据库性能。

如果没有有效的undo tablespace 或 rollback segment，系统会使用system rollback segment，这种情况是不被推荐的，会产生alter.log告警。

SQL> select tablespace_name,status,SUM(bytes)/1024/1024 "bytes(M)" from dba_undo_extents group by tablespace_name,status;

TABLESPACE_NAME      STATUS  bytes(M)
------------------------------ --------- ----------
UNDOTBS1       UNEXPIRED     5.3125
UNDOTBS1       EXPIRED     5.125

查看表空间里的区使用情况，其中expired是过期了的，可以被覆盖，相当于空闲的空间。

这里通过undo_retention， 来指定 undo  记录保存的最长时间，以秒为单位。

undo_retention是个动态参数，完全可以在实例运行时随时修改，通常默认是 900  秒，也就是 15  分钟。

undo数据被覆盖的情况有两种：

1、15分钟前的undo数据属于“失效”状态，允许被覆盖。

2、当有新数据写入时undo表空间已满，此时不管里面原数据是否已过期都会直接覆盖掉已经提交的事务数据。（事务末结束时undo数据不被覆盖）

要保证undo数据在retention期间内一定有效，则要看参数undo_guarantee:

SQL> alter tablespace undotbs1 retention guarantee; (关闭则是 no guarantee)

SQL> select retention from dba_tablespaces where tablespace_name='UNDOTBS1'; 

RETENTION
-----------
NOGUARANTEE

默认的undo_retention是15分钟，一般无法满足系统的需求，建议改成3个小时，

SQL> alter system set undo_retention = 10800;

但此时undo tablespace的大小就必须根据需要变动了，如果设置为retention guarantee且当表空间已满时，进行DML操作会报错：

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

处理表空间不足的方法有两种：

1、添加undo tablespace的数据文件：SQL> alter tablespace undo add  datafile '/u01/app/oracle/backup/undo02.dbf' size 100m reuse;

2、切换undo tablespace，即新建undotbs2，然后 SQL> alter system set undo_tablespace=undotbs2;（多用于undotbs1的空间已经非常大的情况下）

如果undo tablespace损坏了，则db无法启动，类似报错如下：

ORA-00600: internal error code, arguments: [4194]

如果不能从备份恢复，那么就只能用以下两种方法恢复undo表空间：

方法一：使用system segment

使用system segment启动db，然后删除掉原来的undo tablespace，再新建一个，切换undo_management为auto 。最后按正常情况重启db。

顺序：创建pfile——修改参数undo_management='manual'、rollback_segments='system';——从pfile启动数据库——删除并新建undo tablespace

——关闭数据库——把pfile修改回来undo_management='auto'、undo_tablespace='undotbs1'——用修改后的pfile创建spfile——正常启动数据库。

方法二：跳过损坏的segment

1、修改pfile，添加参数*._corrupted_rollback_segments='_SYSSMU11$','_SYSSMU12$','_SYSSMU13$' （可以从alter log里查看哪些段是损坏的）

2、用修改之后的pfile启动数据库；

3、创建新的undo tablespace并切换；

4、把pfile改回来然后创建spfile，用spfile正常启动数据库。