运维经验：回滚段异常的特殊救急方法

跟着恩墨一起读好书运动开始啦！咱们作为DBA不仅要外部打扮自己，更要从内部武装。近期，小编将分享冷菠老师的《Oracle高性能自动化运维》一部分精选章节分享给大家。如果你对内容很感兴趣，还是要去买一本比较好哦。

购买：https://item.jd.com/12128635.html


冷菠

冷菠，资深DBA，著有《Oracle高性能自动化运维》，有近10年的数据库运维、团队管理以及培训经验。擅长数据库备份恢复、数据库性能诊断优化以及数据库自动化运维等。目前致力于大数据、智能一体化、开源云计算等领域的佳实践探索。

当Oracle回滚段异常时，将会影响CR重构、事务锁定、块清除等与回滚段紧密相关的数据库功能，甚至可能会导致数据库无法正常启动。

因此，在回滚段出现异常后，需要对回滚段进行（特殊）恢复，遵循以下原则：

1、介质恢复（Media Recovery）是首要的恢复方式，能保证数据恢复的一致性和完整性；

2、当介质恢复不能解决问题时，可以考虑使用隐藏参数来进行特殊恢复；

3、特殊恢复作为最后的恢复手段，需要对特殊恢复带来的风险、特殊恢复时间以及恢复失败回退机制等要点进行综合评估，尽可能减少数据的丢失。

NOTE
隐藏参数比较危险，需慎重使用。

隐藏参数

Oracle回滚段特殊恢复相关的隐藏参数主要有：

参数_offline_rollback_segments，如下所示：

参数_corrupted_rollback_segments，如下所示：

其中：

1、隐藏参数_offline_rollback_segments在init.ora初始化参数文件中的格式如下：

*._offline_rollback_segments=(r01,r02,r03)

回滚段r01、r02及r03为需要离线（offline）的回滚段。

2、隐藏参数_corrupted_rollback_segments在init.ora初始化参数文件中的格式如下：

*.rollback_segments=(r01,r02,r03)

*._corrupted_rollback_segments=(r04)

回滚段r01、r02及r03为需要在线使用（onffline）的回滚段，r4为强制异常的回滚段。

场景

Oracle 回滚段隐藏参数用于回滚段异常导致数据库无法正常工作的特殊恢复场景，主要包括：数据库打开、一致读和块清除、回滚段删除。

一、回滚段隐藏参数与数据库打开

在数据库打开的过程中，处于_offline_rollback_segments/_corrupted_rollback_segments参数列表中的回滚段有以下特点：

1、数据库不会检查回滚段头事务表信息，同时，回滚段头的活跃事务也不会被标记为“DEAD”或者“已回滚”状态；

2、回滚段处于离线（Offline）状态；

3、回滚段不能分配给新事务使用。

二、回滚段隐藏参数与一致性读和块清除

对于一致性读与块清除而言，隐藏参数_offline_rollback_segments与_corrupted_rollback_segments在特殊恢复中的作用是不同的。

隐藏参数_offline_rollback_segments：当事务槽处于开启状态（ITL Open）的Block与_offline_rollback_segments参数列表上的回滚段相关时，数据库在重新打开过程中需要检查_offline_rollback_segments列表上的回滚段头事务表信息，获取事务的状态：

1、事务提交（Inactive），块清除；

2、事务未提交（Active），其他Session读取该Block时，则需要应用Undo Record来重构CR Copy。

NOTE

尽管offline_rollback_segments列表上的回滚段被Offline，Oracle仍然会读取这些回滚段来检查事务状态，在回滚段Online后应用Undo Record实现回滚。如果offline_rollback_segments列表中存在与事务相关的回滚段坏块，那么Oracle回滚操作就会失败

隐藏参数_corrupted_rollback_segments：当事务槽处于开启状态（ITL Open）的Block与_corrupted_rollback_segments参数列表上的回滚段相关时，数据库在重新打开过程中不会读取_corrupted_rollback_segments列表上的回滚段事务表信息，这样就可以利用这个特性越过系统对回滚段的检查来尝试启动数据库。

1、如果活跃事务没有提交，将会出现逻辑异常错误，可以使用参数_corrupted_rollback_segments来越过系统检查，尝试启动数据库；

2、当_corrupted_rollback_segments列表中的回滚段被删除后，系统会将“DEAD”状态的事务当作已经被提交，进行延迟块清除。

NOTE

