recover through resetlogs

本文详细记录了一次使用Oracle RMAN进行数据库恢复的过程。包括从全备份恢复、控制文件故障处理、通过resetlogs恢复数据库等多个步骤,并分享了在特定情况下恢复数据库所需的技巧。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

拷贝CP 的全文

1.时间点A,我做了一个全备份,

[ora9i@database rmanarch]$ rman target / nocatalog

Recovery Manager: Release 9.2.0.1.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

connected to target database (not started)

RMAN> startup mount

Oracle instance started
database mounted

Total System Global Area 353440004 bytes

Fixed Size 450820 bytes
Variable Size 150994944 bytes
Database Buffers 201326592 bytes
Redo Buffers 667648 bytes

RMAN> run{allocate channel c3 type disk; backup database format '/backup/oracle/rmanarch/ora9i%t%s.rman';}

allocated channel: c3
channel c3: sid=13 devtype=DISK

Starting backup at 20021130 21:48:59
channel c3: starting full datafile backupset
channel c3: specifying datafile(s) in backupset
including current controlfile in backupset
input datafile fno=00001 name=/backup/oracle/oradata/system.dbf
input datafile fno=00002 name=/backup/oracle/oradata/undo1.dbf
input datafile fno=00003 name=/backup/oracle/oradata/data.dbf
channel c3: starting piece 1 at 20021130 21:49:00
channel c3: finished piece 1 at 20021130 21:49:45
piece handle=/backup/oracle/rmanarch/ora9i4793393402.rman comment=NONE
channel c3: backup set complete, elapsed time: 00:00:45
Finished backup at 20021130 21:49:45
released channel: c3

RMAN> exit

Recovery Manager complete.

由于我没有备份的recovery catalog,我单独备份了这个时候的控制文件,通过OS的拷贝命令。

2。时间点B,我做了一些transaction,
21:50:05 SQL> create table tt tablespace data as select * from dba_objects;

Table created.

Elapsed: 00:00:00.51
21:50:19 SQL> select count(*) from tt;

COUNT(*)
----------
5782

Elapsed: 00:00:00.01
21:50:23 SQL> alter system switch logfile;

System altered.

Elapsed: 00:00:00.04
21:50:27 SQL> /

System altered.

Elapsed: 00:00:02.54
21:50:30 SQL> /

System altered.

Elapsed: 00:00:05.13
这个时候磁盘崩溃,数据库崩溃。
21:50:37 SQL> shutdown abort

我restore database,recover database, resetlogs到时间点B之前的B':
[ora9i@database rmanarch]$ rman target / nocatalog

Recovery Manager: Release 9.2.0.1.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

connected to target database: ORACLE9I (DBID=3143519835)
using target database controlfile instead of recovery catalog

RMAN> run{allocate channel c3 type disk;restore database;recover database until time '20021130 21:50:05';}

allocated channel: c3
channel c3: sid=14 devtype=DISK

Starting restore at 20021130 21:54:34

channel c3: starting datafile backupset restore
channel c3: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /backup/oracle/oradata/system.dbf
restoring datafile 00002 to /backup/oracle/oradata/undo1.dbf
restoring datafile 00003 to /backup/oracle/oradata/data.dbf
channel c3: restored backup piece 1
piece handle=/backup/oracle/rmanarch/ora9i4793393402.rman tag=TAG20021130T214859 params=NULL
channel c3: restore complete
Finished restore at 20021130 21:55:11

Starting recover at 20021130 21:55:11

starting media recovery

archive log thread 1 sequence 22 is already on disk as file /backup/oracle/product/9.2.0/dbs/arch1_22.dbf
archive log filename=/backup/oracle/product/9.2.0/dbs/arch1_22.dbf thread=1 sequence=22
media recovery complete
Finished recover at 20021130 21:55:12
released channel: c3

RMAN> alter database open resetlogs;

database opened

RMAN> exit

我检查在时间点B的事务:表TT,已经看不到了:
21:53:32 SQL> select status from v$instance;

STATUS
------------------------
OPEN

Elapsed: 00:00:00.04
21:55:41 SQL> select count(*) from tt;
select count(*) from tt
*
ERROR at line 1:
ORA-00942: table or view does not exist

Elapsed: 00:00:00.06
21:55:47 SQL> create table ttt tablespace data as select * from dba_objects;

Table created.

Elapsed: 00:00:00.44
21:56:05 SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /backup/oracle/product/9.2.0/dbs/arch
Oldest online log sequence 1
Next log sequence to archive 1
Current log sequence 1
我做了一些事务,比如创建表TTT,
这个时候,我还在做online备份没有完成,或者没有做备份,但是磁盘再次崩溃,丢失了一些数据文件:

