在归档模式下删除非系统文件的恢复，归档

在归档模式下删除非系统文件的恢复，归档

众所周知，我们的核心生产数据库通常都是在归档模式下运行的，更不用说还配置DG环境的了。开启归档，并保证所有归档不丢失，就能保证我们对数据库所做的任何修改不会丢失，归档日志可谓是恢复的根本，如果丢失归档，那么即使RMAN功能再强大，也无法对丢失的数据进行恢复。所以我们通常配置的RMAN策略就是全备+归档+控制文件自动备份。这里的归档不是指数据库创建以来生成的归档(那量也太大了)，而是当进行RMAN非一致性备份时新产生的那部分归档日志，用来保证数据库可以前推到一致性状态，这样才能顺利open数据库。以下的测试只是想说明归档日志对恢复数据的重要性，并没有用到RMAN来进行恢复。
测试一：归档日志健全未丢失
--连接到Oracle，确保是运行在归档模式下 [oracle@ora10g ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on 8 13:46:53 2014
Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options
SQL> archive log list Database log mode              Archive Mode    --归档模式 Automatic archival             Enabled Archive destination            USE_DB_RECOVERY_FILE_DEST Oldest online log sequence     172 Next log sequence to archive   174 Current log sequence           174 SQL> set lin 130 pages 130 SQL> col name for a45 SQL> select file#,name from v$datafile;
     FILE# NAME ---------- ---------------------------------------------          1 /u01/app/oracle/oradata/ora10g/system01.dbf          2 /u01/app/oracle/oradata/ora10g/undotbs01.dbf          3 /u01/app/oracle/oradata/ora10g/sysaux01.dbf          4 /u01/app/oracle/oradata/ora10g/users01.dbf          5 /u01/app/oracle/oradata/ora10g/example01.dbf
--创建测试表空间、用户、表 SQL> create tablespace zlm_test datafile '/u01/app/oracle/oradata/ora10g/zlm01.dbf' size 50m;
Tablespace created.
SQL> create user zlm identified by zlm default tablespace zlm_test;
User created.
SQL> grant connect,resource to zlm; --赋权限
Grant succeeded.
SQL> select file#,name from v$datafile;
     FILE# NAME ---------- ---------------------------------------------          1 /u01/app/oracle/oradata/ora10g/system01.dbf          2 /u01/app/oracle/oradata/ora10g/undotbs01.dbf          3 /u01/app/oracle/oradata/ora10g/sysaux01.dbf          4 /u01/app/oracle/oradata/ora10g/users01.dbf          5 /u01/app/oracle/oradata/ora10g/example01.dbf          6 /u01/app/oracle/oradata/ora10g/zlm01.dbf    --新增了6号文件作为测试表存放的物理介质
6 rows selected.
SQL> create table zlm.test1 as select rownum as id,object_name from dba_objects where rownum<=5;
Table created.
SQL> col object_name for a15
SQL> select * from zlm.test1;
        ID OBJECT_NAME ---------- ---------------          1 ICOL$          2 I_USER1          3 CON$          4 UNDO$          5 C_COBJ#
--查看当前online日志文件状态 SQL> select group#,status,archived from v$log;
    GROUP# STATUS           ARC ---------- ---------------- ---          1 INACTIVE         YES          2 INACTIVE         YES          3 CURRENT          NO    --当前日志组为3，未归档
--归档当前日志（多次） SQL> alter system archive log current;
System altered.
SQL> alter system archive log current;
System altered.
SQL> alter system archive log current;
System altered.
这里进行了3次归档当前日志文件的操作，目的是使online日志被刷新，强制其归档，写到归档日志中去，因为我们要测试的是归档，否则恢复文件时，会自动去online日志中查找，即便是非归档模式，只要online日志还未被刷新，依旧是可以恢复的

SQL> select group#,status,archived from v$log;
    GROUP# STATUS           ARC ---------- ---------------- ---          1 INACTIVE         YES          2 INACTIVE         YES          3 CURRENT          NO    --虽然看起来和刚才上一步一致，但此时其实已经把第3组online日志刷新掉了
--保险起见，再归档一次（可选） SQL> alter system archive log current;
System altered.
SQL> select group#,status,archived from v$log;
    GROUP# STATUS           ARC ---------- ---------------- ---          1 CURRENT          NO          2 INACTIVE         YES          3 ACTIVE           YES    --现在新一轮的第3组的日志也已经归档了
--一致性关闭数据库，在OS级别删除测试文件datafile 6 SQL> shutdown immediate
Database closed. Database dismounted. ORACLE instance shut down. SQL> ! [oracle@ora10g ~]$ cd $ORACLE_BASE/oradata/ora10g [oracle@ora10g ora10g]$ ll -lrth total 1.7G -rw-r----- 1 oracle oinstall  51M Sep  5 10:13 test02.dbf -rw-r----- 1 oracle oinstall 301M Sep  5 10:13 test01.dbf -rw-r----- 1 oracle oinstall 201M Sep 16 16:56 temp01.dbf -rw-r----- 1 oracle oinstall  51M Sep 18 13:49 redo02.log -rw-r----- 1 oracle oinstall  51M Sep 18 13:51 redo03.log -rw-r----- 1 oracle oinstall  51M Sep 18 13:51 zlm01.dbf -rw-r----- 1 oracle oinstall  31M Sep 18 13:51 users01.dbf -rw-r----- 1 oracle oinstall 166M Sep 18 13:51 undotbs01.dbf -rw-r----- 1 oracle oinstall 561M Sep 18 13:51 system01.dbf -rw-r----- 1 oracle oinstall 271M Sep 18 13:51 sysaux01.dbf -rw-r----- 1 oracle oinstall  51M Sep 18 13:51 redo01.log -rw-r----- 1 oracle oinstall 101M Sep 18 13:51 example01.dbf -rw-r----- 1 oracle oinstall 7.2M Sep 18 13:52 control03.ctl -rw-r----- 1 oracle oinstall 7.2M Sep 18 13:52 control02.ctl -rw-r----- 1 oracle oinstall 7.2M Sep 18 13:52 control01.ctl [oracle@ora10g ora10g]$ rm -f zlm01.dbf  [oracle@ora10g ora10g]$ exit exit
--重启数据库 SQL> startup ORACLE instance started.
Total System Global Area  285212672 bytes Fixed Size                  1218992 bytes Variable Size              88082000 bytes Database Buffers          192937984 bytes Redo Buffers                2973696 bytes Database mounted. ORA-01157: cannot identify/lock data file 6 - see DBWR trace file ORA-01110: data file 6: '/u01/app/oracle/oradata/ora10g/zlm01.dbf'
可以看到，此时是无法open数据库的，因为数据库文件物理上已经不存在，而在控制文件中是有记录的，这里提示的是“cannot identify/lock data file 6”，而当如果仅仅是物理上存在，数据文件头中的信息与控制文件中记录的数据文件头信息不一致时，会提示xxx文件需要恢复
--手动创建一个datafile 6 SQL> alter database create datafile 6;

Database altered.
注意，此时仅仅是创建了一个不一致的datafile 6而已，也可以通过RMAN的restore datafile 6;命令来实现，作用是一样的
--恢复datafile 6 SQL> recover datafile 6; ORA-00279: change 983806 generated at 09/18/2014 13:47:22 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_174_%u_.arc ORA-00280: change 983806 for thread 1 is in sequence #174

Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto    --此处输入auto，让数据库自动匹配，去寻找需要的日志去恢复数据库 ORA-00279: change 983923 generated at 09/18/2014 13:49:44 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_175_%u_.arc ORA-00280: change 983923 for thread 1 is in sequence #175 ORA-00278: log file '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_174_b1nwmrpv_.arc' no longer needed for this recovery

Log applied. Media recovery complete. SQL> alter database open;
Database altered.
SQL> select * from zlm.test1;
        ID OBJECT_NAME ---------- ---------------          1 ICOL$          2 I_USER1          3 CON$          4 UNDO$          5 C_COBJ#
尽管online日志没有了，但由于归档日志从头至尾都没有删除过，很快地数据库完成了介质恢复，顺利地open了，测试表数据也未丢失
测试二：更改表内容后的归档日志全部丢失
--删除测试表中第5条记录并提交 SQL> delete from zlm.test1 where id=5;

1 row deleted.
SQL> commit;
Commit complete.
SQL> select * from zlm.test1;
        ID OBJECT_NAME ---------- ---------------          1 ICOL$          2 I_USER1          3 CON$          4 UNDO$
SQL> select group#,status,archived from v$log;
    GROUP# STATUS           ARC ---------- ---------------- ---          1 CURRENT          NO          2 INACTIVE         YES          3 INACTIVE         YES
--同样的，切3次归档，把online日志刷到归档去 SQL> alter system archive log current;
System altered.
SQL> alter system archive log current;
System altered.
SQL> alter system archive log current;
System altered.
SQL> select group#,status,archived from v$log;
    GROUP# STATUS           ARC ---------- ---------------- ---          1 CURRENT          NO    --此处online日志已经被刷新          2 ACTIVE           YES          3 ACTIVE           YES
--关闭数据库，在os级别删除datafile 6以及新增的归档日志文件 SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> ! [oracle@ora10g ~]$ cd $ORACLE_BASE/oradata/ora10g [oracle@ora10g ora10g]$ rm -f zlm01.dbf  [oracle@ora10g ora10g]$ cd $ORACLE_BASE/flash_recovery_area/ORA10G/archivelog/2014_09_18 [oracle@ora10g 2014_09_18]$ ll -lrth total 9.5M -rw-r----- 1 oracle oinstall 2.4M Sep 18 10:10 o1_mf_1_172_b1nhskdd_.arc -rw-r----- 1 oracle oinstall 469K Sep 18 10:14 o1_mf_1_173_b1nj0wxp_.arc -rw-r----- 1 oracle oinstall 6.1M Sep 18 13:49 o1_mf_1_174_b1nwmrpv_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 13:49 o1_mf_1_175_b1nwmzo4_.arc -rw-r----- 1 oracle oinstall 2.5K Sep 18 13:49 o1_mf_1_176_b1nwn43r_.arc -rw-r----- 1 oracle oinstall  37K Sep 18 13:51 o1_mf_1_177_b1nwpwxb_.arc -rw-r----- 1 oracle oinstall 477K Sep 18 14:01 o1_mf_1_178_b1nx9ry9_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 14:01 o1_mf_1_179_b1nx9y1k_.arc -rw-r----- 1 oracle oinstall 7.0K Sep 18 14:01 o1_mf_1_180_b1nxb6q1_.arc
这里14:01生成的3个归档日志，是我在删除测试表数据库后归档current online日志生成的
--为了方便恢复，移走这3个归档日志（未真正删除） [oracle@ora10g 2014_09_18]$ mv *178* ../ [oracle@ora10g 2014_09_18]$ mv *179* ../ [oracle@ora10g 2014_09_18]$ mv *180* ../ [oracle@ora10g 2014_09_18]$ ll -lrth total 9.0M -rw-r----- 1 oracle oinstall 2.4M Sep 18 10:10 o1_mf_1_172_b1nhskdd_.arc -rw-r----- 1 oracle oinstall 469K Sep 18 10:14 o1_mf_1_173_b1nj0wxp_.arc -rw-r----- 1 oracle oinstall 6.1M Sep 18 13:49 o1_mf_1_174_b1nwmrpv_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 13:49 o1_mf_1_175_b1nwmzo4_.arc -rw-r----- 1 oracle oinstall 2.5K Sep 18 13:49 o1_mf_1_176_b1nwn43r_.arc -rw-r----- 1 oracle oinstall  37K Sep 18 13:51 o1_mf_1_177_b1nwpwxb_.arc [oracle@ora10g 2014_09_18]$ exit exit
--启动数据库 SQL> startup ORACLE instance started.
Total System Global Area  285212672 bytes Fixed Size                  1218992 bytes Variable Size              88082000 bytes Database Buffers          192937984 bytes Redo Buffers                2973696 bytes Database mounted. ORA-01157: cannot identify/lock data file 6 - see DBWR trace file ORA-01110: data file 6: '/u01/app/oracle/oradata/ora10g/zlm01.dbf'
--再次创建数据文件datafile 6 SQL> alter database create datafile 6;
Database altered.
--对数据文件datafile 6进行介质恢复 SQL> recover datafile 6; ORA-00279: change 983806 generated at 09/18/2014 13:47:22 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_174_%u_.arc ORA-00280: change 983806 for thread 1 is in sequence #174

Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto ORA-00279: change 983923 generated at 09/18/2014 13:49:44 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_175_%u_.arc ORA-00280: change 983923 for thread 1 is in sequence #175 ORA-00278: log file '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_174_b1nwmrpv_.arc' no longer needed for this recovery

ORA-00279: change 983927 generated at 09/18/2014 13:49:51 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_176_%u_.arc ORA-00280: change 983927 for thread 1 is in sequence #176 ORA-00278: log file '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_175_b1nwmzo4_.arc' no longer needed for this recovery

ORA-00279: change 983931 generated at 09/18/2014 13:49:56 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_177_%u_.arc ORA-00280: change 983931 for thread 1 is in sequence #177 ORA-00278: log file '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_176_b1nwn43r_.arc' no longer needed for this recovery

ORA-00279: change 983974 generated at 09/18/2014 13:51:24 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_178_%u_.arc ORA-00280: change 983974 for thread 1 is in sequence #178 ORA-00278: log file '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_177_b1nwpwxb_.arc' no longer needed for this recovery

ORA-00308: cannot open archived log '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_178_b1nx9ry9_.arc' ORA-27037: unable to obtain file status Linux Error: 2: No such file or directory Additional information: 3
当执行auto后，第一个建议的归档位置是174，然后到175、176、177，都没有问题，一直到178，提示文件无法找到，由于178、179、180这3个归档日志被移走了，模拟被删除的情况，数据库无法自动获取到这3个归档日志，也就无法把datafile 6前推到数据库正常关闭前的一致性状态，这个时候想要恢复，就只能通过BBED工具来修改数据文件头信息来实现了，数据库自身以无法完成这个任务，如果这个数据文件对整个数据库而言并不是非常重要，那么可以先offline该文件，然后一致性打开数据库，当然，这个数据文件中的数据也就丢失了
--使datafile 6 offline SQL> alter database datafile 6 offline;
Database altered.
SQL> alter database open;
Database altered.
SQL> select file#,name,status from v$datafile;
     FILE# NAME                                          STATUS ---------- --------------------------------------------- -------          1 /u01/app/oracle/oradata/ora10g/system01.dbf   SYSTEM          2 /u01/app/oracle/oradata/ora10g/undotbs01.dbf  ONLINE          3 /u01/app/oracle/oradata/ora10g/sysaux01.dbf   ONLINE          4 /u01/app/oracle/oradata/ora10g/users01.dbf    ONLINE          5 /u01/app/oracle/oradata/ora10g/example01.dbf  ONLINE          6 /u01/app/oracle/oradata/ora10g/zlm01.dbf      OFFLINE
6 rows selected.
SQL> select * from zlm.test1; select * from zlm.test1                   * ERROR at line 1: ORA-00376: file 6 cannot be read at this time ORA-01110: data file 6: '/u01/app/oracle/oradata/ora10g/zlm01.dbf'
虽然打开了数据库，但测试数据表还是丢失了，丢失了归档，又没有备份过归档，那么丢数据库是在所难免得了，又一次证明了归档对数据恢复的重要性，由于刚才并未真正地删除归档，只是使了一个trick，那么就当我们之前对归档做了个手动备份，现在来恢复丢失的归档（mv回原归档路径）
SQL> shutdown immediate
Database closed. Database dismounted. ORACLE instance shut down. SQL> ! cd[oracle@ora10g ~]$ cd $ORACLE_BASE/flash_recovery_area/ORA10G/archivelog [oracle@ora10g archivelog]$ ll -lrth total 516K drwxr-x--- 2 oracle oinstall 4.0K Sep 12 10:33 2014_09_12 drwxr-x--- 2 oracle oinstall 4.0K Sep 15 17:19 2014_09_15 drwxr-x--- 2 oracle oinstall 4.0K Sep 17 12:30 2014_09_16 drwxr-x--- 2 oracle oinstall 4.0K Sep 18 10:15 2014_09_17 -rw-r----- 1 oracle oinstall 477K Sep 18 14:01 o1_mf_1_178_b1nx9ry9_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 14:01 o1_mf_1_179_b1nx9y1k_.arc -rw-r----- 1 oracle oinstall 7.0K Sep 18 14:01 o1_mf_1_180_b1nxb6q1_.arc drwxr-x--- 2 oracle oinstall 4.0K Sep 18 14:25 2014_09_18 [oracle@ora10g archivelog]$ mv *.arc ./2014_09_18 [oracle@ora10g archivelog]$ cd 2014_09_18 [oracle@ora10g 2014_09_18]$ ll -lrth total 9.5M -rw-r----- 1 oracle oinstall 2.4M Sep 18 10:10 o1_mf_1_172_b1nhskdd_.arc -rw-r----- 1 oracle oinstall 469K Sep 18 10:14 o1_mf_1_173_b1nj0wxp_.arc -rw-r----- 1 oracle oinstall 6.1M Sep 18 13:49 o1_mf_1_174_b1nwmrpv_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 13:49 o1_mf_1_175_b1nwmzo4_.arc -rw-r----- 1 oracle oinstall 2.5K Sep 18 13:49 o1_mf_1_176_b1nwn43r_.arc -rw-r----- 1 oracle oinstall  37K Sep 18 13:51 o1_mf_1_177_b1nwpwxb_.arc -rw-r----- 1 oracle oinstall 477K Sep 18 14:01 o1_mf_1_178_b1nx9ry9_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 14:01 o1_mf_1_179_b1nx9y1k_.arc -rw-r----- 1 oracle oinstall 7.0K Sep 18 14:01 o1_mf_1_180_b1nxb6q1_.arc [oracle@ora10g 2014_09_18]$ exit exit
SQL> startup mount
ORACLE instance started.
Total System Global Area  285212672 bytes Fixed Size                  1218992 bytes Variable Size              88082000 bytes Database Buffers          192937984 bytes Redo Buffers                2973696 bytes Database mounted. SQL> alter database datafile 6 online;
Database altered.
SQL> recover datafile 6; ORA-00279: change 983974 generated at 09/18/2014 13:51:24 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_178_%u_.arc ORA-00280: change 983974 for thread 1 is in sequence #178

Specify log: {<RET>=suggested | filename | AUTO | CANCEL} auto Log applied. Media recovery complete. SQL> alter database open;
Database altered.
SQL> select * from zlm.test1;
        ID OBJECT_NAME ---------- ---------------          1 ICOL$          2 I_USER1          3 CON$          4 UNDO$
当恢复了归档后，再次对datafile 6进行介质恢复，再open数据库以后，之前丢失的数据又回来了。 注意：当归档路径在OS上物理存在，只是默认位置不是FRA指定的路径，那么当执行recover datafile 6后，可以手动指定一个归档路径的位置，如： SQL> recover datafile 6; ORA-00279: change 983806 generated at 09/18/2014 13:47:22 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_174_%u_.arc ORA-00280: change 983806 for thread 1 is in sequence #174

Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_174_%u_.arc
Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_175_%u_.arc
Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_176_%u_.arc
Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_177_%u_.arc
Specify log: {<RET>=suggested | filename | AUTO | CANCEL} /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/o1_mf_1_178_%u_.arc    --注意区别，是mv后的新路径 ... ... 以此类推，这样也是可以完成recover的，只不过麻烦一些，但前提是，这些物件还存在！
总结：鉴于归档日志对于数据库的恢复非常重要，因此对归档日志的备份也要重视起来。可以这么说，归档日志就是对online日志的备份，对于那些写入数据文件的脏数据，和不一致数据而言，都是要通过归档日志来前滚到一致性状态的，只有当数据库的所有数据文件与关闭数据库时是一致的，才可以无需备份归档日志文件。

一般来说，硬盘的损坏按大类可以分为硬损坏和软损坏,硬盘损坏的种类。

硬损坏包括磁头组件损坏、控制电路损坏、综合性损坏和扇区物理性损坏（一般人称之为物理坏道）四种。

※ 磁头组件损坏：主要指硬盘中磁头组件的某部分被损坏，造成部分或全部磁头无法正常读写的情况,u盘数据恢复。磁头组件损坏的方式和可能性非常多，主要包括磁头脏、磁头磨损、磁头悬臂变形、磁线圈受损、移位等。

※控制电路损坏：是指硬盘的电子线路板中的某一部分线路断路或短路，或者某些电气元件或IC芯片损坏等等，导致硬盘在通电后盘片不能正常起转，或者起转后磁头不能正确寻道等。

※综合性损坏：主要是指因为一些微小的变化使硬盘产生的种种问题。有些是硬盘在使用过程中因为发热或者其他关系导致部分芯片老化；有些是硬盘在受到震动后，外壳或盘面或马达主轴产生了微小的变化或位移；有些是硬盘本身在设计方面就在散热、摩擦或结构上存在缺陷。种种的原因导致硬盘不稳定，经常丢数据或者出现逻辑错误，工作噪音大，读写速度慢，有时能正常工作但有时又不能正常工作等。

※扇区物理性损坏：是指因为碰撞、磁头摩擦或其他原因导致磁盘盘面出现的物理性损坏，譬如划伤、掉磁等。

软损坏包括磁道伺服信息出错、系统信息区出错和扇区逻辑错误（一般又被称为逻辑坏道）。

※磁道伺服信息出错：是指因为某个物理磁道的伺服信息受损或失效，导致了该物理磁道无法被访问。

※系统信息区出错：是指硬盘的系统信息区（硬盘内部的一个系统保留区，里面又分成若干模块，保存了许多硬盘出厂的参数、设置信息和内部控制程序）在通电自检时读不出某些模块的信息或者校验不正常,硬盘电路板测试及维修3，导致硬盘无法进入准备状态。

※扇区逻辑错误：是指因为校验错误（ECC错误和CRC错误）、扇区标志错误（IDNF错误）、地址信息错误（AMNF错误）、坏块标记错误（BBM）等原因导致该扇区失效。

一般来说，修复硬盘的软损坏是可能的，很多硬盘厂商发布的硬盘管理和维护软件（DM）都具备修复硬盘软损坏的能力。像扇区逻辑错误这样的问题，即使是一般的低级格式化软件,杭州scsi数据恢复，也是完全可以胜任的。不过在所有的软损坏当中，系统信息区出错属于比较难以修复的种类，因为即使是同一个厂商同一种型号的硬盘，系统信息区也不一定相同；而且硬盘厂商对于自己产品的系统信息区内容和读取的指令代码，一般是不公开的。但是对于IBM和日立的硬盘用户来说就比较幸运了，日立的DFT和IBM的DDD-SI软件对系统信息区出错还是有比较高的修复成功率的。这两个软件可是真真正正由硬盘的生产厂商发布的硬盘维修软件啊（DFT还是免费的），有非常强大的功能，效率和可靠性比起那些要价过万的第三方编写的软件都要高很多，可惜只对IBM和日立的产品有效。

当然，如果仅仅是为了修复软损坏，一个原厂的DM软件就可以完成90％以上的任务了，根本不需要购买上万元的所谓专业软件，而现在HDD Regenerator、MHDD、PC-3000和效率源等等这些软件,舟山硬盘数据恢复，在宣传上就说明了他们所针对的不仅仅是软损坏，而且连硬损坏里面的物理坏道甚至是一些IC的损坏都可以修复！
 

1.如果是短小TXT文档的话可以WINHEX扫描全盘。找几个自己还记得的关键字。
2.找回误删并清除了回收站的文档

步骤：

1、单击“开始——运行，然后输入regedit （打开注册表）

2、依次展开：HEKEY——LOCAL——MACHIME/SOFTWARE/microsoft/WINDOWS/ CURRENTVERSION/EXPLORER/DESKTOP/NAMESPACE 在左边空白外点击“新建”

，选择：“主键”，把它命名为“645FFO40——5081——101B——9F08——00AA002F954E” （主键就是项）

再把右边的“默认”的主键的键值设为“回收站”，然后退出注册表。就OK啦。

3、要重启你的计算机。

只要你机器没有运行过磁盘整理。系统完好.任何时候的文件都可以找回来。

3.EasyRecovery是一个威力非常强大的硬盘数据恢复工具，能够帮你恢复丢失的数据以及重建文件系统。
4.R-Studio 是功能超强的数据恢复、反删除工具，采用全新恢复技术，为使用 FAT12/16/32、NTFS、NTFS5(Windows 2000系统)和 Ext2FS(Linux系统)分区的磁盘提供完整数据维护解决方案！同时提供对本地和网络磁盘的支持，此外大量参数设置让高级用户获得最佳恢复效果。具体功能有：采用 Windows资源管理器操作界面；通过网络恢复远程数据(远程计算机可运行Win95/98/ME/NT/2000/XP、Linux、UNIX 系统)；支持 FAT12/16/32、NTFS、NTFS5 和 Ext2FS文件系统；能够重建损毁的RAID阵列；为磁盘、分区、目录生成镜像文件；恢复删除分区上的文件、加密文件(NTFS 5)、数据流(NTFS、NTFS 5)；恢复FDISK或其它磁盘工具删除过得数据、病毒破坏的数据、MBR 破坏后的数据；识别特定文件名；把数据保存到任何磁盘;浏览、编辑文件或磁盘内容等等。geis.onlinedown.net/...DR.zip
easyrecovery是威力非常强大的硬盘数据恢复工具。能够帮你恢复丢失的数据以及重建文件系统。EasyRecovery不会向你的原始驱动器写入任何东东，它主要是在内存中重建文件分区表使数据能够安全地传输到其他驱动器中。你可以从被病毒破坏或是已经格式化的硬盘中恢复数据。该软件可以恢复大于8.4GB的硬盘。支持长文件名。 被破坏的硬盘中像丢失的引导记录、BIOS参数数据块；分区表；FAT表；引导区都可以由它来进行恢复。
nn.onlinedown.net/...07.rar

我一直用免费软件Drive Rescue，......余下全文>>