隐藏参数_offline_rollback_segments与_corrupted_rollback_segments的最大区别是：

1、_offline_rollback_segments列表中的回滚段头事务表在数据库打开过程中需要被读取；

2、_corrupted_rollback_segments列表中的回滚段事务表在数据库打开过程中不需要被读取，Oracle会将_corrupted_rollback_segments列表中的回滚段当作已经“Drop”处理。这样的好处就是可以在回滚段异常时，将异常回滚段添加到_corrupted_rollback_segments参数列表中，越过系统检查，从而打开数据库。

如果在ITL被清除前，标记为“corrupted”状态的回滚段被Oracle重用（从_corrupted_rollback_segmens参数列表中移除），这时就需要回滚之前已经提交事务，导致Block逻辑异常。为了避免这些问题，因此建议在使用隐藏参数_corrupted_rollback_segments后，将参数列表中的回滚段删除。

三、回滚段隐藏参数与回滚段删除

在一般情况下，Oracle 回滚段是不能被删除（Drop）的，这是因为回滚段中包含了活动事务（Active）信息，保存了事务恢复的回滚记录。为了保护数据的一致性，Oracle不允许删除有活动事务的回滚段。

在特殊情况下，将存在活动事务的回滚段添加到_corrupted_rollback_segments列表中，就可以忽略回滚段保护机制。也就是说，在数据库启动过程中，处于_corrupted_rollback_segments列表中包含有活动事务的回滚段可以被删除。方法就是将该回滚段添加到_corrupted_rollback_segments列表中。删除活动事务回滚段示例如下：

NOTE

在使用_corrupted_rollback_segments参数后，数据库运行可能比较正常，但是出现问题的潜在风险将增大；删除_corrupted_rollback_segments列表中包含有活动事务的回滚段时，存在逻辑错误的风险以及数据字典异常的风险，这可能将是一种灾难，因此需要慎用该参数；建议在大多数情况下保持数据库的正常启动，尽可能少地使用隐藏参数，规避风险。

实战

当存在活动事务的回滚段表空间出现异常时，可以通过以下步骤进行特殊恢复。

1、创建新的init.ora初始化参数文件（pfile），语法格式如下：

create pfile= path from spfile;

2、修改新init.ora初始化参数文件，将异常回滚段表空间的回滚段添加_corrupted_rollback_segments参数列表中，如下所示：

NOTE

一般情况下，只需要将异常回滚段添加到_corrupted_rollback_segments列表中即可，如果回滚段表空间中所有回滚段都异常，则需要将所有异常的回滚段都添加到_corrupted_rollback_segments列表中。

3、使用修改后的init.ora初始化参数文件启动数据库：

startup restrict pfile= pfile_path 

NOTE

在数据库启动过程中，可以根据需要使用open resetlogs的方式打开数据库（只有部分数据丢失）。

4、在启动成功的数据中创建新的回滚段表空间，语法如下：

create undo tablespace undotbs2 datafile  path  size 16384mautoextend retention noguarantee;

5、删除异常的回滚段表空间，使用以下命令：

alter tablespace undotbs1 offline immediate;

drop tablespace undotbs1 including contents and datafiles;

NOTE
当删除异常的回滚段表空间完成后，_corrupted_rollback_segment列表中只有与活动事务相关的回滚段存在部分数据丢失。这样就保证了数据库正常启动的同时，也尽可能地减少了数据的丢失。

6、使用以下命令，关闭数据库：

shutdown immediate；

7、修改init.ora初始化参数文件，重新配置新的回滚段表空间，如下所示：

8、正常启动数据库，并重建spfile：

startup;

create spfile from pfile= path 

至此，基于隐藏参数的回滚段特殊恢复就告一段落。

原文发布时间为：2017-09-13
本文作者： 冷菠
本文来自云栖社区合作伙伴“数据和云”，了解相关信息可以关注“数据和云”微信公众号

几行代码轻松实现跨系统传递 traceId，再也不用担心对不上日志了！ 新项目查日志太麻烦，多台机器之间查来查去，还不知道是不是同一个请求的。打印日志时使用 MDC 在日志上添加一个 traceId，那这个 traceId 如何跨系统传递呢？
如何避免长事务对业务的影响？ 大家好前面我们大概了解了关于事务的隔离级别，实现方式，启动方式的细节，长事务与短事务的区别。今天我们延伸介绍一下，如果因为失误用了长事务，那我们在工作中如何发现问题，排查问题？