我修改initsid.ora文件,把controlfile重新指到A时间点的时候备份的控制文件。
然后我restore database, recover database到B'时间点(就是上次B崩溃的时候,我恢复到的时间点)

RMAN> run{allocate channel c3 type disk;restore database;recover database until time '20021130 21:50:05';}

allocated channel: c3
channel c3: sid=13 devtype=DISK

Starting restore at 20021130 21:57:38

channel c3: starting datafile backupset restore
channel c3: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /backup/oracle/oradata/system.dbf
restoring datafile 00002 to /backup/oracle/oradata/undo1.dbf
restoring datafile 00003 to /backup/oracle/oradata/data.dbf
channel c3: restored backup piece 1
piece handle=/backup/oracle/rmanarch/ora9i4793393402.rman tag=TAG20021130T214859 params=NULL
channel c3: restore complete
Finished restore at 20021130 21:58:15

Starting recover at 20021130 21:58:15

starting media recovery

archive log thread 1 sequence 22 is already on disk as file /backup/oracle/product/9.2.0/dbs/arch1_22.dbf
archive log filename=/backup/oracle/product/9.2.0/dbs/arch1_22.dbf thread=1 sequence=22
media recovery complete
Finished recover at 20021130 21:58:16
released channel: c3

RMAN> shutdown

database dismounted
Oracle instance shut down
这个时候,我再次修改initsid.ora文件里面的controlfile,重新指回到C时间点的控制文件,
我企图打开数据库:
[ora9i@database oradata]$ sql

SQL*Plus: Release 9.2.0.1.0 - Production on Sat Nov 30 21:58:58 2002

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

21:58:58 SQL> startup
ORACLE instance started.

Total System Global Area 353440004 bytes
Fixed Size 450820 bytes
Variable Size 150994944 bytes
Database Buffers 201326592 bytes
Redo Buffers 667648 bytes
Database mounted.
ORA-01190: controlfile or data file 1 is from before the last RESETLOGS
ORA-01110: data file 1: '/backup/oracle/oradata/system.dbf'

但是报错。
我恢复数据库:

21:59:17 SQL> recover database;
Media recovery complete.
22:00:42 SQL> alter database open;

Database altered.

OK,数据库打开。我检查我在时间点C的做的事务:

Elapsed: 00:00:01.64

22:00:52 SQL> select count(*) from ttt;

COUNT(*)
----------
5782

Elapsed: 00:00:00.03
我们可以看到,C时间点我创建的表TTT现在还在。

recover through resetlogs 的关键,在于把数据库先恢复到B'的时间点的状态,然后再根据当前的控制文件的状态来进行恢复。

虽然这样还是再某些条件下可以恢复数据库,但是我们一般都建议,再做了resetlogs之后,马上对数据库做一个全备份。因为recover through resetlogs 还是需要一定的条件和技巧的。不是推荐的标准的备份恢复手段。

______________________________________

from : http://www.itpub.net/110555,2.html

