Oracle数据恢复、数据库恢复、灾难恢复专题
题记:随着数据库在企业中的重要性不断增加,数据库承载的业务越来越复杂,管理难度也不断增加,用户在数据库的使用过程中,不可避免的会遇到种种数据库故障、灾难,此时,数据备份与恢复就显得尤为重要。
本站在多年的维护过程中,积累了大量备份恢复相关的案例与知识内容,在此以专题的形式,整理归类出来,供大家参考,案例以为警醒,知识以为参考。
对于一个DBA来说,最为重要的就是备份,DBA四大守则,备份重于一切。
备份的重要性
对于DBA来说,有一句话需要谨记:隐患险于明火,防范胜于救灾,责任重于泰山
备份重于一切,我们必需知道,系统总是要崩溃的,没有有效的备份只是等哪一天死!唯一会使DBA在梦中惊醒的就是没有备份. | 生活的启示
严谨专注是DBA的基本素质要求之一,当然我也非常喜欢另外一句话:坚韧卓绝之人,必能成就万事.
这个世界上没有永远的侥幸,如果你掉以轻心,生活就会给你教训。读读这些DBA职业生涯的误操作篇,看看哪些可以避免. |
Ora-600错误
- ORA-00600 kcratr_nab_less_than_odr案例
猜测是一种很重要的能力,[kcratr_nab_less_than_odr],根据less than字样,可以判断是在进行某个比较时,出现问题
当实例崩溃之后启动,Oracle会去检查崩溃前最后一个写出的数据块,通过控制文件校验其是否一致
这里的错误代码kcbzpbuf,猜测是Kenerl Cache Buffer上的验证错误。应当是在应用Redo前滚时在Buffer中校验数据时出了问题。
在解决2662错误之后,经常会出现Ora-00600 4193错误,4193错误通常是因为恢复时redo与undo不一致所导致。
ORA-600 errors are internal exceptions handled by the RDBMS Kernel. The first arguments is an identifier. | DBA警示录-有多少错误可以不犯
对表做了move后,没有rebuild index,然后就关闭数据库了,导致数据库不能重新启动
应当将PROPS$视为禁忌,也就是说,决不要直接对这个表进行任何操作。
历史总数惊人的相似,以前我曾经写过一篇文章:年终难终 进入数据库事故多发期,现在又到了这样一个时期。
有人遭遇了这样一个惨痛教训,当使用root登陆系统时(HP Unix系统),错误的发出了hostname -a命令。
在这样曲折的过程中,我们可以注意到,对于一个关键的操作,无论采取怎样认真、细致、繁琐的测试、验证与规划都是值得的。 |
备份恢复基础知识
Oracle的恢复从上一次成功的写出开始,也就是以Cache-Low RBA为起点,恢复至日志的最后成功记录,也就是以On-Disk RBA为终点。
由于备份时是不删除归档的,所以会导致积累了大量的归档日志存储,删除时需要找到那个备份过的最近的归档日志
RMAN提供VALIDATE的命令,可以用于校验备份集的有效性,验证命令会建议备份的存在性、完好性和可恢复性,帮助我们确认备份的有效与否.
和UNDO相关的操作极度危险,任何一个丢失的事务都可能成为灾难,所以了解任何一个动作及其可能带来的影响是对我们的重大考验。
不管控制文件的名称里是否包含了DBID,但是,只要有了控制文件,就可以从其中获得DBID
有时候需要跟踪文件中缺省的不会记录具体的SQL、绑定变量等信息,可以通过ErrorStack进行后台跟踪,获得更详细的信息
kcbgtcr 是Oracle数据库最重要的函数之一,其含义为:Kernal Cache Buffer GeT Cosistents Read,也就是数据库的一致性读操作
我们知道Oracle10g丰富了catalog命令,使用这个命令,可以将RMAN的备份集注册到控制文件(或者目录数据库中)
在RMAN的备份中,可以通过Exclude命令排除某些不需要备份的表空间。这样可以缩减备份的容量,对备份进行适当优化和调整。 | 数据库恢复技术与案例
从Oracle9iR2开始,可以使用flashback query闪回误删除的数据,在undo_retention的限制下,可以快速的执行数据恢复。
最近一周以来,恩墨科技帮助多家用户进行了数据恢复,挽救了多个危难之中的数据库。
使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库,会由于SCN不一致而遭遇到ORA-00600 2662号错误
电力不稳定,导致HP IA64位的服务器断电,后来维护厂商在不明缘由下,多次反复启停主机。接下来发现数据库丢失了2个重要的数据文件。
在数据库遭受损坏时,可以通过BBED工具对数据块进行修复,BBED的copy命令等对恢复非常有效。
在初期恢复时出现了ORA-600 4000号错误,这个错误以前写过几个案例,一般没有好的办法,只能通过bbed修复。
在回滚段8上存在一个需要恢复的事务,导致了异常,我不再管这个错误的具体含义,只是确认这个表空间可以清理掉,就开始向下进行
故障的原因是技术人员将数据库中的几个数据字典表Truncate掉,这直接导致了数据库不可用。数据库环境为Oracle 9.2.0.7 RAC环境。
以前我说:年终难终 进入数据库事故多发期,一年一度今又是,记得另外一个圣诞节,我还和Biti一起在北京的时候,遇到上海的朋友数据库崩溃 |