＋设为首页 ＋添加到收藏夹
媒体恢复分完全恢复与不完全恢复.不完全恢复可以恢复到指定的时刻或系统更改号,但不完全恢复之后剩余日志文件就不可用,必须重置日志序列号,用resetlogs选项打开数据库,此后数据库变成一个新形体,为了将来的恢复,必须重做一致备份.而且,resetlogs之前的备份已不可用.但是,很可能在resetlogs后没有做数据库的一致备份,而数据库又不认识resetlogs之前的备份,此时该如何恢复resetlogs后的数据呢?虽说本文提供的技术能实现用resetlogs之前的备份恢复到resetlogs之后某一时刻的数据,但这也是挽救措施,笔者强烈建议读者要做resetlogs之后的一致数据库备份.
【程序编程相关:微软Outlook Express地址本】 【推荐阅读:FastJar 文件释放目录迁移漏洞】技术的理论基础 【扩展信息:微软.NET Framework SDK】 oracle仅根据系统更改号（scn）进行恢复操作,所有数据文件必须恢复到同一时间点,并在该点后未作任何改动,才能打开数据库.数据库的scn是唯一的,并随着数据库生存期间的操作事务增加而增加（可能不连续）.scn的值永远不会为0,除非重新创建数据库.scn的序列的递增性不随数据库的任何操作而改变,即使是resetlogs也如此.resetlogs清除所有联机日志文件中未应用的重做记录,resetlogs只重置日志文件的序列号为1,但对scn无影响,scn仍按原序列递增. 在控制文件中保存resetlogs scn与计数器,以便唯一地标识用resetlogs选项执行的每一次打开数据库的操作.这个值被写进每个数据文件头以及重做日志文件.如果重做日志文件的日志序列号与oracle的要求值不相符,则在恢复中不能应用重做日志文件.执行不完全恢复后,数据库要求日志序列号为1的日志文件,所以原来的日志序列中剩余的日志文件将不可用.resetlogs操作创建数据库的新形体,即一个拥有从1开始的新的日志序列号流的数据库. 根据以上理论,scn为顺序数据流,在数据库存在期间始终递增,而日志文件序列流也是递增序列,只不过会因resetlogs而重置,但日志文件序列流中的scn序列流却保持递增不便.因此可以用resetlogs之前的归档日志流与resetlogs之后的归档日志流来连接与延续scn序列流,这样就实现了用resetlogs之前的备份恢复resetlogs之后的数据.前提是保证两股日志流（resetlogs之前的归档日志流与resetlogs之后的归档日志流）完整,并且有相应两股日志流的控制文件. 即使能够挽救数据,也要满足下列条件 （1）oracle版本等于或高于7.3.3. （2）能够成功实现resetlogs之前的不完全媒体恢复. （3）resetlogs后没有提供一致备份. （4）resetlogs之前提供一致性备份（冷或热）.... 下一页