RAC 之 RMAN 恢复

RAC 下的RMAN 讲究的是备份和还原的策略要一致。备份策略的不同，会导致备份结果的分步不同，进而影响恢复的策略和步骤。一般情况下，恢复策略和备份策略必须是对应的。如果备份策略进行了修改，那么恢复也应该采用相同的策略。之前我们的RMAN 备份参考：

RAC 之 RMAN 备份

http://blog.csdn.net/tianlesoftware/archive/2010/09/22/5901053.aspx

这里面有2个注意事项：

1.       执行恢复的节点要能看到所有节点的归档文件。 这个在RAC 备份那篇里已经讲了方法，就是把归档文件传送到其他节点，这样就能够看到所有节点的归档文件了。

2.       备份集的存放问题。 如果我们放在共享设备上，那么节点可以访问所有的备份文件，那么就可以直接进行恢复操作。 如果不是放在共享设备，可以通过NFS mount来挂载，或者设置2个通道。 分别指向多个实例。

示例：

1.1 先停止数据库

[[email protected] bin]$ srvctl stop db -d orcl

[[email protected] bin]$ crs_stat -t

Name           Type           Target    State     Host

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

ora.orcl.db    application    OFFLINE   OFFLINE

ora....oltp.cs application    OFFLINE   OFFLINE

ora....cl1.srv application    OFFLINE   OFFLINE

ora....cl2.srv application    OFFLINE   OFFLINE

ora....l1.inst application    OFFLINE   OFFLINE

ora....l2.inst application    OFFLINE   OFFLINE

ora....SM1.asm application    ONLINE    ONLINE    rac1

ora....C1.lsnr application    ONLINE    ONLINE    rac1

ora.rac1.gsd   application    ONLINE    ONLINE    rac1

ora.rac1.ons   application    ONLINE    ONLINE    rac1

ora.rac1.vip   application    ONLINE    ONLINE    rac1

ora....SM2.asm application    ONLINE    ONLINE    rac2

ora....C2.lsnr application    ONLINE    ONLINE    rac2

ora.rac2.gsd   application    ONLINE    ONLINE    rac2

ora.rac2.ons   application    ONLINE    ONLINE    rac2

ora.rac2.vip   application    ONLINE    ONLINE    rac2

1.2 将节点启动到mount 状态：

备份集存在在2个节点的情况（2个节点的RAC），在这种情况下，需要分配2个通道分别连接对应的节点。 每个节点都需要启动到mount状态。 因为每个节点都有备份文件，所以在每个节点都需要执行restore，如果没有启动的话，就会报错，对于备份集存放在共享设备的就不用这么麻烦。

[[email protected] bin]$ export ORACLE_SID=orcl1

[[email protected] bin]$ rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Mon Sep 27 02:56:55 2010

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database (not started)

RMAN> startup mount;

Oracle instance started

database mounted

Total System Global Area     180355072 bytes

Fixed Size                     1218388 bytes

Variable Size                100665516 bytes

Database Buffers              75497472 bytes

Redo Buffers                   2973696 bytes

[[email protected] bin]$ export ORACLE_SID=orcl2

[[email protected] bin]$ rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Mon Sep 27 02:57:44 2010

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database (not started)

RMAN> startup mount;

Oracle instance started

database mounted

Total System Global Area     180355072 bytes

Fixed Size                     1218388 bytes

Variable Size                 83888300 bytes

Database Buffers              92274688 bytes

Redo Buffers                   2973696 bytes

1.3            完全恢复

在任意一个节点上执行：

RMAN> RUN {

allocate channel c1 device type disk connect  ‘sys/[email protected]‘;

allocate channel c2 device type disk connect  ‘sys/[email protected]‘;

restore database;

recover database;

}

2> 3> 4> 5> 6>

using target database control file instead of recovery catalog

allocated channel: c1

channel c1: sid=146 instance=orcl1 devtype=DISK

allocated channel: c2

channel c2: sid=146 instance=orcl2 devtype=DISK

Starting restore at 27-SEP-10

skipping datafile 2; already restored to file +DATA/orcl/datafile/undotbs1.278.730181053

skipping datafile 3; already restored to file +DATA/orcl/datafile/sysaux.277.730181053

skipping datafile 5; already restored to file +DATA/orcl/datafile/undotbs2.284.730181347

skipping datafile 1; already restored to file +DATA/orcl/datafile/system.276.730181051

skipping datafile 4; already restored to file +DATA/orcl/datafile/users.279.730181053

skipping datafile 7; already restored to file +DATA/orcl/datafile/anhuianqing.dbf

Finished restore at 27-SEP-10

Starting recover at 27-SEP-10

starting media recovery

media recovery complete, elapsed time: 00:00:04

Finished recover at 27-SEP-10

released channel: c1

released channel: c2

RMAN> sql ‘alter database open‘;

sql statement: alter database open

1.4 不完全恢复

1.4.1基于时间点的恢复

