一、恢复解决方案

错误类型及解决方案

注意：恢复依赖于备份，当生产环境中部署完成就应该确保有一次数据库的全库备份，且确保归档Redo日志被打开。

二、SCN时间机制

SCN（System Change Number，系统改变号）是Oracle内容非常重要的时间机制，一致性、数据恢复都与SCN有着非常密切的关系。Oracle启动时，也是通过SCN的验证来确认数据库是否需要执行实例恢复的。虽然RAC有多个实例，但是只有一个数据库，SCN是对应数据库级别的改变号，所以在不同的实例产生的SCN都必须是唯一的、有序的，这是由SCN生成器完成的工作。系统时间和SCN之间可以非常容易的相互转换，下面是系统时间和SCN相互转换的例子：

SQL> select timestamp_to_scn(sysdate) from dual;

TIMESTAMP_TO_SCN(SYSDATE)

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

               6980593

SQL> select scn_to_timestamp(6980593) from dual;

SCN_TO_ TIMESTAMP (6980593)

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

02-DES-13 11.12.21.000000000 PM

SQL>

以下为几种常见的SCN：

?  检查点SCN

查询当前最近的检查点SCN：

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

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

        3.6555E+12

SQL>

每执行一次检查点就由CKPT进程来更新，这个SCN保存在控制文件中。检查点的执行能够确保检查点执行时刻数据的完整性和一致性。实例恢复也是从上一次检查点开始进行恢复，检查点执行的频率决定了Crash恢复或者实例恢复需要花费的时间。当发生日志切换或者请求的SGA空间不足等情况时就会触发检查点。发生检查点，DBWn进程会将所有的脏数据写回磁盘，从而能够确保已提交的一致性数据被写回磁盘。单个联机Redo日志文件越大，发生检查点的间隔时间可能越长，实例恢复的时间也相应地增长，日志文件的丢失也会导致更多的数据丢失。

?  最新SCN

执行以下SQL语句查看数据库最新的SCN：

SQL> select current_scn from v$database;

CURRENT_SCN

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

3.6555E+12

SQL>

该SCN是最新生成的全局SCN，它在不断更新，并且只会增大不会减小。

?  数据文件SCN

执行以下SQL查看所有数据文件的SCN：

SQL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

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

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

6 rows selected.

SQL>

每个数据文件都有一个数据文件SCN，每执行一次检查点便由CKPT进程来更新一次，该SCN保存在控制文件中。

?  启动SCN

执行以下SQL语句查询所有数据文件的启动SCN：

SQL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#

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

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

        3.6555E+12

6 rows selected.

SQL>

每个数据文件都有一个启动SCN，没执行一次检查点都由CKPT进程来更新一次，该SCN存储在数据文件头中。

?  终止SCN

执行下面SQL语句查询所有数据文件的终止SCN：

SQL> select last_change# from v$datafile;

LAST_CHANGE#

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

6 rows selected.

SQL>

        每个数据文件都有一个终止SCN，没执行一次检查点都由CKPT进程更新一次。该SCN保存在控制文件中，当数据库打开时，由于没有终止SCN存在，所以看到的是空，表示无穷大。

        数据库启动过程中，首先会检查控制文件和数据文件的检查点执行次数是否一致，如果不一致需要对数据文件进行介质恢复。如果一致，进一步检查数据文件的启动SCN和终止SCN是否相同。如果数据库是非正常关闭，那么终止SCN肯定是空，这个时候需要执行Crash恢复或实例恢复的过程。Crash恢复或实例恢复过程需要用到联机Redo日志和UNDO表空间执行前滚和回滚操作，如果联机Redo日志或者UNDO表空间被损坏，那么数据库可能无法正常打开。如果启动SCN和终止SCN相同，那么数据库就可以正常打开。

?  日志SCN

执行以下SQL语句查询与日志相关的SCN：

SQL> select status,first_time,first_change#,next_time,next_change# from v$log;

STATUS               FIRST_TIME     FIRST_CHANGE# NEXT_TIME      NEXT_CHANGE#

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

INACTIVE             02-12鏈13        3.6555E+12 02-12鏈13       3.6555E+12

CURRENT              02-12鏈13        3.6555E+12                  2.8147E+14

CURRENT              02-12鏈13        3.6555E+12                  2.8147E+14

INACTIVE             02-12鏈13        3.6555E+12 02-12鏈13       3.6555E+12

SQL>

    在上面查询中，first_time表示该日志组开始的时间，first_change#表示该日志组开始的SCN。可以看到，状态为current的日志组的first_change#值与前面讨论到的检查点的SCN值相同，说明发生日志切换的时候会触发检查点生成一致的检查点SCN。Next_time表述结束日志组的时间，next_change#表示结束日志组的SCN，该SCN值等于下一个日志组的first_change#值。当前日志组的next_time为空，next_change#是一个很大的值。

三、日志线程与联机Redo日志

