通过service 修复12c备库-凯发app官方网站

-- 1.关闭备库
shu abort
startup mount
-- 2.比对主、备库文件是否有不同
col name for a50
col fhscn for 99999999999999
set lin 120 pages 100
select file#, name,checkpoint_change# fhscn from v$datafile_header;
-- 3.备库确认当前备库scn，稍后的步骤中确定是否主数有新数据文件
select current_scn from v$database;
-- 4.备库同步差异（简单多了）
rman target /
recover database from service tns_prim noredo using compressed backupset;
-- 5.备库同步最新的控制文件
shutdown immediate;
startup nomount;
restore standby controlfile from service tns_prim;
alter database mount;
report schema; -- 检查文件位置及名称（应该都是主库上的信息）
-- 6.更新备用控制文件中的数据文件和临时文件的名称
由于控制文件是从 primary 恢复的，通常主备库数据文件位置不同，或者如果使用 oracle 管理的文件名 omf，需要注册备库文件。如果主备具有相同的结构和数据文件名称，则可以跳过此步骤。
catalog start with '备库数据文件位置'; --注意是备库文件位置，所以数据文件最好放置在同一目录下（好管理）
switch database to copy;
如果这里出现 rman-06571，说明位置不对或主备库文件位置一样
个别文件在其他目录下则单独注册，例如：switch datafile 5 to copy;
-- 7.检查是否有数据文件是新加的
select file# from v$datafile where creation_change# >=第3步中的scn
如果缺少21号文件，则单独恢复
run
{
set newname for database to '/';
restore datafile 21 from service tns_prim;
}
-- 8.清理备库日志文件(主备库不在同一个主机或使用同一asm组，否则就把主库给直接破坏了，细思极恐)
select 'alter database clear logfile group '||group#||';' c from v$logfile where type='standby' group by group#;
执行输出

-- 9.恢复备库并继续同步

recover database;
alter database open read only;
alter database recover managed standby database disconnect from session;

参考：
在 12c 中使用 recover from service 命令前滚物理备用数据库（文档 id 1987763.1）

阅读(1442) | 评论(0) | 转发(0) |

上一篇：ora-19909 处理

下一篇：ora-01578 ora-26040 修复nologging 操作对dg的影响

给主人留下些什么吧！~~

| | | | |

感谢所有关心和支持过chinaunix的朋友们