数据恢复与软故障处理基本指南(4)
经验总结：分区类型只是一个字节，却会带来如此严重的后果。可见，修复数据必须异常慎重。
3、 NT SERVER硬盘崩溃一例
相应情况：
这是单位里的一台NT服务器。三个NTFS分区，有重要数据在内。硬盘崩溃，不能启动，软盘启动后，用NTFSDOS 不能映射任何逻辑分区。
工具准备：
DISK1 - WIN98启动盘（带DEBUG）
DISK2 - DISKEDIT等工具（此盘不要写保护）
修复过程：
用DEBUG读取主分区表，发现完全混乱。反汇编后发现为一段有逻辑意义的代码，我当时十分紧张，以为硬盘被加密了。只好向一个高手HIT-007求援，不料他用DEBUG看了两下，马上退出来，做了FDISK/MBR。我大惊失色。但重起后，硬盘竟能启动进入NT，当然只剩下C一个分区。而后我很容易的恢复了另外两个分区。他对我说，你一看MBR中的内容就被吓住了，我向后看后面的一些系统扇区情况都是正常的。这就说明只是MBR不正常而已。
经验总结：数据恢复中情绪的因素很重要，无论什么情况不能慌张，因为这可能影响到你 是否能全面冷静的思考。
4、 NOVELL服务器掉电问题一例：
相应情况：
这是两年前处理过的一个问题，我当时在某证券营业部兼职做网管，开市时，一台NOVELL服务器因UPS故障突然掉电重起。当时的交易系统还是DBF数据库，按照规程，应该运行一个全部数据库重建索引例程。但索引中，却有7个库无法重建，检查发现，是库无法打开。
修复情况：
我恍惚记得深圳一个证券界电脑工程师对我说过，DBF文件头在突然死机中可能会损坏。但不知细节如何。我初步判定，由于库写入时，先修改文件头中的记录总数，再写入记录。可能是掉电时文件头已经修改但记录没有成功写入，因此，应该是记录数不符。但文件头中记录数在哪里呢。我于是这样处理，把这些损坏的数据库和一个完好的数据库COPY到本地，用FOXPRO打开看到记录数，换算成16进制。然后查找这个HEX串，判定找到记录数地址，（这个库记录数应当比较多，减少混淆的可能，否则容易找错）。由于我不知道处理DBF的公式，只好把损坏数据库的记录数每次减一，然后再用FOXPRO打开实验。其中5个数据库减一后就可以打开，只有一个数据库直到减4后才正常。全处理过程从掉电开始只有20分钟，基本没有影响交易进行。
经验总结：当出现问题，但你不知道确切的处理方法时，要充分进行分析。
5、 某财务系统数据处理一例：
相应情况：
也是我在证券公司处理的情况，某单机版财务系统，基于Clipper，当时是年初安装，使用正常至6月份底，突然发现该月数据紊乱，与实际出入巨大。出品公司的人来看过后，声称需要1周处理时间和近万元的处理费，我听说后，建议财务部拒绝其“讹诈”，由我来处理。
分析处理过程：
由于我对财务一窍不通，我请财务经理讲明了情况和一些概念，又分析了系统的大致结构。我发现本月每一笔数据都是正常的，只是因为多了上千笔没有发生的收支，才使汇总表发生了变化。那么这些数据是哪里来的，就成了问题的关键。在看了该软件的初始状态后，我似有所悟，问财务软件初装后并没有的上百个“科目”是从哪里建立的。财务经理回忆是上年底从某营业部发来的，我当时就明白了，那个营业部是上一年6月成立的，问题显然出在该营业部提供的初始科目不为空，由于上年1-5月该营业部尚不存在，所以数据为空，而该营业部6月以后的数据则随科目转入了我所在营业部的财务系统。经过对当初转入初始科目的对照，证实了我的判断。于是，我做了一段程序，按照对应关系把相关数据从系统库中摘除。从分析问题到问题的解决，只用了三个小时。
最新相关文章发表评论