要损坏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可以从备份集中解压缩文档日志
从媒介失败中恢复
媒介失败之后的重新存储和恢复在下一章中会进行更加详细的描述，并且在第二个OCP考试中也会详细考察，但是了解一下初级考试中的简单问题的基本恢复也是很有必要的。这些简单的问题是丢失了多路控制文件中的一个，和一个在线redo日志文件，以及关键和非关键数据文件丢失之后的完全恢复。
多路控制文件丢失的恢复
只要挽救了现有控制文件的多路拷贝，恢复损失的控制文件就是简单的。只要用挽救回来的控制文件的拷贝替换它就可以了。要从备份中重新存储被损坏的或者丢失的控制文件拷贝在这样的情况下是没有用处的，因为控制文件的所有的拷贝都必须是同样的;很明显，一个重新存储的拷贝不会与其他幸存的拷贝同步，更不用说是数据库的其它部分了。
实际上，在损坏发生的瞬间，环境就会终止。而像往常一样，数据库管理员的第一个反应就是坏了的环境应该重新启动。在NOMOUNT模式下，这不会成功的，并且会返回一个错误消息。警报日志将会描述哪个控制文件拷贝丢失了，还会在这个部分列出那些非默认情况的初始化参数——实际上使用了多少控制文件，以及它们都在哪里。在这一点上，你要注意三点。第一点，你需要编辑参数文件来删除对丢失或者损坏的控制文件的参考。
这样很好，但是你的数据库现在就要运行就会少了一部分多路拷贝，这有可能会违反你的安全条款。一个更好的选择就是用幸存下来的拷贝来替换损坏的文件，或者真的去更改CONTROL_FILES初始化参数来删掉对那些被损坏的文件的参考，重新参考一些新的文件，然后拷贝那些幸存的控制文件到那里去
本文作者: