Open Resetlogs操作对oracle数据库恢复的影响

摘要 当用resetlogs选项打开ORACLE数据库的时，要重置联机日志文件序号，产生一个新的数据库形态（（incarnation），本文着中介绍在各种oracle数据库版本下，如何利用resetlogs点之前的备份进行数据库恢复操作。

1 概述

oracle数据库执行不完全恢复或使用备份控制文件恢复后，需要用resetlogs选项打开数据库，这时oracle重置联机日志序号，该重置数据库称为oracle数据库的一个新形态（incarnation）。图1说明形成新的数据库形态的过程：假设在日志序列号4000时，oracle数据库发生介质损坏，复原日志序列号1000时的备份，恢复数据库到日志序列号2500，接着用resetlogs选项打开数据库，这时将重置联机日志序列号为1，开始新的数据库运行，形成一个新的数据库形态。

图1

当用resetlogs选项打开数据库后，一般情况下不能使用resetlogs点之前的备份进行数据库恢复，也就是Resetlogs操作对oracle数据库恢复造成了不利的影响，因此强烈建议在重置联机日志文件后，做一个一致性的全库备份，这一点有些dba容易忽略，以至于在数据库出现介质损坏时，对数据库的恢复造成较大的麻烦。但是随着oracle10g的出现，对这个问题做了改进，可以有条件的使用resetlogs点前的备份进行恢复且能穿越resetlogs点，条件是存在备份点以来的所有归档日志和最近的控制文件，即要求该控制文件有以前的incarnation 记录。下面主要介绍对于不同版本的oracle数据库执行resetlogs操作后，没有做数据库备份，但数据库又出现了介质失败，如何进行数据库恢复。首先声明一下本文涉及的所有备份恢复操作均使用oracle的rman工具。

2 resetlogs操作对数据库的影响

2．1 首先说明用resetlogs操作打开数据库时，重置联机日志的操作过程：

1． 归档当前联机日志，接着清除联机日志的内容并重置日志顺序号为1。

2． 如果联机日志文件不存在，创建联机日志文件。

3． 初始化控制文件中关于联机日志和重做线程的元数据。

4． 用resetlogs scn和时戳（time stamp）更新控制文件、联机日志文件、数据文件的头部以及以后的归档日志。

另外，resetlogs操作会记录在Alert文件中，以下是某次resetlogs操作在Alert文件中的记录：

alter database open resetlogs

RESETLOGS after incomplete recovery UNTIL CHANGE 233039

Resetlogs scn为233039，也就是数据库在scn 233039+1=233040处执行一次resetlogs打开，233040转换为16进制是：38e50,即在38e50进入下一个incarnation。

下面是对数据库执行resetlogs操作前后，数据文件，控制文件和联机日志文件中resetlogs SCN和计数器（counter）改变的测试，通过转储这些文件，可以对比各个文件中resetlogs SCN和计数器（counter）的变化：

2.2 resetlogs操作前各种文件的转储（DUMP）

1．数据文件转储（DUMP）

alter session set events 'immediate trace name file_hdrs level 10';

DATA FILE #1:

(name #8) C:ORACLEORADATAYXYUPSYSTEM01.DBF

FILE HEADER:

reset logs count:0x2433aaa2 scn: 0x0000.0002e872 recovered at 12/29/2006 14:19:45

2．控制文件转储（DUMP）

alter session set events 'immediate trace name controlf level 10';

DATABASE ENTRY

Resetlogs scn: 0x0000.0002e872 Resetlogs Timestamp 11/24/2006 16:43:14

Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp 05/12/2002 16:16:56

INCARNATION RECORDS

Earliest record:

RECID #1 Recno 1 Record timestamp

Resetlogs scn and time scn: 0x0000.0002e872 11/24/06 16:43:14

Previous Resetlogs scn and time scn: 0x0000.00000001 05/12/02 16:16:56

Latest record:

RECID #1 Recno 1 Record timestamp

Resetlogs scn and time scn: 0x0000.0002e872 11/24/06 16:43:14

Previous Resetlogs scn and time scn: 0x0000.00000001 05/12/02 16:16:56

3．REDOFILE的转储（DUMP）

SQL> alter session set events 'immediate trace name redohdr level 10';

DUMP OF LOG FILES: 3 logs in database

LOG FILE #1:

(name #3) C:ORACLEORADATAYXYUPREDO01.LOG

FILE HEADER:

reset logs count: 0x2433aaa2 scn: 0x0000.0002e872

2.3 resetlogs操作后各种文件的转储（DUMP）

1.数据文件转储（DUMP）

alter session set events 'immediate trace name file_hdrs level 10';

DATA FILE #1:

(name #8) C:ORACLEORADATAYXYUPSYSTEM01.DBF

FILE HEADER:

reset logs count: 0x249a8415 scn: 0x0000.00038e50

2.控制文件转储（DUMP）

alter session set events 'immediate trace name controlf level 10';

DATABASE ENTRY

Resetlogs scn: 0x0000.00038e50 Resetlogs Timestamp 02/09/2007 17:02:13

Prior resetlogs scn: 0x0000.0002e872 Prior resetlogs Timestamp 11/24/2006 16:43:14

INCARNATION RECORDS

Earliest record:

RECID #1 Recno 1 Record timestamp

Resetlogs scn and time scn: 0x0000.0002e872 11/24/06 16:43:14

Previous Resetlogs scn and time scn: 0x0000.00000001 05/12/02 16:16:56

Latest record:

RECID #2 Recno 2 Record timestamp

Resetlogs scn and time scn: 0x0000.00038e50 02/09/07 17:02:13

Previous Resetlogs scn and time scn: 0x0000.0002e872 11/24/06 16:43:14

RECID #1 Recno 1 Record timestamp

Resetlogs scn and time scn: 0x0000.0002e872 11/24/06 16:43:14

Previous Resetlogs scn and time scn: 0x0000.00000001 05/12/02 16:16:56

3.REDOFILE的转储（DUMP）

alter session set events 'immediate trace name redohdr level 10';

DUMP OF LOG FILES: 3 logs in database

LOG FILE #1:

(name #3) C:ORACLEORADATAYXYUPREDO01.LOG

FILE HEADER:

reset logs count: 0x249a8415 scn: 0x0000.00038e50

从以上转储文件可以看到控制文件中保存resetlogs SCN和计数器，唯一地标识用RESETLOGS选项执行的每一次打开数据库的操作。这个值也写进每个数据文件以及重做日志文件头。执行数据库恢复时，oracle将比较数据文件头部和归档日志的RESETLOGS SCN and time stamps，如果他们不匹配，数据库将不应用归档日志，这样阻止对数据文件可能造成的损坏。resetlogs操作会修改控制文件和其它各种文件的头信息，记录本次resetlogs操作。

3 用resetlogs操作前的备份恢复数据库的可能性

3.1 根据前面的叙述，在oracle10g中可以有条件的轻易的穿越resetlogs点进行恢复，而对于oracle9i以前的版本怎么恢复？

我们知道，Oracle数据库中有一个scn(system change number)号,用来记录数据库的变化，它是由数据库维护且单调递增的数字，数据库的操作不会改变SCN的递增性，即使是RESETLOGS也如此， RESETLOGS只是重置日志文件的序列号为1，但对SCN无影响，SCN仍按原序列递增。根据数据库恢复理论，Oracle恢复操作主要根据SCN进行，所有数据文件必须恢复到同一时间点，并在该点后未作任何改动，才能打开数据库。根据以上分析，在数据库生命周期期间SCN为始终递增的顺序数据流，虽然RESETLOGS操作会重置日志文件的序列号，但RESETLOGS操作前后的日志文件序列流中的SCN序列流却保持递增不变。因此可以用RESETLOGS之前的归档日志流和RESETLOGS之后的归档日志流来连接和延续SCN序列流，这样就实现了用RESETLOGS之前的备份恢复RESETLOGS之后的数据。前提是保证两股日志流（RESETLOGS之前的归档日志流和RESETLOGS之后的归档日志流）完整，并且有相应两股日志流的控制文件。这就是用两步法实现恢复的主要理论依据。

根据以上理论，对于oracle9i以前的数据库可以采用一种称为两步法的方法穿越resetlogs进行恢复，但不是所有情况都能恢复，还必须满足一定条件。

1． 存在resetlogs点前的控制文件备份。

2． 当前控制文件存在或存在resetlogs点后的控制文件备份。

3． 能够获取resetlogs scn，resetlogs scn为数据库用resetlogs选项打开时对应的scn。

4． 数据文件的备份是最近resetlogs点前的备份。

5． 有备份点到resetlogs scn的归档日志。

6． 存在RESETLOGS SCN到恢复点之间的归档日志。

3.2 在两步恢复方法中，获取准确的resetlogs scn至关重要。可以通过下面三种方式获得resetlogs scn：

1．检查alert_SID.log文件，寻找行: RESETLOGS after incomplete recovery UNTIL CHANGE 1234. 其中1234 就是resetlogs scn.

2． 查询V$DATABASE，得到RESETLOGS_CHANGE#，resetlogs scn= RESETLOGS_CHANGE#-1，可以执行：

SELECT (RESETLOGS_CHANGE#)-1 FROM V$DATABASE;

3。在rman中运行LIST INCARNATION，resetlogs scn= Reset SCN -1。

3.3 下面主要描述一下oracle9i以前版本使用的两步法的恢复过程：

3.3.1 首先介绍第一个阶段，复原数据库并恢复到resetlogs scn。

1. 根据前面介绍的方法获得RESETLOGS SCN。

2. 用abort关闭数据库。

3．使用操作系统命令拷贝当前控制文件到另外的位置。

4. 启动rman并连接到目标数据库和恢复目录。

5. 启动目标实例到nomount状态，startup nomount。

6．运行RESET DATABASE TO INCARNATION inc_key command,允许rman复原resetlogs前的备份，inc_key是前一个incarnation的唯一标识。

7. 执行如下run命令块，实现第一阶段恢复：

Run{

Set until scn resetlogs_scn;

Allocate channel c1 device type diak;

Restore controlfile;

Alter database mount;

Restore datafile;

Recover database;

}

8. 用immediate选项关闭数据库。

3.3.2 第一个阶段完成后，开始第二阶段的操作：

1. 复原resetlogs操作后的控制文件备份或当前控制文件。

2. 启动数据库实例到nomount。

3. 运行RESET DATABASE TO INCARNATION inc_key 命令，使数据库的INCARNATION为当前incarnation。

4. mount数据库。

5. 恢复数据库到期望的点。

6。打开数据库，并执行全库备份。

4 关于Oracle10g穿越resetlogs点进行恢复的情况

4．1 在oracle10g中可以使用resetlogs点前的备份轻易的进行恢复且能穿越resetlogs点，只要求存在备份点以来的所有归档日志和控制文件。Oracle10g之所以能够这样做，是因为oracle10g 对于归档日志文件的格式引入了新的格式符%r，它表示resetlogs id，包含在log_archive_format参数的默认格式中。这避免了执行resetlogs操作后，因为相同的日志顺序号而覆盖前一incarnation产生的归档日志，保证了归档日志具有唯一的名称。例：

SQL> show parameter log_archive_format
NAME TYPE VALUE
----------------------- ----------- ----------------
log_archive_format string %t_%s_%r.dbf

另外一点是在以前的版本中，在resetlogs操作期间，要清除v$log_history 和 v$offline_range 中的记录，在oracle10g中为了支持穿越resetlogs点的恢复，动态性能视图V$LOG_HISTORY和 V$OFFLINE_RANGE做了以下修改：

1．

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9599/viewspace-473006/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9599/viewspace-473006/