使用增量RMAN恢复备用数据库standby

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

使用增量RMAN恢复备用数据库

备用数据库可能使用从主数据库采取增量备份进行恢复。为此，执行下列步骤:

采用备用侧的当前scn值:

SQL> select current_scn from v$database; CURRENT_SCN ----------- 485263

从初级侧，使用 backup incremental from scn 命令，提供从备用数据库采用的scn 值，备份具体的scn 值之后的变化:

RMAN> backup incremental from scn 485263 database format '/u02/inc_backup_%U';

切换到备用数据库，使用catalog 命令注册增量备份:

RMAN> catalog start with '/u02/';

现在使用no redo 选项恢复备用数据库，为了只应用增量备份:

RMAN> recover database noredo;

RMAN 只应用增量备份到备用数据库，然后切换主数据库上的重做日志文件，并在备用侧上应用:

# On the primary side SQL> alter system switch logfile; System altered. #On the standby side SQL> recover standby database;

使用增量备份解决归档重做日志缺口

假设由于网络故障, 根据定义的RMAN保留策略，一些归档重做日志文件没有发送到备用数据库，被从主数据库中删除，因为接下来生成的归档重做日志文件不能跳入成功按先后顺序一个接一个地应用所有之前，无论是从头开始创建备用数据库，或者-

当然, 有另一个选项，通过应用从主数据库采用的必要的增量备份，前滚数据库，并且越过应用丢失的归档重做日志文件。下面的场景会显示没有归档重做日志文件时，恢复备用数据库的步骤

首先, 需要带有丢失重做日志文件的备用数据库，为此:

1. 在主侧上改变log_archive_dest_2 参数

2. 手动切换日志文件，创建归档重做日志文件

3. 从主侧中删除生成的归档重做日志文件

首先, 检查v$archived日志文件，在两个数据库上获得最后一个生成的归档重做日志序列值, 然后改变主侧上的log_archive_dest_2 初始参数，阻止归档重做日志传送到备用站点，如下:

# Run the following code on the primary database: SQL> select max(sequence#) from v$archived_log; MAX(SEQUENCE#) -------------- 54 # Run the following code on the standby database: SQL> select max(sequence#) from v$archived_log; MAX(SEQUENCE#) -------------- 54 SQL> show parameter log_archive_dest_2 NAME TYPE VALUE --------------------------- ----------- ---------------------------- log_archive_dest_2 string service=test optional reopen=15 SQL> alter system set log_archive_dest_2='service=noservice'; System altered. SQL> show parameter log_archive_dest_2; NAME TYPE VALUE ---------------------------- ----------- --------------------------- log_archive_dest_2 string service=noservice

现在，再次在两侧手工切换重做日志，检查v$archived_log视图:

# Run the following codes on the primary database: SQL> alter system switch logfile; System altered. SQL> / System altered. SQL> / System altered. SQL> select max(sequence#) from v$archived_log; MAX(SEQUENCE#) -------------- 57 SQL> # Run the following code on the standby database: SQL> select max(sequence#) from v$archived_log; MAX(SEQUENCE#) -------------- 54

这里显示了没有发送到备用站点的最后三个归档重做日志文件，进入到主站点，删除带有序列55、56 和57最后生成的三个归档重做日志文件:

[oracle@localhost 2015_06_06]$ rm -rf o1_mf_1_5[5-7]_60rp*

现在取消备用站点的管理恢复操作, 取最后一个序列值，关闭备用数据库:

SQL> alter database recover managed standby database cancel ; SQL> select current_scn from v$database; CURRENT_SCN ----------- 507189 SQL> shutdown immediate

切换到主站点，并采用数据库的增量备份，从已经从备用数据库所采取的SCN值开始:

RMAN> backup incremental from scn 507189 database format='/u02/rman_backup/incremental/incr_backup_%U';

创建备用控制文件, 改变 log_archive_dest_2 初始参数并切换当前重做日志文件:

SQL> alter database create standby controlfile as '/u02/rman_backup/standby_control.ctl'; SQL> alter system set log_archive_dest_2='service=test optional reopen=15'; System altered. SQL> alter system switch logfile;

复制备用控制文件和增量备份文件到备用点，在no mount模式下打开数据库，改变参数文件，使实例使用备用控制文件:

SQL> alter system set control_files='/u02/rman_backup/standby_control.ctl' scope=spfile; System altered. SQL> shutdown immediate SQL> startup nomount

安装备用数据库和编目增量备份到存储库:

SQL> alter database mount standby database; RMAN> catalog ackuppiece'/u02/rman_backup/incr_backup_1mlfj8pq_1_1';

现在, 使用增量备份恢复数据库:

RMAN> recover database; channel ORA_DISK_1: starting incremental datafile backupset restore channel ORA_DISK_1: reading from backup piece /u02/rman_backup/ incr_backup_1mlfj8pq_1_1 channel ORA_DISK_1: restored backup piece 1 piece handle=/u02/rman_backup/incr_backup_1mlfj8pq_1_1 tag=TAG20100606T224202 channel ORA_DISK_1: restore complete, elapsed time: 00:00:02 starting media recovery archive log thread 1 sequence 58 is already on disk as file /u01/oracle/product/10.2.0/db_1/flash_recovery_area/TEST/archivelog/ 2010_06_07/o1_mf_1_58_60s4sjbc_.arc archive log filename=/u01/oracle/product/10.2.0/db_1/flash_recovery_area/TEST/ rchivelog/2010_06_07/o1_mf_1_58_60s4sjbc_.arc thread=1 sequence=58 unable to find archive log archive log thread=1 sequence=59 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 06/07/2010 02:38:36 RMAN-06054: media recovery requesting unknown log: thread 1 seq 59 lowscn 508306 RMAN> exit

正如我们看到的, RMAN尝试应用还未在主数据库上生成的带有序列59的归档重做日志，在主数据库上手工切换重做日志，带有序列59的新的归档重做日志文件会创建，并发送到备用服务器，取用主数据库上的当前 scn，以便和备用数据库进行比较:

SQL> alter system switch logfile; System altered. SQL> select current_scn from v$database; CURRENT_SCN ----------- 511308 SQL>

现在切换到备用数据库，运行recover standby database 命令， RMAN 会寻找下一个归档重做日志文件，并自动应用:

SQL> recover standby database;

然后在备用数据库上查询当前 scn 值:

SQL> select current_scn from v$database; CURRENT_SCN ----------- 511301 SQL>

结论

本章展示了使用RMAN的duplicate database命令克隆数据库的方法，数据库已经被克隆到带有相同的和不同的目录结构的远程和本地主机，然后Oracle的新功能11g中的网络启用数据库克隆，无需在数据库使用实时数据文件复制中检查任何备份。

接着,展示了使用Enterprise Manager进行数据库克隆的方式，本章的结尾展示了使用duplicate database for standby命令创建备用数据库的步骤。下一章将重点放在使用RMAN传送表空间和整个数据库到不同的平台上。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

服务热线： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com