Redo日志记录了数据的所有操作，以及操作的顺序。Redo日志主要包括联机Redo日志、归档Redo日志和Standby Redo日志三种类型，这三种类型的日志在结构上是完全相同的，只有用途不同而已。

Redo数据只有在数据库恢复时才能体现出它的价值。在RAC环境中，每个实例的归档Redo日志可以存放在本地文件系统，但是恢复的时候需要将所有节点的归档Redo日志放在一起，确保恢复的实例能够访问到所有实例的归档Redo日志。

每个实例都对应一个维护日志的日志线程（Redo thread），单实例只有一个线程号为1的日志线程。对于RAC来说，日志线程与实例的关系可以通过以下SQL语句查询得到。

1）   查询来自控制文件的线程信息：

SQL> select thread#,checkpoint_change#,last_redo_change# from gv$thread;

   THREAD# CHECKPOINT_CHANGE# LAST_REDO_CHANGE#

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

         1         3.6555E+12        3.6555E+12

         2         3.6555E+12        3.6555E+12

         1         3.6555E+12        3.6555E+12

         2         3.6555E+12        3.6555E+12

SQL>

2）   查询线程与实例之间的关系：

SQL> select thread#,instance_name from gv$instance;

   THREAD# INSTANCE_NAME

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

         1 PROD1

         2 PROD2

SQL>

3）  查询线程与日志组之间的关系：

SQL> select group#,thread# from v$log;

    GROUP#    THREAD#

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

         1          1

         2          1

         3          2

         4          2

SQL>

四、UNDO表空间

UNDO表空间存放的是数据块的前镜像，是块的多版本数据，用于数据库恢复、一致性读和事务回滚，对数据库并发下读一致性起着重要的作用。

在RAC环境中，与连接Redo日志一样，每个实例都有自己的UNDO表空间，UNDO表空间必须放在共享存储上，每个实例都能访问到所有实例的UNDO表空间，以便任一活动实例都能执行所有实例的恢复操作。每个实例都有自己独立的UNDO表空间还能减少实例间对UNDO表空间的争用。

实例对应的Redo日志组由Redo线程来指定，实例对应的UNDO表空间是直接通过初始化参数文件中的参数指定。下面是参数文件中指定UNDO表空间对应实例的参数：

Prod01.undo_tablespace = ‘UNDOTBS1’

Prod02.undo_tablespace = ‘UNDOTBS2’

1.       UNDO参数

l   UNDO_MANAGEMENT初始化参数

UNDO_MANAGEMENT指定系统使用的UNDO空间管理模式。设置为AUTO，实例打开自动化UNDO管理模式；设置为MANUAL表示使用回滚段的手动管理模式自动UNDO管理（AUM）是从Oracle9i开始引入，以代替回滚段，也可以称为系统管理UNDO（SMU）。自动UNDO管理自动分配和管理DML操作所需空间的UNDO表空间，代替分配很多不同大小的回滚段。

l   UNDO_RETENTION初始化参数

UNDO_RETENTION指定的是事务提交之后UNDO数据保留的时间。事务提交之后，UNDO数据不再需要用于回滚或者事务恢复，但一致性读可能还需要用到这些UNDO数据。

l   UNDO_TABLESPACE初始化参数

每个数据库可以有多个UNDO表空间，但是对于每个实例只有一个活动的UNDO表空间。在RAC环境中，每个实例都对应一个UNDO表空间，UNDO_TABLESPACE用于指定实例对应的UNDO表空间。UNDO表空间无法进行收缩，如果UNDO表空间过大，只有通过替换的方式缩小UNDO表空间的大小。

l   GUARANTEED UNDO RETENTION特性

默认guaranteed undo retention特性是禁用的，如果启动这个特性意味着数据库不能覆盖已提交但保留时间为超过undo_retention指定时间的UNDO数据。启用这个特性需要更大的UNDO表空间来支撑，如果UNDO表空间没有足够的空间会导致DML操作分配UNDO段失败。启用这个特性能够缓解出现ORA-01555错误几率，确保在一定的时间内能够使用部分Flashback特性闪回数据。执行以下SQL语句启用UNDO表空间的RETENTION特性：

SQL> alter tablespace undotbs1 retention guarantee;

2.       UNDO视图

l   V$undostat视图

V$undostat是v$rollstat的代替和提升，包含很多对UNDO空间的监控和统计信息。这个视图对于了解实例对UNDO空间的使用情况非常有用，能够通过监控估算出当前负载需要的UNDO表空间大小，能够根据统计信息提供建议调整UNDO_RETENTION，还能够找出长时间运行的SQL语句。在系统中，数据也使用这个视图提供的信息调整UNDO表空间的使用。只有自动化UNDO管理模式才能使用该视图。

l   dba_undo_extents视图

dba_undo_extents描述了在数据中所有undo表空间包含的区间。这个视图显示UNDO中每个区间大小。执行以下SQL语句显示UNDO表空间中不同区间状态的统计信息。

l   v$transaction

l   dba_rollabck_segs视图