2005年11月18日

公司一块80G 迈拓金九硬盘,某天突然进不了分区,提示为“无法访问X: 参数错误”。硬盘上为该公司为本市摄制和编辑的运动会视频和音频文件,摄录磁带中已清除,运动会也不可能再开一次。先前到某电脑公司去试过,结果没能解决问题。广告公司经理和我的一个朋友是朋友,知道此事后就转来我处。

  修复过程:该硬盘为只有一个NTFS分区的数据盘,先在DOS下用扇区编辑软件查看LBA0–63扇区,结果发现分区表和63扇区都有错误,1—62扇区间有大量扇区被写上不明代码,87-102扇区不正常,先手工修复分区表,恢复63引导扇区,删除1—62扇区间的代码。87-102扇区之间暂不处理,到WINDOWS下检查,结果还是出现同样的提示,试用恢复软件1,可以看到目录结构,再试FINALDATE,这个软件此时太不尽人意;用恢复软件1选择某目录进行试恢复,结果28个试恢复文件只恢复2个,其余的全部为0字节,恢复工作陷入困境。再次对79-102扇区进行分析,79扇区面目全非,被严重篡改破坏,80-86扇区被清空,87-102扇区的内容也不正常。经过一番苦思冥想,对某些扇区进行备份后做清除,备份被放到1-62扇区之间,以备不测时改回原样。

  再次在WINDOWS下用恢复软件1进行恢复,让其读该盘约10秒钟,停止扫描,看到的内容和前面提到的相同,试恢复一个文件夹,从恢复过程能看到这时恢复动作正常了,随后对其余的文件和文件夹进行恢复,近3个多小时后,63.9G资料全部恢复,文件中几乎就AVI、WAV、PSD和其它格式的图形文件,逐个打开完全正常。恢复工作顺利结束,大功告成。

  后来一个朋友说这个分区应该是2000格式化出来的,mft在分区的前面,很容易被破坏,象此案里里面87-102扇区里大约有6个左右的用户文件/文件夹是恢复不出来的,但102~~以后的文件应该能完全恢复的。在ntfs里面,一般90扇区以后的mft才是用户的文件信息,前面的是系统的一些元文件,对数据恢复影响不大的。

  个人觉得ntfs还是比较先进的,文件碎片都放在一个mft里面,只要这个扇区没有被破坏,就可以恢复。

  NTFS的结构确实比较复杂,正常情况下所有的操作MFT中有记录。但是,那些扇区被使用,那些没被使用,这些概念还是很有用的。

  实验盘被删除79-102扇区内容后,开机后不需要第三方软件,文件和目录直接可以读出拷贝到其它地方。查看被删除扇区内容,95扇区后的内容都自动修复了,80-94嘛。。。。看来MFT中应该还有一个备份,或是具有自动修复功能。

  故障盘为何就不能自动修复?且不让访问。故障盘中某些扇区看来是被利用了。它的数据恢复是通过第三方软件得到的,对第三方软件来讲,就算格式化了,绝大部分数据还是能找回来的。

  

俗话说得好,请神容易送神难,出于某种需要安装了一些软件,当不再需要使用它们时,诸如非法删除、软件非法关闭、软件自身的BUG等方面的原因,常常会出现该软件不能卸载或卸载不完全等现象,有时候我们在删除某个文件或文件夹时,系统提示无法删除,这的确令人十分头疼,现在我们就来看看解决的办法。

一、常规解决办法

1.注消或重启电脑,然后再试着删除。

2.进入“安全模式删除”。

3.在纯DOS命令行下使用DEL、DELTREE和RD命令将其删除。

4.如果是文件夹中有比较多的子目录或文件而导致无法删除,可先删除该文件夹中的子目录和文件,再删除文件夹。

5.如果是在“添加或删除程序”选项卸载一个软件后,发现软件的安装目录仍旧存在,里边残留着几个文件,直接删除时,系统却提示文件正在使用无法删除。

此时可首先打开“命令提示符”窗口,按“Ctrl+Alt+Del”组合键打开任务管理器,在进程中将“explorer.exe”进程关闭掉(在这之前最好将所有程序关闭掉,如图1),切换到命令提示符窗口,使用DOS命令进入无法删除的文件夹,输入“Del 文件夹名”就可以将该文件夹删除了。删除完成后,在任务管理器中选择“文件→新任务”,输入“explorer.exe”重新建立系统的外壳。

 

二、高级解决方案

1.磁盘错误

运行磁盘扫描,并扫描文件所在分区,扫描前确定已选上修复文件和坏扇区,全面扫描所有选项,扫描后再删除文件(图2)。

 

2.预读机制

某些视频、图像文件播放中断或正在预览时会造成无法删除。在“运行”框中输入:REGSVR32 /U SHMEDIA.DLL,注销掉预读功能。或在注册表中删除[HKEY_
LOCAL_MACHINESOFTWAREClassesCLSID{87D62D94-71B3-4b9a-9489-5FE6850DC73E}InProcServer32]键值。然后即可删除文件。

3.防火墙

由于反病毒软件在查毒时也会导致执行删除时提示文件正在使用,这时可试着停止或关闭它再删。

我常常在想,如果数据库不用考虑数据恢复,对我们这些做数据库的人来说,日子也许将变过美好很多。

  没有一种软件会象数据库这样,需要面对如此恶劣的环境。你需要考虑各种可能的错误和故障,例如系统断电、磁盘损坏、甚至是地震火灾。而给你的目标非常明确:不论发生何种故障,数据都不能被丢失,你可能觉得这有些小题大做,可对于许多商业应用(如银行、火车订票系统等)来说,这只不过是最基本的要求。

  要保证每一步操作都不会丢失,既无必要,也无可能(除非你能发明一种和硬盘一样大,和内存一样快,同时断电时数据不丢失的东东)。因此同并发控制中一样,数据库同样也利用了事务的概念。事务是这样一组操作,这组操作要么都做,要么都不做(我们通常把这叫做事务的原子性)。而当你决定结束一个事务时,你可能会选择:是提交(COMMIT)这个事务,还是应该滚回(ROLLBACK)它。如果你选择提交,那么你在这个事务中所做的全部修改都会被存入数据库中,如果这个数据库系统足够强壮,它将保证:只要事务提交完成,不管今后发生何种故障,事务所做的修改都不会丢失。如果你选择滚回,那么系统将回到事务开始的状态,你在该事务中所做的所有修改都将丢失。如果在事务运行当中,系统发生了任何故障,你会期望它的结果应该和你滚回这个事务一样。

  恢复的本质是数据的冗余,在众多的冗余手段中,日志(log)也许是我们最常使用的技术(尽管我们还有许多其它的选择,如影子页面等)。在我们对数据库进行修改之前,系统会将数据修改前的影象(前项)和你要修改的数据影象(后项)保存在日志当中。在这个过程中,有两点需要保证。一是日志必须先于它对应的修改被写入数据库,我们把这叫做先写日志(WAL)协议,这很容易理解,想象一下,如果修改被先写入数据库,而系统在日志被写入之前崩溃了,那么它将无法把该事务恢复到开始的状态。二是在事务提交之前,必须将它的日志写入数据库。否则,系统无法保证后续的故障不会丢失该事务的修改。我们将不能实现我们在前面对用户所做出的承诺。

  我们继续上文的讨论,看看我们到底有哪些故障需要应付。

  首先是应用故障,例如用户不小心错删了一张表,或者应用破坏了完整性约束。这种故障的恢复非常简单,对于前者,你可以显式地滚回事务(利用日志的前项),如果你不小心提交了事务,那么问题就麻烦了,系统也许只能把它当作介质故障(利用备份)来恢复了;对于后者,系统会强迫把该事务滚回。只要数据库还在运行,在系统看来,事务的滚回与其它正常操作并没有什么区别。

  然后是进程故障,假如在系统运行时,一个client崩溃了,或者网络断了(通常服务器无法区别这两种状态);或者服务器端的某个进程死了。这时我们恐怕得为系统配置一个监视进程,由它来定期地检查系统状态,恢复或清除失败的进程(连接),同时把对应的事务滚回。我们会希望这个监视进程是所有进程的父进程,因此假设连它也死了,我们就能把这种情况归结到后面将要讨论的系统故障。

  接着是系统故障,假如系统因为内部错误(例如数据库或操作系统含有bug),或者发生断电。这时缓冲区里的数据全部丢失,但幸运地是磁盘上的数据还在。因此系统在重新启动(RESTART)后,首先重做所有事务的修改(利用日志的后项),这就让数据库回到了发生故障时的状态,这时再将所有在这一点上未提交的事务滚回就完事了。注意这一过程是自动完成的,你完全不需要去关心它。

  再接着是介质故障,假如磁盘出现了坏磁道,或者整个磁盘报销了。这时上面的数据肯定已经丢失了。由于介质故障只能在你试图再次存取磁盘时被发现,而这时故障可能早已发生。因此对介质故障的恢复需要你的参与才能完成。你必须定期地备份(BACKUP)数据库,这样,当介质故障发生时,你可以先用备份重新覆盖整个数据库(RESTORE过程),然后利用日志重做从备份那点到当前的数据库的更新(ROLL-FORWARD过程),接下来的事情就和系统故障完全一样了。你可能会问,那要是日志也坏了怎么办呢?没办法,鸡生蛋、蛋生鸡,总得有个头吧。所以你最好祈祷日志不要坏,为了保证这一点,你应该对日志文件进行镜象,或者干脆用RAID。

  除了这种恢复方式,我们还有一种叫做逻辑恢复的方式,也就是利用我们常常在用的IMPROT/EXPORT工具对数据进行备份/恢复。当然我们只把它看作是介质故障恢复的一种辅助形式(也许它更适合于恢复我们前面说的那种应用故障),因为你只能把数据恢复到你备份的那一点。

  最后是灾难,象发火灾、被人黑了什么的,这时整个系统可能被完全破坏。你当然仍然可以对数据库进行备份,然后把备份(磁盘)放到另一个安全的地方,但这样做,备份以后数据库所做的修改可能就永久丢失了。一个更为稳妥的办法是我们在远程建立一个备份系统,所有在本地产生的日志同时也送往这个远程系统,为了防止网络发生故障,本地与远程系统之间应该同时建立几条相互独立的网络连接。这听上去好象有点超前,可实际上许多关键应用早就用上了。

  应该明白的是,恢复毕竟是一种非常耗时的工作,特别是进行后三种故障的恢复时,数据库对用户不可用。而这对象银行这样的部门来说,损失实在太大了。因此在很多情况下,我们只把恢复看作是最后的一道防线,我们希望最好永远也别需要用到它。因此现在就出来了各种各样的容错设备,象RAID、双机系统什么的,它们会把故障发生的概率降低到一个实际上可能永不发生的程度。