如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]
使用增量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传送表空间和整个数据库到不同的平台上。
Leave a Reply