数据库损坏的恢复方法
出处:网络

　　我几年来，最担心的是客户忽然打电话告诉我数据库坏了，这可能是狐友最恐惧的事。

　　在98年时，我的指导老师告诉我，尽量不要使用数据库，数据库比自由表容易损坏。从此我作给别人和的软件，就尽量不用数据库只用自由表，还有一个目的是自由表比较通用，特别适合学校这样的单位，学校的数据特点是跨部门跨平台跨软件频繁交换。dbf库用delphi或foxbase或excel都可以读，大多数的校园管理软件都有dbf的接口。

　　这几年来做了许多简单软件，这些软件也遇上了很多停电，基本都没有出问题，按我老师说是因为自由表比数据库更不容易损坏。

　　除了有一个软件频频发生故障。这是98年做的一个在基层交警大队用的网络理论考试软件。用的大队有十几个，基本上是用旧机（486）改造网络，网络极其不稳定。由于采用f/s的方式，所以停电、网络不稳定很容易导致库损坏。第一次我要求各大队更换服务器为新机或者稳定机，给服务器买ups，更换稳定的网络设备，并且把交换机锁在箱子里，避免别人接触。果然大大减少了库损坏机率。

　　但依然时有发生故障，均观查特别容易发生在有存放学员相片的大队，因为我把相片存入自由表的通用型字段，用了一年半后自由表的fpt会达到3G以上，dbf自身体积是800M。所以我把库结构修改了，删除相片通用型字段。建立一个相片目录，所有的相片都以文件的形式保存在目录中。因为还有一个备注型字段存放试卷，所以fpt文件还在，fpt体积从5G减少至1G。又观查了一年，机率又减小了许多，很后悔当时设计自由表时没把试卷作为文件单独存放，可是改这个部分工作量太大，不如让我去死。试想如果真得没有备注型字段，损坏机率还可以降低。

　　仍然偶有奇异现象发生。即是在查询时找到的一些记录，在显示或编辑时忽而不见，忽而变身。有时显示还有记录，但忽然又发生文件尾错误，交警同志称为我的系统遇鬼了。把这个库带回家反复研究发现是索引文件不对，修改程序为，服务器程序一启动就判断今天是否索引过了，如没索引过，就把数据表独占，进行reindex的重建索引的工作，顺便也把数据表物理删除(pack)，并把备注文件浪费空间释放(pack memo)。在重建索引的同时让工作站出示“等待服务器整理数据库”提示。后来曾经下决心不使用索引文件了，可是很快就发现没有索引的数据库慢的令人受不了。再后来改为一个月由电脑自动重建索引，并提供一个手工重建索引的菜单，并提示客户如果发现同类异常现象就手工启动。这个闹鬼现象就基本消失了，代价是服务器常常要自动重建索引，工作站必须等待五分钟左右。有时数据表损坏了，就不能进reindex操作，必须先处理好数据表。此时我常采用建立空表，appe from 坏库 命令尽可能最大恢复数据表。
　　
　　以上是我在三年左右维护中，遇到数据库损坏及我自己试验的尽可能避免办法，很希望能听到有经验的大侠能够指导我，一同找到一个比较好的解决办法，（当然除了用SQL数据库）

二、库损坏后的自动处理方法
　　库损坏后，要尽可能的让用户用最短的时间恢复工作。这方面我没有什么经验，请高手指点一些方法。
我最早采用备份单个数据表的方式，坏哪个，恢复哪个。虽然能够尽可能多的保存有效数据，但是我担心单库备份，有时会出现几个数据表不一致的现象，因为生产、管理中，几个数据表的变化是相关的，恢复最多的数据表很可能和恢复最少的数据表相关数据发生不一致，比如销售库全部恢复了，库存库只恢复了一部分，就会出现一个商品卖了后库存中还有的混乱情况。导致操作员一头雾水，他弄不清楚什么数据回来了，什么数丢了。
所以我现在往往采用“断点恢复”的方法，由系统每天开机时把全部数据表压缩保存，记录详细时间，如果出现数据库损坏则可以跳回昨天那个断点。这样操作员就比较清楚，数据丢失的是今天一天的，补输即可。也可以由操作员随时手工备份设置断点，因为每个断点都有设置精确的时间，所以操作员恢复到某个断点后就很明白要补输入哪些内容。
我也找到另一种尽可能恢复最多数据的方法是，有的数据库损坏了，打开后不能重建索引不能pack，也不能移动指针至末尾。把损坏数据表改名，生成一个空的同结构带索引的数据表，用append from的方法可以从损坏的数据库表中获得最多的数据。这种方法即使没有备份，也能够尽可能的获得最多的数据，有时还能恢复全部的记录数。（能够恢复全部的记录数的情况常常是备注恢复不太完整）

[返回]

首页 | 设为首页 | 加入收藏 | 关于本站 | 友情链接 | 版权声明