摘要 当用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.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。
3.使用操作系统命令拷贝当前控制文件到另外的位置。
5. 启动目标实例到nomount状态,startup nomount。
6.运行RESET DATABASE TO INCARNATION inc_key command,允许rman复原resetlogs前的备份,inc_key是前一个incarnation的唯一标识。
Set until scn resetlogs_scn;
Allocate channel c1 device type diak;
Restore controlfile;
Alter database mount;
Restore datafile;
Recover database;
}
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/