在不损坏块的情况下尝试修复恢复问题:阶段2
依赖于你猜想的介质恢复问题的类型,在你的处理中有不同的解决方案。
可以尝试一种技术或多种技术的结合。这些解决方案是普通的修复技术,对地解决大多数的介质恢复问题是相当安全的。
表 29.5 介质恢复解决方案
假设… | 则… |
丢失或错误地命名了归档重做日志 | 判断你是否输入了正确的文件名称.如果输入正确,则检查这个日志是否已经从操作系统丢失了。 如果丢失了并且你有备份,则还原备份并应用日志; 如果没有备份,则如果可能就执行不完全恢复到丢失日志的点。 |
ALTER DATABASE OPEN出现ORA-1113错误 | 查看表29-4中引起这个错误的原因。确定所有需要恢复的read/write数据文件是联机的。 如果使用备份的控制文件进行恢复,则控制文件和数据文件必须在一个一致的SCN, 这样数据库才能打开。如果没有需要的redo数据,则必须重建控制文件。 |
损坏了归档日志 | 如果在重做日志块上的校验失败,则该日志就是损坏了。 如果在恢复会话过程中,或在数据库产生redo信息的时候,DB_BLOCK_CHECKSUM没有开启, 则恢复的问题可能是由损坏的块引起的。 如果日志被损坏并且另外的拷贝可用,则尝试应用它并查看这种策略能否修复问题。 DB_BLOCK_CHECKSUM初始化参数决定是否对重做日志和数据块进行校验计算。 |
归档日志与并行redo格式不兼容 | 如果Oracle的版本<= 9.2并且你试图应用使用并行redo格式创建的重做日志,则必须完成下面的步骤: 1. 更新数据库到更新的版本 2. 执行介质恢复 3. 一致地关闭数据库并且备份数据库 4. 降级数据库到原来的版本 |
内在损坏或暂时的问题 | 通过关闭数据库,重新开始恢复有可能修复问题。 如果第2次尝试也失败了,数据库应该处于一致的状态。 |
损坏数据块 | 使用用户管理的方法再次还原和恢复数据文件, 或使用RMAN RECOVER…BLOCK命令还原和恢复单个的数据块。这种技术可能修复问题。
如果在一个数据块上的校验验证失败,则这个数据块就损坏了。 如果DB_BLOCK_CHECKING中禁用的,则数据块损坏的问题可以表现为一个redo的问题。
如果你必须继续介质恢复,则你可能想允许介质恢复当前将这些块标志为损坏的,继续进行恢复,最后使用RMAN执行块介质恢复。 |
如果不能使用表 29.5中的方法来修复问题,则可能没有容易的方法来修复问题并且不丢失数据,可有如下选择:
n 用RESETLOGS选项打开数据库(对于整个数据库恢复)。
这种方法抛弃了redo问题发生点之后的所有改变,但保证了逻辑上一致的数据库。
n 允许介质恢复损坏一个或多个数据块然后继续。
只有当预警日志表明如果损坏一个或多个数据块恢复可以继续的时候,这个选项才能成功。
这可能是大多数恢复问题的情况。如果你必须快速地启动数据库恢复所有的改变,这个选择是最好的。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17013648/viewspace-1101387/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/17013648/viewspace-1101387/