标签归档:ADG

基于scn恢复ADG和ASM在rman备份恢复过程中的tuning

以下过程主要涉及如下3个问题: 1,根据SCN号“重做”ADG 2,主库是ASM数据库,使用了一半自动命名文件名的文件,和一部分手工指定文件名(别名)的文件: ——————————————————————————– 针对OMF的数据文件使用下面命令: catalog start with ‘+DATA1/MUM/DATAFILE/’; 针对非OFM的数据文件使用下面命令: catalog datafilecopy ‘<File-Specification>’; ——————————————————————————– 3,优化ASM的IO效率 源库: 备库: 查看主库force logging: 查看有哪些文件含有force logging操作,以及他们的scn(下次执行,应该带上orderby,这样更清晰): 备库: 生成批量的backup命令,进行基于scn的恢复(含有force logging的都需要) 主库,备份可以有两个方法: 1,根据上述备份命令写备份脚本 2,从最早的一个scn开始备份也可以 restore 数据文件: 总共新增加了3个文件,重新备份这3个文件即可: 现有ASM的文件信息如下: 有两个错误,这个是因为上面操作时没有注意到数据库中有2个offline的数据文件,下次操作记得备份时把offline的文件不要备份就好了。。。。。。 <bold>开始recover database,这个过程非常慢长,主要原因: 1,存储着实太差了。。。。。。 2,网络速度太差了(这个是NFS的空间) 3,ASM在recover 时需要tuning </bold> 监控rman恢复进度: … 继续阅读

发表在 ASM, backup&recovery, Dataguard | 标签为 , , , , | 留下评论