<think>我们正在讨论Oracle数据库中的`ALTERDATABASEOPENRESETLOGS`命令。根据引用[1],这个命令在数据库恢复过程中有重要作用,它会改变数据库的状态并重置在线重做日志文件的信息。现在,我将根据用户的问题,详细解释`RESETLOGS`的使用和场景。首先,我们需要了解`RESETLOGS`的基本作用和应用场景。在Oracle数据库中,当我们进行不完全恢复(即恢复到某个过去的特定时间点,而不是最后提交的事务)后,必须使用`RESETLOGS`选项打开数据库。这是因为不完全恢复会使数据库恢复到过去的某个状态,而重做日志文件中的序列号(logsequencenumber)需要重置,以避免与恢复前的日志序列混淆。具体步骤通常如下:1.进行不完全恢复(例如,使用`RECOVERDATABASEUNTILTIME`或`RECOVERDATABASEUNTILSCN`)。2.然后执行`ALTERDATABASEOPENRESETLOGS`。这个命令会执行以下操作:-重置日志序列号(logsequencenumber)为1。-清空在线重做日志文件的内容(因此,在执行前必须确保有有效的备份)。-创建新的数据库化身(incarnation),这样新的日志序列将从1开始。重要注意事项:-执行`RESETLOGS`后,之前的所有备份和归档日志在正常情况下将不再适用于新化身。因此,必须立即进行全库备份。-如果尝试使用`RESETLOGS`之前的备份进行恢复,需要先使用`RESETDATABASETOINCARNATION`命令将数据库切换到旧的化身。此外,`RESETLOGS`还用于以下场景:-使用备份的控制文件进行恢复后(无论是完全恢复还是不完全恢复)都必须使用`RESETLOGS`打开数据库。-在重建控制文件(使用`CREATECONTROLFILE`命令)时指定了`RESETLOGS`选项,则打开数据库时必须使用`ALTERDATABASEOPENRESETLOGS`。现在,让我们通过一个示例来说明在不完全恢复后使用`RESETLOGS`的步骤:假设我们有一个数据库,需要恢复到某个时间点(例如,由于用户错误删除了重要数据):1.将数据库启动到mount状态:`STARTUPMOUNT`2.进行时间点恢复:`RECOVERDATABASEUNTILTIME'2024-01-01:12:00:00'`3.然后打开数据库:`ALTERDATABASEOPENRESETLOGS`在执行`ALTERDATABASEOPENRESETLOGS`后,Oracle会重置日志序列号,并创建一个新的数据库化身。另外,关于引用[2]和[3],它们分别提到了SQL语言参考中的`CREATERESTOREPOINT`和闪回技术(Flashback)。闪回技术依赖于撤销数据(UNDODATA),可以在不需要不完全恢复的情况下回退错误更改。但是,请注意,闪回技术通常用于更小范围的回退(如表、事务或查询级别),而不完全恢复和`RESETLOGS`则是整个数据库级别的恢复。因此,在可能的情况下,优先考虑使用闪回技术来避免使用`RESETLOGS`,因为`RESETLOGS`会带来一些管理上的复杂性(如备份和恢复策略的调整)。最后,我们生成几个相关问题:§§相关问题§§1.什么情况下必须使用`RESETLOGS`选项打开数据库?2.使用`RESETLOGS`后,之前的备份和归档日志还能使用吗?3.如何解决因`RESETLOGS`导致的数据库化身问题?4.闪回技术和`RESETLOGS`在恢复数据库时有何区别?</think>### Oracle数据库RESETLOGS选项详解 #### **一、核心作用** `ALTER DATABASE OPEN RESETLOGS`是Oracle数据库恢复的关键命令,主要用于: 1. **重置日志序列** - 将在线重做日志序列号重置为1 - 创建新的数据库化身(incarnation)[^1] 2. **清理历史状态** - 清除恢复过程中产生的过时日志链 - 确保数据库以全新日志序列启动 #### **二、典型应用场景** 1. **不完全恢复后** ```sql RECOVER DATABASE UNTIL TIME '2023-01-01:12:00:00'; -- 时间点恢复 ALTER DATABASE OPEN RESETLOGS; -- 强制启动新日志序列 ``` *适用场景*:误删数据后恢复到操作前状态。 2. **备份控制文件恢复** 使用备份控制文件恢复后必须执行`RESETLOGS`[^1]。 3. **物理备用数据库激活** 将Data Guard物理备库切换为主库时: ```sql ALTER DATABASE ACTIVATE STANDBY DATABASE; ALTER DATABASE OPEN RESETLOGS; ``` 4. **日志文件损坏无法复用** 当所有在线日志组损坏且无备份时,需重建控制文件并指定`RESETLOGS`选项。 #### **三、关键操作流程** 1. **前置条件** - 数据库必须处于`MOUNT`状态 - 完成恢复操作(`RECOVER DATABASE`) 2. **执行命令** ```sql ALTER DATABASE OPEN RESETLOGS; ``` 3. **后续强制操作** - **立即全库备份**:旧备份和归档日志失效[^1] - 验证数据文件一致性:`SELECT * FROM v$datafile` #### **四、注意事项** 1. **数据备份失效** - RESETLOGS前所有备份不可直接用于新化身 - 需通过`RESET DATABASE TO INCARNATION`切换化身恢复[^2] 2. **闪回技术限制** - RESETLOGS会清除闪回日志(Flashback Logs) - 无法使用`FLASHBACK DATABASE`回退到RESETLOGS之前[^3] 3. **日志重置影响** ```mermaid graph LR A[原日志序列] -->|序列号100| B[正常恢复] A -->|RESETLOGS| C[新日志序列]-->|序列号1| D[新化身] ``` #### **五、替代方案建议** 优先考虑以下技术避免RESETLOGS: 1. **闪回数据库(Flashback Database)** ```sql FLASHBACK DATABASE TO TIMESTAMP SYSDATE-1/24; -- 回退1小时 ``` *优势*:无需重置日志,保留恢复链[^3] 2. **逻辑恢复工具** - Data Pump导出/导入 - 表空间时间点恢复(TSPITR) > **关键总结**:RESETLOGS数据库恢复的"断点重置"操作,仅在无法通过常规恢复或闪回技术解决时使用。执行后必须立即全备并更新恢复策略[^1][^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值