标签归档：Dataguard

以下过程主要涉及如下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恢复进度： … 继续阅读 →