Oracle数据库如何进行数据拯救

最近这段时间，接二连三的接到数据拯救的项目。本来觉得数据拯救是体力活，技术含量并不是很高，但是如果客户都有这种认识，在维护工作中掉以轻心，那么出问题的机会还是很高的。其实从数据库的角度来说，数据拯救不是万能的，数据库的安全第一关还是把空在DBA手里，如何把好第一关是十分关键的。DBA要了解到从Oracle的角度来说，数据拯救能做到什么，是十分关键的。那么数据拯救能作些什么呢？

1、数据库整个挂掉了：没什么好说的，如果有备份，尽量使用备份恢复，如果没有备份，或者没有使用归档模式，那么只能通过DUL下载数据。如果你的数据库很大，或者使用了NVARCHAR之类的国际字符类型，或者大量使用自定义对象，使用DUL是个很痛苦的事情，而且DUL回来的数据，是可能存在部分脏数据的，存在脏数据比少几条记录要麻烦的多

2、出现坏块：坏块的种类有多种，出现ORA-1578的，出现ORA-8103的，出现坏块后最好是祈祷一下，如果坏的是索引，那是比较幸运的事情，重建一下索引就OK了。如果坏块出现在数据上，那么期望这个数据是不很重要的，否则麻烦就大了。而如果不幸的是你的老板告诉你丢失一条数据你就下岗，而坏块正好出现在这种地方，那么你最好希望坏块出现在段头、BMB之类的地方，而不要出现在真正的数据上。如果坏块包含有用的数据，那么虽然我们可以跳过坏块将其他数据导出，但是坏块破坏的数据就很难修复了。如果仅仅是块头被破坏，使用orapatch还可以进行修复，或者我们把数据DUMP出来，人工分析。而如果整个块坏掉了（通常会报ORA-8103)那么这个块的数据想要完全恢复是很困难的了。这种时候，你应该希望开发人员很喜欢建索引，如果有大量的索引，那么你还是有可能将坏块对应记录的部分字段的数据拯救出来，甚至运气好的话还可能通过这些数据，找到数据的原始记录，并将数据补充完整。

如果坏块出现在回滚段上，而且那个回滚段正好又是有用的，那么麻烦来了，虽然可用通过强制参数强行打开数据库，但是强制离线或者删除活跃的回滚段，可能会带来的后果是产生部分脏数据或者带来一些额外的逻辑坏块。幸运的是仅仅会带来逻辑坏块，坏块中的数据还是可能被DUMP出来后人工分析，的，不会带来大面积的数据丢失。这种情况下，Oracle的内部工具txchecker就十分有用了，在强制打开数据库前，使用txchecker分析一下，会减少不少麻烦。

如果坏块出现在REDO LOG上，那么最好这个REDO LOG是非当前的，最好是非活跃的，这样只要将REDO LOG CLEAR掉，就可以解决问题了。如果是物理坏块，重建REDO LOG组也很方便。如果不幸的是当前的REDO LOG出现了坏块，那么强制清除当前REDO LOG，可能会带来脏数据的风险。

 3、误删表/错误的TRUNCATE

 错误的将不该删除的表做了drop table,这时候可能你希望你使用的是Oracle 10G，这时候可以通过表闪回技术将表从回收站里恢复回来（恢复回来后注意索引名字会改变，如果你想用回以前的名字，需要重新创建）。如果运气不好，使用了9i或者更早的版本，那么你就需要dul工具了。实际上dul工具在国外是Oracle标准的技术支持的一部分，任何合法的Oracle客户都可以通过客服申请这个工具，而在中国这个工具被神秘化了，只有通过购买Oracle的紧急恢复服务才能够使用这个工具（Oracle的工程师带工具到现场使用），这个时候，数据第一，被宰一刀也只能认了。不过好消息是这个工具现在流传很广，很多做第三方的服务的公司都有这个工具，第三方虽然不是慈善机构，但是价格比Oracle原厂来说，是慈善的多了。误删表后，如果该表十分重要，立即将该表所在的数据文件OFFLINE，或者暂停业务系统，然后将该文件拷贝出来，这样你的数据就保住了，今后无论采取何种方法，都可以恢复你的数据

和错误的DROP TABLE类似，错误的TRUNCATE表也是危害巨大的。错误的TRUNCATE是十分危险的，这和DROP略有不同，但是也可以采取和DROP TABLE类似的方法进行数据恢复，因为TRUNCATE TABLE的时候，这些段里面的数据还是被保留下来的，而且里面的SEG/OBJ号仍保留原来表的DATA_OBJECT_ID，只是TRUNCATE后的表的DATA_OBJECT_ID会使用一个新的。这样只要文件中的这些段还没有被使用，还是可以被恢复的，这时候，尽快OFFLINE数据文件，并将文件拷贝出来就十分重要了。

4、错误的DELETE

如果不小心把有用的数据DELETE了，怎么办，如果使用的是Oracle 9i，那么使用flash back技术，就可以把数据恢复过来了。如果是早期的版本，那么麻烦就大了，通过在线日志也许能够恢复部分数据，但是十分困难。这个时候只能希望你的数据库是跑在归档模式下了

5、EXP DUMP文件损坏

如果你有一个DUMP文件，想导入数据库，发现DUMP文件损坏，无法导入。如果你的编程能力够强，那么就可以写一个程序从DUMP文件里把数据导出到一个平面文件里，再用SQL*LOADER导入，因为DUMP文件里面包含创建表的脚本、INSERT数据的脚本，以及每一行的数据。dul 10版也提供了一个工具，可以用来修复损坏的dump文件，导出成sqlloader的格式。

以上不一定很完整，但是作为DBA，数据拯救的事情最好不要出现，为了安心的睡好每一觉，最好做好以下几件事：

1、最好使用归档模式，如果领导不同意，就不停的建议，使用归档模式，起码有一个恢复手段在那里，睡觉也会安稳一些

2、经常检查备份集，确保可用

3、对常用表的访问，最好作些限制，DROP.TRUNCATE之类的操作最好能够作些控制（通过系统触发器）

4、对一些重要的表，最好经常作一些逻辑备份，以备不测

5、如果单位有钱，第一件事情就是要拿出来建一个DATAGUARD，看你有多大本事劝说领导投资了

6、如果系统出问题，尽量不用shutdown abort,如果数据库关闭不下来，先杀掉所有的前台进程，而不要强制关机

7、经常检查操作系统的情况，如果发现IO问题，不要掉以轻心

8、SWAP区的设置不能太小

9、ULIMIT之类的操作系统限制一定要设置未UNLIMITED，FILE TABLE的数量一定要足够


 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31448824/viewspace-2138074/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31448824/viewspace-2138074/