RMAN> RUN {

allocate channel c1 device type disk connect  ‘sys/[email protected]‘;

allocate channel c2 device type disk connect  ‘sys/[email protected]‘;

set until time "to_date(‘2010/9/27 03:30:00‘,‘yyyy/mm/dd hh24:mi:ss‘)";

restore database;

recover database;

}

2> 3> 4> 5> 6> 7> 8>

allocated channel: c1

channel c1: sid=143 instance=orcl1 devtype=DISK

allocated channel: c2

channel c2: sid=146 instance=orcl2 devtype=DISK

executing command: SET until clause

Starting restore at 27-SEP-10

channel c1: starting datafile backupset restore

channel c1: specifying datafile(s) to restore from backup set

restoring datafile 00001 to +DATA/orcl/datafile/system.276.730181051

restoring datafile 00004 to +DATA/orcl/datafile/users.279.730181053

restoring datafile 00007 to +DATA/orcl/datafile/anhuianqing.dbf

channel c1: reading from backup piece /u01/backup/orcl_2blotmnp_1_1_20100927

channel c2: starting datafile backupset restore   -- 这里使用了2个通道，因为这个测试的备份集是放在2个节点的。

channel c2: specifying datafile(s) to restore from backup set

restoring datafile 00002 to +DATA/orcl/datafile/undotbs1.278.730181053

restoring datafile 00003 to +DATA/orcl/datafile/sysaux.277.730181053

restoring datafile 00005 to +DATA/orcl/datafile/undotbs2.284.730181347

channel c2: reading from backup piece /u01/backup/orcl_2clotmno_1_1_20100927

channel c2: restored backup piece 1

piece handle=/u01/backup/orcl_2clotmno_1_1_20100927 tag=ORCL_HOT_DB_BK

channel c2: restore complete, elapsed time: 00:01:21

channel c1: restored backup piece 1

piece handle=/u01/backup/orcl_2blotmnp_1_1_20100927 tag=ORCL_HOT_DB_BK

channel c1: restore complete, elapsed time: 00:02:48

Finished restore at 27-SEP-10

Starting recover at 27-SEP-10

starting media recovery

media recovery complete, elapsed time: 00:00:03

Finished recover at 27-SEP-10

released channel: c1

released channel: c2

RMAN>

恢复完成之后，在两个节点执行：

alter database open resetlogs;

打开数据即可。

1.4.2 基于SCN的恢复

当前SCN 查看方法：

SQL> select current_scn from v$database;

CURRENT_SCN

-----------

1118216

RMAN> RUN {

allocate channel c1 device type disk connect  ‘sys/[email protected]‘;

allocate channel c2 device type disk connect  ‘sys/[email protected]‘;

restore database until scn 1118215 ;

recover database until scn 1118215 ;

}

2> 3> 4> 5> 6>

using target database control file instead of recovery catalog  -- 非catalog 模式， 这种模式备份控制文件非常重要

allocated channel: c1

channel c1: sid=142 instance=orcl1 devtype=DISK

allocated channel: c2

channel c2: sid=151 instance=orcl2 devtype=DISK

Starting restore at 27-SEP-10

channel c1: starting datafile backupset restore

channel c1: specifying datafile(s) to restore from backup set

restoring datafile 00001 to +DATA/orcl/datafile/system.276.730181051

restoring datafile 00004 to +DATA/orcl/datafile/users.279.730181053

restoring datafile 00007 to +DATA/orcl/datafile/anhuianqing.dbf

channel c1: reading from backup piece /u01/backup/orcl_2blotmnp_1_1_20100927

channel c2: starting datafile backupset restore

channel c2: specifying datafile(s) to restore from backup set

restoring datafile 00002 to +DATA/orcl/datafile/undotbs1.278.730181053

restoring datafile 00003 to +DATA/orcl/datafile/sysaux.277.730181053

restoring datafile 00005 to +DATA/orcl/datafile/undotbs2.284.730181347

channel c2: reading from backup piece /u01/backup/orcl_2clotmno_1_1_20100927

channel c2: restored backup piece 1

piece handle=/u01/backup/orcl_2clotmno_1_1_20100927 tag=ORCL_HOT_DB_BK

channel c2: restore complete, elapsed time: 00:03:58

channel c1: restored backup piece 1

piece handle=/u01/backup/orcl_2blotmnp_1_1_20100927 tag=ORCL_HOT_DB_BK

channel c1: restore complete, elapsed time: 00:05:47

Finished restore at 27-SEP-10

Starting recover at 27-SEP-10

starting media recovery

archive log thread 1 sequence 44 is already on disk as file /u02/rac1_arch/1_44_730181171.dbf

archive log thread 2 sequence 38 is already on disk as file /u02/rac1_arch/2_38_730181171.dbf

archive log thread 1 sequence 1 is already on disk as file /u02/rac1_arch/1_1_730784806.dbf

archive log thread 2 sequence 1 is already on disk as file /u02/rac2_arch/2_1_730784806.dbf

