全面介绍恢复Oracle数据库

来源：作者：佚名出处：巧巧读书 2007-11-04 进入讨论组

要损坏Oracle数据是不可能的。环境恢复的机制保证了这一点，就是使用redo和undo来将数据库返回到环境失败之前的一个一致性状态中去。然而，在媒介失败之后丢失数据是可能的——如果数据库管理员没有予以适当的警惕。

    预先防范是简单的:在归档日志模式下运行数据库;多路传送控制文件，在线日志文件，以及文档日志文件;支持数据文件和文档日志文件。在媒介失败之后，备份和文档日志可以用于恢复数据库到失败前的点，不丢失任意一行已经被提交的数据。但是，尽管环境恢复的确是自动化的，不可避免的——媒介恢复是一个手工的过程。本章内容将会讲述基本的恢复技术。可以用于更加复杂问题的比较高级的技术，将会在下章中涉及。

    不可避免性——媒介的恢复是个手工的过程。本章讨论的是基本的恢复技术。更高级的，可以应用于更加复杂问题的技术，将会在稍后的章节中继续讨论。

    恢复结构和处理过程

    在媒介失败之后，有不同的技术用于恢复，根据哪个文件被损坏的情况。数据库由3种文件类型组成:控制文件、在线redo日志文件，以及数据文件。恢复控制文件和在线redo日志文件的过程是一个繁琐的过程，它们是通过多路传送的。恢复一个或者多个数据文件的过程是比较复杂的，但是很直接。损坏的控制文件可以通过多路传送的拷贝或者用CREATE CONTROLFILE命令重新创建的控制文件来进行恢复。在极端的情况下，它可以从备份中重新存储，但是这一点在媒介失败之后是从来不需要的，如果你遵循的是一个合适的多路策略。损坏的在线redo文件也可以被重新生成，Oracle提供了一条ALTER DATABASE CLEAR LOGFILE GROUP #(#是损坏成员的组的号码)命令，它可以删除并且重新创建日志文件组的成员。如果数据库运行的是文档日志模式(也应该是这样的)，日志文件组必须在Oracle允许执行清楚日志文件命令之前进行归档。这是因为，清除一个没有归档的日志文件组，就意味着文档日志流会丢失一个日志文件，因此恢复就是不可能的了。这样的命令还可以有一些变化，ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #，它可以删除并重新创建日志文件，即使是它没有成功地归档，但是在执行了这条命令之后，它绝对就是执行整个数据库备份的一个至关重要的部分。

    一个受到损坏的日志文件需要使用备份和文档日志。在媒介失败导致日志文件的损坏之后，有两种选择用于恢复:完全恢复，意思是不丢失数据;还有不完全恢复，这时你通过在它完成之前停止恢复过程故意丢失一部分工作。不完全恢复是一个高级的程序，将会在第27章中讲述。完全恢复过程有两个阶段。首先，被损坏的文件必须从备份中重新存储。第二个，重新存储的文件必须被恢复，通过使用文档日志中的redo信息来把它及时地向前推进，直到它与数据库的其它部分同步。

    测验贴士:在Oracle环境中，“重新存储”的意思是用备份替换掉一个损坏或者丢失的文件;“恢复”的意思是通过使用文档日志使文件与数据库的其它部分同步。

    因为在线redo日志从来没有被RMAN备份过，那么RMAN就不能用来恢复损坏;修理由于媒介失败导致的在线日志文件损坏可以通过SQL*Plus完成，或者是通过数据库控制。控制文件和数据文件都可以通过RMAN来重新存储或者恢复;实际上，如果你把它们备份到备份集中去，RMAN就是你惟一的选项。

    要打开一个数据库，所有的控制文件拷贝，至少是每个在线日志文件组中的一个文件，还有所有的在线日志文件，都必须要显示出来并且同步。如果，在启动过程中，SMON发现情况不对劲，启动就无法完成。如果一个控制文件拷贝损坏了或者丢失了，启动就用NOMOUNT模式来终止。一条描述哪个(或者哪些)拷贝被损坏了的消息就会发送给警报日志。假设控制文件是好的，SMON就继续打开数据库。在这个过程中，它检查所有在线数据文件的头。如果头有丢失或者损坏，就会写适当的错误消息给警报日志，数据库会继续保持准备的模式。如果所有的在线文件都显示出来，并且没有损坏，但是其中的一个或者多个没有同步，SMON会尝试通过使用在线redo日志来对它们进行同步。这就是环境恢复的过程，在第18章有详细介绍，这个过程是自动进行的。如果所需的在线日志找不到，那么数据库就无法打开。如果一个或者多个数据文件从备份中重新存储了，那么它们可能会非常过时，在线redo日志也无法走那么远的时间去恢复它们:这是你就必须使用文档日志文件来恢复了，这是一个必须手工启动的过程——从SQL*Plus中，如果你用的是操作系统的命令备份的话，或者使用RMAN，如果(是Oracle强烈推荐的)你是用RMAN来提交备份的。

    如果媒介损坏发生在数据库打开的时候，那么影响的范围就基于有哪些文件受到影响。任何控制文件拷贝的损坏都会导致数据库环境立即终止。如果受到损坏的数据文件是SYSTEM表空间或者活动的undo表空间，那么影响是一样的。但是对任何在线日志的损坏都不会导致环境的终止，只要还有部分日志文件组存在的话。实际上，环境会继续工作，你的终端用户也甚至不会注意到。但是错误消息会写到警报日志中去，这种情况也需要立即纠正;这样的纠正能够并且应该是在线的，当人们继续工作的时候。

    如果损坏的数据文件时表空间的一部分，而不是SYSTEM或者其他活动的undo表空间，也不会导致环境的失败，但是很明显，终端用户可能会有问题，因为数据库的部分内容消失了。你的应用程序如何应对这种情况是不可预期的——它是完全根据应用程序是如何组织的。对损坏数据文件的重新存储或者恢复都可以在线完成，假如它们不是属于SYSTEM或者undo表空间的数据文件。最后，如果是组成你的临时表空间的临时文件受到损坏，终端用户也完全不会注意到。Oracle不会去验证临时文件的存在，除非要使用它们了，并且一个经过良好调整的数据库也许永远也不会用到它们。这就是说，临时文件可以在它们受到注意之前消失一阵子。同样也意味着损坏的临时文件可以被删除或者重新创建，在任何时间，除非正好在那个时候要用到它。

    在备份中重新存储可以通过RMAN或者操作系统工具来完成。但是如果你的RMAN备份是备份集合，而不是映像的拷贝，重新存储就只能通过RMAN来完成了:没有其他的方法从数据集中解压缩数据文件。重新存储后的恢复也可以通过SQL*Plus命令，或者用RMAN来完成，但是也有同样的约束条件:只有RMAN可以从备份集中解压缩文档日志。

文章地址： http://www.qqread.com/oracle/2007/11/s379810.html