经常有DBA因为对DATAGUARD监控不到位,导致归档日志和主库没有同步(如本人),更悲剧的是主库通常都设置了RMAN备份,
而全库备份结束后通常会删除归档日志。遇到这种情况,发现很多DBA都会着手重新从主库全库备份恢复到从库,
遇到小的数据库还好,对于动辄上百G或T的库往往会很悲剧,因为数据拷贝时间都相当的漫长。
而事实上对于从库SCN和主库差距并不大,也可以理解为归档差距并不多的DG,
根本没必要全库回复,这种情况下增量恢复能快速解决问题,但对于数据量较小的数据库,直接重新配置duplicate更为方便:
采用incremental recover(增量备份恢复)的方法实现主库和从库同步,
先确定备库的current scn,以此在主库上执行incremental backup,将备份传至备库,使用recover noredo方式恢复备库。
select to_char(current_scn) from v$database;
在主库执行incremental备份
run
{
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
backup as compressed backupset incremental from SCN 16856357 database format '/home/oraclerac/rman_bak/forsryxrdb/standby_%d_%T_%U.bak'
include current controlfile for standby filesperset=5 tag 'FOR STANDBY';
release channel d1;
release channel d2;
release channel d3;
release channel d4;
}
将备份集传输到备库的指定目录中
还原控制文件,并覆盖原来控制问及那
restore standby controlfile to '/home/oracle/app/oradata/sryxrdb/control01.ctl';
重启只mount状态rman
catalog start with '/home/oracle/rman_bak/forsryxrdb';
重新指定数据文件的位置
select 'set newname for datafile ' || df.FILE_ID || ' to ''/home/oracle/app/oradata/oravs' ||
substr(file_name,INSTR(file_name,'/',1,3),50) || ''';'
from dba_data_files df order by df.file_id;
rman:
run{
set newname for datafile 1 to '/home/oracle/app/oradata/sryxrdb/system.256.866220891';
set newname for datafile 2 to '/home/oracle/app/oradata/sryxrdb/sysaux.257.866220891';
set newname for datafile 3 to '/home/oracle/app/oradata/sryxrdb/undotbs1.258.866220893';
set newname for datafile 4 to '/home/oracle/app/oradata/sryxrdb/users.259.866220893';
set newname for datafile 5 to '/home/oracle/app/oradata/sryxrdb/undotbs2.264.866221147';
set newname for datafile 6 to '/home/oracle/app/oradata/sryxrdb/vs_base.420.866561467';
set newname for datafile 7 to '/home/oracle/app/oradata/sryxrdb/vs_base.421.866561531';
set newname for datafile 8 to '/home/oracle/app/oradata/sryxrdb/tbs_index.422.866561581';
switch datafile all;
}
recover database noredo;
启动备库,实施应用即可。
参考:http://yunlongzheng.blog.51cto.com/788996/717249