archive log filename=/u02/rac1_arch/1_44_730181171.dbf thread=1 sequence=44

archive log filename=/u02/rac1_arch/2_38_730181171.dbf thread=2 sequence=38

archive log filename=/u02/rac2_arch/2_1_730784806.dbf thread=2 sequence=1

media recovery complete, elapsed time: 00:00:09

Finished recover at 27-SEP-10

released channel: c1

released channel: c2

恢复结束，用 alter database open resetlogs 打开数据库。

小结：

以上都是简单的测试，具体情况还是要具体对待。 经验积累的多了，就知道怎么处理了。 总之，备份重于一切。 有了备份，才有恢复的可能。

转：http://blog.csdn.net/tianlesoftware/article/details/5909912

时间： 2024-10-12 20:16:26

RAC 之 RMAN 恢复的相关文章

RAC之RMAN恢复

之前整理的RMAN 有关还原的文章: RMAN 系列(五) ---- RMAN 还原 与 恢复 http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5700474.aspx RMAN 备份与恢复 实例 http://blog.csdn.net/tianlesoftware/archive/2009/10/20/4699320.aspx Oracle Rman跨resetlogs版本恢复 http://blog.csdn.net/tianl

Oracle 11g R2 rac通过rman 恢复到单实例数据库

生产环境是2个节点的rac + dataguard(物理备库也是两个节点的rac),通过rman每天进行备份,现在需要定期对生产库进行恢复操作 恢复步骤如下: 1.      把生产库的备份拷贝到目标端 建立存放备份的目录修改目录属主属组 mkdir /oracle/backup chown oracle:oinstall /oracle/backup 2.      拷贝备份到目标端 scp -P 22 incremental_level*  [email protected]:/oracle

Oracle 11g单实例RMAN恢复到Oracle 11g RAC

一.环境说明 操作系统版本: RHEL 6.5 x64 1. 源数据库服务器 Oracle版本: Oracle 11g 11.2.0.4 64位(单机)Oracle_SID: orcl db_name   : orcl 背景:一台生产oracle10g(10.2.0.5)数据库计划迁移到Oracle 11.2.0.4.0 RAC.1) 先oracle10g(10.2.0.5)升级到Oracle 11.2.0.4(过程略)2)再Oracle 11.2.0.4单实例迁移到Oracle 11.2.0.

RAC+asm通过rman恢复到单实例+asm

1.恢复参数文件,并修改参数文件 参数文件指名几个最简单的就行,我的参数文件如下: 2.恢复控制文件,并启动数据库到mount 如果是把备份集从别的服务器拷贝到本地恢复的服务器的目录,使用下面的语句指定rman恢复目录 RMAN> catalog start with '/data_back/racbk/'; 3.rename日志文件 select 'alter database rename file '||chr(39)||member||chr(39)||' to '||chr(39)||

RAC异机恢复

RAC异机恢复PDCL到PFCL: PNCL:RAC+ASM ,product env   db name:PNCL   instance:PDCL1 PDCL2 PFCL:RAC+ASM ,performance env   db name:PFCL1  instance:PFCL11 PFCL12 ============= start backup at pncl side: [email protected]:PDCL1:/rman_bkup1/PDCL/rmandumps/deff $

RMAN恢复测试

今天做RMAN恢复的测试,做恢复测试,必须在数据库有备份的前提下进行,样例中采用的是完全备份,模拟以下几种情况下的恢复: 1)数据库运行过程中数据文件全部丢失: 2)数据库运行过程中非关键数据文件丢失: 3)数据库运行过程中关键数据文件丢失: 4)联机重做日志文件/归档重做日志文件丢失(未测试): 5)增量备份下归档日志文件丢失(未测试): 在每个模拟中,都要做一次完全备份,上一个的完全备份可以给下一个模拟使用. 一.测试环境描述 系统版本:Red Hat Enterprise Linux Se

RMAN恢复报错： ORA-01103: database name 'POWERDES' in control file is not 'PDUNQ'

执行rman恢复的时候报错 RMAN> alter database mount; RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: ====================================================

ORACLE中没有参数文件和控制文件如何通过rman恢复数据库

场景: 一个DEV告诉我生产环境下某个用户的表都看不到了,需要恢复,而此时生产库上存储自动备份的参数文件控制文件的磁盘目录文件坏块,所以导致rman备份的只有数据文件和归档日志文件,这种情况下,如何在测试服务器上利用rman恢复数据呢?google了很多资料,咨询了朋友,恢复过程如下: 前期准备工作:事先查询好先查询下原来的数据文件路径SQL> select name from v$datafile; NAME-------------------------------------------

RMAN恢复案例之--不完全恢复错误案例

RMAN恢复案例之--不完全恢复错误案例 RMAN恢复案例: 不完全恢复,由于在先前的数据文件备份有误,导致恢复失败. [[email protected] ~]$ rman target / Recovery Manager: Release 11.2.0.1.0 - Production on Sat Sep 20 15:54:25 2014 Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserve