这是截取自Damir Bersinic 和John Watson合着的《Oracle Database g OCP Certification AllInOne Exam Guide》书中第章Oracle出版社出版copyright McGrawHill分公司
在这章中你将会学到的是:
用控制文件挽回损失
用redo日志文件挽回损失
用系统关键数据文件挽回损失
用非系统关键数据文件挽回损失
要损坏Oracle数据是不可能的环境恢复的机制保证了这一点就是使用redo和undo来将数据库返回到环境失败之前的一个一致性状态中去然而在媒介失败之后丢失数据是可能的——如果数据库管理员没有予以适当的警惕
预先防范是简单的:在归档日志模式下运行数据库;多路传送控制文件在线日志文件以及文档日志文件;支持数据文件和文档日志文件在媒介失败之后备份和文档日志可以用于恢复数据库到失败前的点不丢失任意一行已经被提交的数据但是尽管环境恢复的确是自动化的不可避免的——媒介恢复是一个手工的过程本章内容将会讲述基本的恢复技术可以用于更加复杂问题的比较高级的技术将会在下章中涉及
不可避免性——媒介的恢复是个手工的过程本章讨论的是基本的恢复技术更高级的可以应用于更加复杂问题的技术将会在稍后的章节中继续讨论
恢复结构和处理过程
在媒介失败之后有不同的技术用于恢复根据哪个文件被损坏的情况数据库由种文件类型组成:控制文件在线redo日志文件以及数据文件恢复控制文件和在线redo日志文件的过程是一个繁琐的过程它们是通过多路传送的恢复一个或者多个数据文件的过程是比较复杂的但是很直接损坏的控制文件可以通过多路传送的拷贝或者用CREATE CONTROLFILE命令重新创建的控制文件来进行恢复在极端的情况下它可以从备份中重新存储但是这一点在媒介失败之后是从来不需要的如果你遵循的是一个合适的多路策略损坏的在线redo文件也可以被重新生成Oracle提供了一条ALTER DATABASE CLEAR LOGFILE GROUP #(#是损坏成员的组的号码)命令它可以删除并且重新创建日志文件组的成员如果数据库运行的是文档日志模式(也应该是这样的)日志文件组必须在Oracle允许执行清楚日志文件命令之前进行归档这是因为清除一个没有归档的日志文件组就意味着文档日志流会丢失一个日志文件因此恢复就是不可能的了这样的命令还可以有一些变化ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #它可以删除并重新创建日志文件即使是它没有成功地归档但是在执行了这条命令之后它绝对就是执行整个数据库备份的一个至关重要的部分
一个受到损坏的日志文件需要使用备份和文档日志在媒介失败导致日志文件的损坏之后有两种选择用于恢复:完全恢复意思是不丢失数据;还有不完全恢复这时你通过在它完成之前停止恢复过程故意丢失一部分工作不完全恢复是一个高级的程序将会在第章中讲述完全恢复过程有两个阶段首先被损坏的文件必须从备份中重新存储第二个重新存储的文件必须被恢复通过使用文档日志中的redo信息来把它及时地向前推进直到它与数据库的其它部分同步
测验贴士:在Oracle环境中重新存储的意思是用备份替换掉一个损坏或者丢失的文件;恢复的意思是通过使用文档日志使文件与数据库的其它部分同步
因为在线redo日志从来没有被RMAN备份过那么RMAN就不能用来恢复损坏;修理由于媒介失败导致的在线日志文件损坏可以通过SQL*Plus完成或者是通过数据库控制控制文件和数据文件都可以通过RMAN来重新存储或者恢复;实际上如果你把它们备份到备份集中去RMAN就是你惟一的选项
要打开一个数据库所有的控制文件拷贝至少是每个在线日志文件组中的一个文件还有所有的在线日志文件都必须要显示出来并且同步如果在启动过程中SMON发现情况不对劲启动就无法完成如果一个控制文件拷贝损坏了或者丢失了启动就用NOMOUNT模式来终止一条描述哪个(或者哪些)拷贝被损坏了的消息就会发送给警报日志假设控制文件是好的SMON就继续打开数据库在这个过程中它检查所有在线数据文件的头如果头有丢失或者损坏就会写适当的错误消息给警报日志数据库会继续保持准备的模式如果所有的在线文件都显示出来并且没有损坏但是其中的一个或者多个没有同步SMON会尝试通过使用在线redo日志来对它们进行同步这就是环境恢复的过程在第章有详细介绍这个过程是自动进行的如果所需的在线日志找不到那么数据库就无法打开如果一个或者多个数据文件从备份中重新存储了那么它们可能会非常过时在线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初始化参数来删掉对那些被损坏的文件的参考重新参考一些新的文件然后拷贝那些幸存的控制文件到那里去
测验贴士:恢复控制文件的丢失是必须要承担停机时间的它无法在线完成
测验:从控制文件的丢失中恢复
在这个测验中假设你丢失了多路控制文件并且要用一个拷贝来替换它
用SQL*Plus连接到你的数据库上去然后确保你的控制文件是多路传输到这个查询的:
SQL> select * from v$controlfile;
这个查询必须返回至少行如果没有的话多路传输你的控制文件
假设你的数据库受到攻击一个控制文件损坏了并且你的一个控制文件名字更改了注意在Windows上你必须首先停止Windows服务否则Windows不会让你更改文件名然后再重新启动这个服务
输入启动命令这次启动会终止在nomount模式并且返回ORA: error in identifying controlfile check alert log for more info错误消息
拷贝幸存的控制文件到你重新命名的文件路径上去名字也改为你重新设定的名字
再次输入启动命令这次就会成功了
问题示例:
丢失这些文件会导致打开的数据库崩溃?(项选择)
一个多路控制文件
一个多路在线日志文件
一个多路文档日志文件
一个活动的undo表空间数据文件
一个活动的临时表空间临时文件
一个SYSAUX表空间中的数据文件
一个SYSTEM表空间中的数据文件
一个包含了关键用户数据的数据文件
一个多路控制文件的拷贝损坏你应该怎么做?(单选)
用幸存的拷贝替换
用RMAN重新存储
用操作系统命令重新存储
用CREATE CONTROLFILE命令重新创建
