关于用户管理的还原和恢复
当介质失败或其它用户错误损坏或删除了多个数据文件,你需要还原文件。
在用户管理的还原操作中,是使用操作系统工具来还原文件的备份。
如果介质失败影响了数据,则恢复过程依赖于:
n 数据库的归档模式
n 介质失败的类型
n 被介质失败影响的文件(数据文件、控制文件、归档重做日志文件、服务器参数文件都是还原操作的候选项)
如果持久的或临时的介质失败影响到了运行在非归档模式的数据库的数据文件,则数据库自动关闭。
如果介质失败是暂时的,则修正下面的问题并重启数据库。
通常故障恢复会从联机重做日志恢复所有已经提交的事务。
如果介质失败是持久化的,则参考“恢复处于非归档模式的数据库”
下表解释了当处于归档模式的数据库丢失数据文件时,介质恢复的含义。
表 STYLEREF 1 \s 29. SEQ 表 \* ARABIC \s 1 1 用户管理的还原操作
如果丢失了… | 则… |
SYSTEM表空间的数据文件或与活动的undo段相关的数据文件 | 数据库自动地关闭。 如果硬件问题是暂时的,则修复并开启数据库。通常故障恢复会恢复丢失的事务。 如果硬件问题是持久化的,则要还原数据文件并恢复数据库,参考“执行关闭的数据库的恢复”。 |
非SYSTEM表空间数据文件,不包含活动的回滚段或undo段的数据文件 | 受影响的数据文件脱机,但数据库仍然处于打开状态。 如果数据库未受影响的部分必须保持可用,使用TEMPORARY选项使包含有问题的数据文件的表空间脱机,然后进行恢复,参考“执行打开的数据库恢复” |
当前控制文件的所有拷贝 | 此时必须还原一个控制文件,然后使用RESETLOGS选项打开数据库。 如果没有备份,则可以尝试重建控制文件。 如果允许,可以使用ALTER DATABASE BACKUP CONTROLFILE TO TRACE命令输出的脚本。 也可能需要其它的工作来匹配控制文件结构和当前的数据库结构。 |
多元化控制文件的一个拷贝 | 拷贝一个未受影响的多元化控制文件的拷贝到被损坏的或丢失的控制文件的位置,然后打开数据库。 如果不能拷贝文件到它原始的位置,则编辑初始化参数文件来反映新的位置或移除损坏的控制文件。 然后打开数据库。 |
介质恢复需要的一个或多个归档日志 | 为了使恢复继续进行,必须还原这些归档日志的备份。可以还原到默认的位置或非默认的位置。 如果没有备份,则必须执行不完全恢复到第一个丢失的重做日志之前的SCN,然后OPEN RESETLOGS |
服务器参数文件(SPFILE) | 如果有服务器参数的备份文件,则还原它。 作为替代如果有客户端的初始化参数文件,则可以还原这个文件的备份,启动实例重新创建服务器参数文件。 |
注意:还原和恢复OMF文件与还原和恢复用户命名的文件是没有区别的。
为了执行介质恢复Oracle建议在SQL*Plus中使用RECOVER语句。
你也可以使用ALTER DATABASE RECOVER语句,但RECOVER语句更简单。
为了开始任何类型的介质恢复,为必须遵守下面的限制:
n 必须具有管理员权限
n 所有的恢复会话必须是兼容的
n 在其它的会话执行不完全介质恢复的时候,不能启动完全介质恢复
n 如果是通过共享服务器进程连接到数据库,则不能开始介质恢复。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17013648/viewspace-1098333/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/17013648/viewspace-1098333/