对于题目中提到的动态 SQL，显然应该有一种静态 SQL 与之相对，那么两者应该怎么理解？我们先来个基本的认识。

静态 SQL 之“静态”，意味着在执行之前就已经明确了该 sql 在数据库执行后的业务含义，也就是对于做啥事儿我们是清楚的，只不过需要知道这事儿的具体内容有哪些。比如“select userID,username from users where deptName=’销售部’”，意思就是查销售部的所有用户 ID 及用户名。 再稍微灵活一点，可以写作“select userID,username from users where deptName=?”，此时语句中的“?”传递哪个部门名称，相对应的就查哪个部门的用户信息。但，sql 本身所要做的“查询某部门下的用户信息”这个事情我们是完全明确的，不确定的只是用户有多少，各自的信息是什么。

而动态 SQL 之所以称为“动态”，就是在是否“明确业务含义”这一点上是“不明确”的，也就是说 sql 应该执行出啥结果，我们本身并没有明确的预期，包括查什么、用哪些条件以及怎么组合这些条件等——原则上，这些都可以随意选择组合。

部门’”时，执行结果是查询某部门的用户信息；当传入“roleName=’技术主管’”时，则是按照角色筛选复合条件的用户信息。尽管都是返回用户信息，但不同条件下，我们可以认为是两个不同的业务，这里的 sql 我们就称之为是动态的，显然，这样的 sql 执行后得到的结果的业务含义也是完全不确定的。

同理，使用的物理表也可能不固定，例如定义为“select … from ${table} where …”时，”table”给定啥值就从哪个表查数据。

结合两者的具体含义，可以分析得到各自的优劣所在：

l 静态 SQL： 功能固定，比较传统，但相对比较安全。

l 动态SQL： 自由灵活，但同时不得不提到sql植入风险，一旦被攻击者利用可能的sql漏洞，会有相当严重的安全问题，如窃取用户信息、篡改数据等等。

而在常用的报表工具使用场景中，报表开发人员一般都没有DBA的功力，因此难以对sql的安全性问题考虑周全，动态SQL可能带来的风险也就很难排除。而要规避动态SQL风险，无非是下面两种方法：

1、 让dba配合工作，尽可能协助提供安全性高的sql；

2、 希望报表工具可以提供规避sql注入风险的方法。

方法 1 需要依赖外部DBA的配合，不是总能满足，所以，比较可行的，还是在考察报表产品时，考虑报表工具是否提供防sql植入风险的功能支持。不然，在安全第一的前提下，就只能不用动态sql，退而选择静态sql了，毕竟安全还是最重要的，一旦造成信息泄露，责任很难承担。

下面，我们就对比一下常见的两种报表工具，Birt和润乾报表，看看它们各自在动态SQL以及安全性方面的表现如何：

2、 应用程序来实现： 这个太麻烦，需要有Java开发能力，咱们就不介绍了，感兴趣的可以到网上搜索自行研究。

下面我们通过实例来讲解一下在数据集中通过script脚本拼接sql的方式。

注：例子以“员工表”为例，员工表内存放有“工资”及“应发工资”两个字段，我们通过动态SQL实现由终端用户选择应该查询“工资”列还是“应发工资”列

1、 新建报表并新增数据源（hsql）

如，数据集名称为“dt”,query text为“select * from 员工”。实际这里可以定义为空，但为了保存等操作不报错，这里需要随便写个 sql。

脚本如下（含义为当qField传进来是“工资”时，拼入工资字段查数据，为“应发工资”时则对应查询，默认查询工资列）：

前面 6 列为常规列，拖拽字段到 dataRow 即可，第 7 列位动态列，这里当根据传入参数的不同，显示不同的标题（header row）及数值（data row），其中

（1） 当输入qField参数为“应发工资”时

（2） 当输入qField参数为“工资”时

暂且不考虑上述操作涉及的复杂的制作过程，即便辛苦做出了效果，我们也不难发现其中留有很大漏洞，那就是这种拼串的方法很容易出现 sql 植入问题。

比如，当攻击者尝试给 qFiled 参数传入“身份证号”，而恰好又存在该字段的话，用户的身份证号信息就全部暴露了，同样，用类似的方法还可以猜到“电话号码”、“家庭住址”，等等等等，这些敏感信息的全面泄露，意味着安全保障的不堪一击。

而针对脚本这种做法，想要全面规避风险非常麻烦，可能的方式是在脚本里加入大量的判断，尽力排除所有 “身份证”、“电话号码”、“手机号码”等各种情况。对于一两个报表这么搞还行，多了肯定就费劲了，并且后期维护也得蒙圈。

润乾报表动态sql实现

同样以“员工表”为例，员工表内存放有“工资”及“应发工资”，我们来实现由终端用户选择应该查询“工资”列还是“应发工资”列。

润乾报表采用动态参数实现：

（1） 连接demo数据源

（2） 用向导生成报表

通过向导，一步生成如下网格式报表模板

（3） 修改数据集，增加动态列

A、增加报表参数“qFiled”

B、 数据集sql中增加动态列

采用宏的方式引入，sql改为如下

（4） 修改报表模板，增加动态列

A、 qFiled传入“应发工资”

很显然，仅从做法而言，润乾报表就比birt要简单的多，不需要写任何脚本即可实现，对开发人员的技术要求也不高，对应后期维护也就很轻松了。

当然这里也存在sql植入的风险，但是润乾报表作为一款商业软件，厂商已经为用户考虑到了，可以通过专门的配置规避风险，具体使用也很简单，但功能很强大。

关于sql植入及报表规避的有专门的文章做详细的介绍，可参考《报表的SQL植入风险及规避方法》url：** 报表的 SQL 植入风险及规避方法

不管是开源还是商业报表，可能对于某功能的实现都没什么问题，但制作方法的简便性、考虑问题是否周全（比如安全性问题）等方面的差距就可能会非常明晰。

开源报表固然有它的优点——不用花钱！！！ 但工作量相对要大很多，服务或支持也没有保障，只能靠用户自己埋头苦干去研究了。而商业报表则是一条捷径，虽然要花一点点 Money，但考虑到效率及安全性方面，那就真是完全可忽略的成本了。

更多报表及安全问题请查看:基础部署相关问题分类导航 报表类相关问题分类导航
* 报表的 SQL 植入风险及规避方法
* 动态交叉表头报表的制作
* 如何制作动态层分组报表

1. MySQL一棵B+树能存多少条数据？
2. 如果MySql 引起 CPU 消耗过大，怎么优化
3. MySql 死锁问题如何解决
4. MySql 数据存储在磁盘上是什么样子
5. 数据库连接池到底应该设多大
6. 为什么delete 表数据，磁盘空间却还是被占用
7. 主从复制解决了什么问题，出现同步延迟如何解决

MySQL一棵B+树能存多少条数据？

1 数据持久化存储磁盘里，磁盘的最小单元是扇区，一个扇区的大小是512 字节
2 文件系统最小单元是 块，一个块的大小是4K
3 InnoDB 存储引擎，有自己的最小单元，称之为页，一个页的大小是 16K

MySQL 的最小存储单元叫做“页”，这么多的页是如何构建一个庞大的数据组织，我们又如何知道数据存储在哪一个页中？
如果逐条遍历，性能肯定很差。为了提升查找速度，我们引入了 B+ 树，先来看下 B+ 树的存储结构：
页除了可以存放数据（叶子节点），还可以存放健值和指针（非叶子节点），当然他们是有序的。这样的数据组织形式，我们称为索引组织表。

如：上图中 page number=3 的页，该页存放键值和指向数据页的指针，这样的页由 N 个键值+指针组成。

B+ 树是如何检索记录？
1 首先找到根页，你怎么知道一张表的根页在哪呢？
2 其实每张表的根页位置在表空间文件中是固定的，即 page number=3 的页。
3 找到根页后通过二分查找法，定位到 id=5 的数据应该在指针 P5 指向的页中。
4 然后再去 page number=5 的页中查找，同样通过二分查询法即可找到 id=5 的记录。

1 查询数据库时，不论读一行，还是读多行，都是将这些行所在的整页数据加载，然后在内存中匹配过滤出最终结果。
2 表的检索速度跟树的深度有直接关系，毕竟一次页加载就是一次 IO，而磁盘 IO 又是比较费时间。对于一张千万级条数 B+ 树高度为 3 的表与几十万级 B+ 树高度也为 3 的表，其实查询效率相差不大。

一棵树可以存放多少行数据？

假设 B+ 树的深度为 2，这棵 B+ 树的存储总记录数 = 根节点指针数 * 单个叶子节点记录条数。

那么指针数如何计算？假设主键 ID 为 bigint 类型，长度为 8 字节，而指针大小在 InnoDB 源码中设置为 6 字节，这样一共 14 字节。

那么一个页中能存放多少这样的组合，就代表有多少指针，即 0。

那么可以算出一棵高度为 2 的 B+ 树，能存放 20 条这样的数据记录。

千万级的数据存储只需要约 3 层 B+ 树，查询数据时，每加载一页（page）代表一次 IO。所以说，根据主键 id 索引查询约 3 次 IO 便可以找到目标结果。

对于一些复杂的查询，可能需要走二级索引，那么通过二级索引查找记录最多需要花费多少次 IO 呢？
首先，从二级索引 B+ 树中，根据 name 找到对应的主键 id：

然后，再根据主键 id 从聚簇索引查找到对应的记录。如上图所示，二级索引有 3 层，聚簇索引有 3 层，那么最多花费的 IO 次数是：3+3=6。

聚簇索引默认是主键，如果表中没有定义主键，InnoDB 会选择一个唯一的非空索引代替。
如果没有这样的索引，InnoDB 会隐式定义一个主键来作为聚簇索引。这也是为什么 InnoDB 表必须有主键，并且推荐使用整型的自增主键！！！
InnoDB 使用的是聚簇索引，将主键组织到一棵 B+ 树中，而行数据就储存在叶子节点上。

①若使用"where id=14"这样的条件查找记录，则按照 B+ 树的检索算法即可查找到对应的叶节点，之后获得行数据。
②若对 Name 列进行条件搜索，则需要两个步骤：
第一步在辅助索引 B+ 树中检索 Name，到达其叶子节点获取对应的主键值。
第二步使用主键值在主索引 B+ 树中再执行一次 B+ 树检索操作，最终到达叶子节点即可获取整行数据。（重点在于通过其他键需要建立辅助索引）

如果MySql 引起 CPU 消耗过大，怎么优化（数据库层面，非数据库层面）

1 减少等待（避免CPU上下文切换带来的消耗）

SQL/index，使用合适的索引减少扫描的行数（需平衡索引的正收益和维护开销，空间换时间）

避免使用函数，将运算转移至易扩展的应用服务器中 如substr等字符运算，dateadd/datesub等日期运算，abs等数学函数

减少排序，利用索引取得有序数据或避免不必要排序 如union all代替 union，order by 索引字段等

禁止类型转换，使用合适类型并保证传入参数类型与数据库字段类型绝对一致 如数字用tiny/int/bigint等，必需转换的在传入数据库之前在应用中转好

简单类型，尽量避免复杂类型，降低由于复杂类型带来的附加运算。更小的数据类型占用更少的磁盘、内存、cpu缓存和cpu周期

index，优化索引，减少不必要的表扫描 如增加索引，调整组合索引字段顺序，去除选择性很差的索引字段等等
table，合理拆分，适度冗余 如将很少使用的大字段拆分到独立表，非常频繁的小字段冗余到“引用表”
SQL，调整SQL写法，充分利用现有索引，避免不必要的扫描，排序及其他操作 如减少复杂join，减少order by，尽量union all，避免子查询等
数据类型，够用就好，减少不必要使用大字段 如tinyint够用就别总是int，int够用也别老bigint，date够用也别总是timestamp

4 减少query请求量（非数据库本身）
适当缓存，降低缓存数据粒度，对静态并被频繁请求的数据进行适当的缓存 如用户信息，商品信息等
优化实现，尽量去除不必要的重复请求 如禁止同一页面多次重复请求相同数据的问题，通过跨页面参数传递减少访问等
合理需求，评估需求产出比，对产出比极端底下的需求合理去除

5 升级cpu若经过减少计算和减少等待后还不能满足需求，cpu利用率还高T_T 是时候拿出最后的杀手锏了，升级cpu，是选择更快的cpu还是更多的cpu了？

低延迟（快速响应），需要更快的cpu（每个查询只能使用一个cpu）
高吞吐，同时运行很多查询语句，能从多个cpu处理查询中收益

MySql 死锁问题如何解决

1 两个 or 两个以上事务
2 每个事务都已经持有锁并且申请新的锁
3 锁资源同时只能被同一个事务持有或者不兼容
4 事务之间因为持有锁和申请锁导致彼此循环等待

出现死锁，看MySql 死锁日志来排查问题

经典MySql 死锁案例：

可以看到两个事务 update 不存在的记录，先后获得间隙锁( gap 锁)，gap 锁之间是兼容的所以在update环节不会阻塞。两者都持有 gap 锁，然后去竞争插入意向锁。当存在其他会话持有 gap 锁的时候，当前会话申请不了插入意向锁，导致死锁。

事务之间对资源访问顺序的交替
一个用户A 访问表A（锁住了表A），然后又访问表B；另一个用户B 访问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。

这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源

1 合理的设计索引，区分度高的列放到组合索引前面，使业务 SQL 尽可能通过索引定位更少的行，减少锁竞争
3 避免大事务，尽量将大事务拆成多个小事务来处理，小事务发生锁冲突的几率也更小。
4 以固定的顺序访问表和行。比如两个更新数据的事务，事务 A 更新数据的顺序为 1，2;事务 B 更新数据的顺序为 2，1。这样更可能会造成死锁。
5 在并发比较高的系统中，不要显式加锁，特别是是在事务里显式加锁。如 select … for update 语句，如果是在事务里（运行了 start transaction 或设置了autocommit 等于0）,那么就会锁定所查找到的记录。
6尽量按主键/索引去查找记录，范围查找增加了锁冲突的可能性，也不要利用数据库做一些额外额度计算工作。比如有的程序会用到 “select … where … order by rand();”这样的语句，由于类似这样的语句用不到索引，因此将导致整个表的数据都被锁住。
7 优化 SQL 和表设计，减少同时占用太多资源的情况。比如说，减少连接的表，将复杂 SQL 分解为多个简单的 SQL。

减少锁粒度，减少锁时间，减少锁发生概率，避免SQL 语句太过复杂，避免修改顺序

MySql 数据存储在磁盘上是什么样子

每个 MyISAM 表都以3个文件存储在磁盘上。这些文件的名称以表名开头，以扩展名指示文件类型。

一张 InnoDB 表底层会对应2个文件在文件夹中进行数据存储。

数据库连接池到底应该设多大（中间层）

那么结论就非常简单。在一个8核的服务器上，设定连接/线程数为8能够提供最优的性能，再增加连接数就会因上下文切换的损耗导致性能下降。数据库通常把数据存储在磁盘上，磁盘又通常是由一些旋转着的金属碟片和一个装在步进马达上的读写头组成的。读/写头同一时刻只能出现在一个地方，然后它必须“寻址”到另外一个位置来执行另一次读写操作。所以就有了寻址的耗时，此外还有旋回耗时，读写头需要等待碟片上的目标数据“旋转到位”才能进行操作。使用缓存当然是能够提升性能的，但上述原理仍然成立。

在这一时间段（即"I/O等待"）内，线程是在“阻塞”着等待磁盘，此时操作系统可以将那个空闲的CPU核心用于服务其他线程。所以，由于线程总是在I/O上阻塞，我们可以让线程/连接数比CPU核心多一些，这样能够在同样的时间内完成更多的工作。

那么应该多多少呢？这要取决于磁盘。较新型的SSD不需要寻址，也没有旋转的碟片。可别想当然地认为“SSD速度更快，所以我们应该增加线程数”，恰恰相反，无需寻址和没有旋回耗时意味着更少的阻塞 ，所以更少的线程[更接近于CPU核心数]会发挥出更高的性能。只有当阻塞创造了更多的执行机会时，更多的线程数才能发挥出更好的性能

公理：你需要一个小连接池，和一个充满了等待连接的线程的队列

如果你有10000个并发用户，设置一个10000的连接池基本等于失了智。1000仍然很恐怖。即是100也太多了。你需要一个10来个连接的小连接池，然后让剩下的业务线程都在队列里等待。连接池中的连接数量应该等于你的数据库能够有效同时进行的查询任务数（通常不会高于2*CPU核心数）。

我们经常见到一些小规模的web应用，应付着大约十来个的并发用户，却使用着一个100连接数的连接池。这会对你的数据库造成极其不必要的负担。

按这个公式，你的4核i7数据库服务器的连接池大小应该为((4 * 2) + 1) = 9。取个整就算是是10吧。是不是觉得太小了？跑个性能测试试一下，我们保证它能轻松搞定3000用户以6000TPS的速率并发执行简单查询的场景。如果连接池大小超过10，你会看到响应时长开始增加，TPS开始下降。

连接池的大小最终与系统特性相关。

比如一个混合了长事务和短事务的系统，通常是任何连接池都难以进行调优的。最好的办法是创建两个连接池，一个服务于长事务，一个服务于短事务。

再例如一个系统执行一个任务队列，只允许一定数量的任务同时执行，此时并发任务数应该去适应连接池连接数，而不是反过来。

当超过这个时候， 会报主键冲突， 说明，当再次插入时，使用的自增ID还是 ，报主键冲突的错误
如果你的服务会经常性的插入和删除数据的话，还是存在用完的风险，建议采用bigint unsigned ，这个数字就大了

不过，还存在另一种情况，如果在创建表没有显示申明主键，会怎么办？

如果是这种情况，InnoDB会自动帮你创建一个不可见的、长度为6字节的row_id，而且InnoDB 维护了一个全局的 dictsys.row_id，所以未定义主键的表都共享该row_id，每次插入一条数据，都把全局row_id当成主键id，然后全局row_id加1

该全局row_id在代码实现上使用的是bigint unsigned类型，但实际上只给row_id留了6字节，这种设计就会存在一个问题：

如果全局row_id一直涨，一直涨，直到2的48幂次-1时，这个时候再+1，row_id的低48位都为0，结果在插入新一行数据时，拿到的row_id就为0，存在主键冲突的可能性。

所以，为了避免这种隐患，每个表都需要定一个主键。

为什么delete 表数据，磁盘空间却还是被占用

凡是使用过mysql，对B+树肯定是有所耳闻的，MySQL InnoDB 中采用了 B+ 树作为存储数据的结构，也就是常说的索引组织表，并且数据时按照页来存储的。因此在删除数据时，会有两种情况：

删除数据页中的某些记录

InnoDB 直接将 R4 这条记录标记为删除，称为可复用的位置。如果之后要插入 ID 在 300 到 700 间的记录时，就会复用该位置。由此可见，磁盘文件的大小并不会减少。

通用删除整页数据也将记录标记删除，数据就复用用该位置，与删除默写记录不同的是，删除整页记录，当后来插入的数据不在原来的范围时，都可以复用位置，而如果只是删除默写记录，是需要插入数据符合删除记录位置的时候才能复用。

因此，无论是数据行的删除还是数据页的删除，都是将其标记为删除的状态，用于复用，所以文件并不会减小。
delete 删除数据时，其实对应的数据行并不是真正的删除，仅仅是将其标记成可复用的状态，所以表空间不会变小。

DELETE只是将数据标识位删除，并没有整理数据文件，当插入新数据后，会再次使用这些被置为删除标识的记录空间，可以使用OPTIMIZE TABLE来回收未使用的空间，并整理数据文件的碎片。

另外，也可以执行通过ALTER TABLE重建表

根据 hash 取模定位 DB，那模数为多少？模数要为所有此 group 组 DB 中的表数，上图总表数为 10。为什么要去表的总数？而不是 DB 总数 3 呢？

如 id=12，id%10=2；那值为 2，落到哪个 DB 库呢？这是设计是前期设定好的，那怎么设定的呢？

一旦设计定位哪个 DB 后，就需要确定落到 DB 中的哪张表呢？

我们看一下，id 在【0，1000 万】范围内的，根据上面的流程设计，1000 万以内的 id 都均匀的分配到 DB_0，DB_1，DB_2 三个数据库中的 Table_0 表中，为什么可以均匀，因为我们用了 hash 的方案，对 10 进行取模。

上面我们也提了疑问，为什么对表的总数 10 取模，而不是 DB 的总数 3 进行取模？我们看一下为什么 DB_0 是 4 张表，其他两个 DB_1 是 3 张表？

在我们安排服务器时，有些服务器的性能高，存储高，就可以安排多存放些数据，有些性能低的就少放点数据。

如果我们取模是按照 DB 总数 3，进行取模，那就代表着【0，4000 万】的数据是平均分配到 3 个 DB 中的，那就不能够实现按照服务器能力适当分配了。

按照 Table 总数 10 就能够达到，看如何达到。

上图中我们对 10 进行取模，如果值为【0，1，2，3】就路由到 DB_0，【4，5，6】路由到 DB_1，【7，8，9】路由到 DB_2。

现在小伙伴们有没有理解，这样的设计就可以把多一点的数据放到 DB_0 中，其他 2 个 DB 数据量就可以少一点。

注意：小伙伴千万不要被 DB_1 或 DB_2 中 table 的范围也是 0～4000 万疑惑了，这个是范围区间，也就是id在哪些范围内，落地到哪个表而已。

上面一大段的介绍，就解决了热点的问题，以及可以按照服务器指标，设计数据量的分配。

其实上面设计思路理解了，扩容就已经出来了；那就是扩容的时候再设计一个 group02 组，定义好此 group 的数据范围就 ok 了。
因为是新增的一个 group01 组，所以就没有什么数据迁移概念，完全是新增的 group 组，而且这个 group 组照样就防止了热点。

简单点的话，就凌晨配置，重启应用服务就行了。但如果是大型公司，是不允许的，因为凌晨也有订单的。那怎么办呢？本地 JVM 缓存怎么更新呢？

其实方案也很多，可以使用用 Zookeeper，也可以使用分布式配置，这里是比较推荐使用分布式配置中心的，可以将这些数据配置到分布式配置中心去。

这边隐含了一个关键点，那就是路由 key（如：id）的值是非常关键的，要求一定是有序的，自增的，这个就涉及到分布式唯一 id 的方案。

自增的主键的值是顺序的,所以Innodb把每一条记录都存储在一条记录的后面。当达到页面的最大填充因子时候(innodb默认的最大填充因子是页大小的15/16,会留出1/16的空间留作以后的 修改)：

①下一条记录就会写入新的页中，一旦数据按照这种顺序的方式加载，主键页就会近乎于顺序的记录填满，提升了页面的最大填充率，不会有页的浪费
②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快，不会为计算新行的位置而做出额外的消耗
③减少了页分裂和碎片的产生

因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb无法做到总是把新行插入到索引的最后,而是需要为新行寻找新的合适的位置从而来分配新的空间

这个过程需要做很多额外的操作，数据的毫无顺序会导致数据分布散乱，将会导致以下的问题：

①写入的目标页很可能已经刷新到磁盘上并且从缓存上移除，或者还没有被加载到缓存中，innodb在插入之前不得不先找到并从磁盘读取目标页到内存中，这将导致大量的随机IO

②因为写入是乱序的,innodb不得不频繁的做页分裂操作,以便为新的行分配空间,页分裂导致移动大量的数据，一次插入最少需要修改三个页以上

所以如果我们设置的主键是乱序的，就有可能会导致数据页中的主键值大小不能满足索引使用的条件，此时就会产生页分裂
如果出现上图的数据页，我们可以发现后面数据页里的主键值比前一个数据页的主键值要小，里面的数据就会进行数据的挪动，也就是页分裂
通过页分裂，我们只要将主键为2的数据行与主键值为4的数据行互相挪动一下位置，就可以保证后面一个数据页的主键值比前一个数据页中的主键值大了，真正的页分裂可能比图中要复杂很多，但是都是通过这种形式来完成页分裂的

结论就是主键值最好是有序的，这样就可以不用页分裂，还能充分使用到索引，否则就必须进行页分裂来保证索引的使用

③由于频繁的页分裂，页会变得稀疏并被不规则的填充，最终会导致数据会有碎片

所以 uuid 和 雪花算法 应该会有 调优操作：
在把随机值（uuid和雪花id）载入到聚簇索引(innodb默认的索引类型)以后,有时候会需要做一次OPTIMEIZE TABLE来重建表并优化页的填充，这将又需要一定的时间消耗。

①别人一旦爬取你的数据库,就可以根据数据库的自增id获取到你的业务增长信息，很容易分析出你的经营情况

②对于高并发的负载，innodb在按主键进行插入的时候会造成明显的锁争用，主键的上界会成为争抢的热点，因为所有的插入都发生在这里，并发插入会导致间隙锁竞争

③Auto_Increment锁机制会造成自增锁的抢夺,有一定的性能损失

1 读磁盘IO瓶颈，热点数据多（水平垂直都可以），每次查询大量磁盘IO，降低查询速度 ： 分库和垂直分表
2 网络带宽不够，请求过多，网络IO瓶颈并发量上不来，一个数据库最多并发2000，最好保持每秒1000左右 ：分库
3 CPU瓶颈：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算

4单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。

offset 和Limit 有什么问题 以及代替方案是什么？

正如前面段落所说的那样，OFFSET 和 LIMIT 对于数据量少的项目来说是没有问题的。
但是，当数据库里的数据量超过服务器内存能够存储的能力，并且需要对所有数据进行分页，问题就会出现。
为了实现分页，每次收到分页请求时，数据库都需要进行低效的全表扫描。

这意味着，如果你有 1 亿个用户，OFFSET 是 5 千万，那么它需要获取所有这些记录 (包括那么多根本不需要的数据)，将它们放入内存，然后获取 LIMIT 指定的 20 条结果

也就是说，为了获取一页的数据：10万行中的第5万行到第5万零20行

需要先获取 5 万行。这么做是多么低效？

这种分页查询方式会从数据库第一条记录开始扫描，所以越往后，查询速度越慢，而且查询的数据越多，也会拖慢总查询速度。

这是一种基于指针的分页。

你要在本地保存上一次接收到的主键 (通常是一个 ID) 和 LIMIT，而不是 OFFSET 和 LIMIT，那么每一次的查询可能都与此类似。

为什么？因为通过显式告知数据库最新行，数据库就确切地知道从哪里开始搜索（基于有效的索引），而不需要考虑目标范围之外的记录。
要使用这种基于游标的分页，需要有一个惟一的序列字段 (或多个)，比如惟一的整数 ID 或时间戳，但在某些特定情况下可能无法满足这个条件。

我的建议是，不管怎样都要考虑每种解决方案的优缺点，以及需要执行哪种查询。

一般情况下，在数据库中建立表的时候，强制为每一张表添加 id 递增字段，这样方便查询。

如果像是订单库等数据量非常庞大，一般会进行分库分表。这个时候不建议使用数据库的 id 作为唯一标识，而应该使用分布式的高并发唯一 id 生成器来生成，并在数据表中使用另外的字段来存储这个唯一标识。

使用先使用范围查询****定位 id （或者索引），然后再使用索引进行定位数据，能够提高好几倍查询速度。即先 select id，然后再 select *；

这种方式已经不属于查询优化，这儿附带提一下。

对于使用 id 限定优化中的问题，需要 id 是连续递增的，但是在一些场景下，比如使用历史表的时候，或者出现过数据缺失问题时，可以考虑使用临时存储的表来记录分页的id，使用分页的id来进行 in 查询。这样能够极大的提高传统的分页查询速度，尤其是数据量上千万的时候。

关于丢数据和返回不稳定的一些说明，最稳定的是第三种，其余不同数据库会有不同表现

方法1: 直接使用数据库提供的SQL语句
适应场景: 适用于数据量较少的情况(元组百/千级)
原因/缺点: 全表扫描,速度会很慢 且 有的数据库结果集返回不稳定(如某次返回1,2,3,另外的一次返回2,1,3). Limit限制的是从结果集的M位置处取出N条输出,其余抛弃.

方法2: 建立主键或唯一索引, 利用索引(假设每页10条)
适应场景: 适用于数据量多的情况(元组数上万)
原因: 索引扫描,速度会很快. 有朋友提出: 因为数据查询出来并不是按照pk_id排序的，所以会有漏掉数据的情况，只能方法3

MySql千万数据10秒批量插入

互联网项目中MySql 应该选用什么事务隔离级别

要从主从复制讲起,基于binlog 复制的，binlog是一个记录数据库更改的文件。
为什么 项目中不适用读未提交 和串行化？
互联网的分布式方案，多采用最终一致性的事务解决方案!

RR 和RC 该怎么选取？

MySql 如果每次更新操作都需要写进磁盘，然后磁盘也要先找到对应的那条数据，然后更新，整个过程IO成本，查找成本很高，为了解决这个问题，MySql在设计的时候就用了类似饭店记账的思路来更新效率。

其实就是MySQL里常说的WAL技术，WAL的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写小黑板，等不忙的时候再写账本。

需要注意的是，先写日志的写日志，其实也是写磁盘，只是写日志是顺序磁盘，速度非常快。

具体的情况就是，当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log里面，并更新内存，这个时候更新就算完成了，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往在系统比较空闲的时候做，就像打烊了以后写账本一样。

同时，将赊账记录在小黑板上，如果赊账的不多，可以等打烊了以后再记录账本，如果赊账的特别多，小黑板写满了，这个时候掌柜就要放下手上的活，先把黑板上的部分赊账记录更新到账本上，然后将记录好的信息从小黑板上擦掉，为记录新的赊账腾出地方。

MySQL于这个也是类似的，InnoDB的redo log是固定大小的，比如我们可以分配一组4个文件，每个文件的大小都是1GB，那么总共就可以记录4GB的操作，从头开始写，写到末尾就又从开头循环写，write pos是当前记录的位置，一边写一边后移，写到3号文件末尾后就回到0号文件开头，checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据库中。
write pos和checkpoint之间的是“小黑板”上还空着的部分，可以用来记录更新的操作，如果write pos追上了checkpoint，表示“黑板“写满了，这个时候不能再执行新的更新，得停下先擦掉一些记录，把check point推进一下。

redo log是InnoDB引擎所特有的，所以我们在使用InnoDB引擎创建表时，如果数据库发生异常重启，之前提交的记录都不会丢失，InnoDB就是因为有了redo log才有了crash-safe的能力。

crash-safe简单来讲，就好比饭店掌柜的把赊账记录在小黑板上或者账本上，之后饭店突然停业了几天，重新开业后，依然可以通过小黑板和账本上的数据核算赊账账目，

MySql 整体看来有两部分
一部分是Server 层，主要做的就是MySql功能层面的事情， Server 层的日志成为binlog。
还有一部分是引擎层，负责存储相关的具体事情。redo log 是innoDB 引擎特有的日志。

2 redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是罗技日志，记录的是这个语句的原始逻辑，比如“給ID=2 这一行的 c 字段加1”

3 redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

MySql 大体上来看可以分为Server 层和存储引擎两部分
server层：包含 连接器，查询缓存，分析器，优化器执行器等，覆盖了MySql的大部分核心服务功能，以及所有的内置函数，所有的跨存储引擎的功能都在这一层实现，比如存储过程，触发器，视图等

存储引擎层：负责数据的存储和提取，其架构模式是插件式的，支持InnoDB，MyISAM，Memory等多个存储引擎。

关键字：长连接以及短连接，内存溢出，发生异常重启 ， 解决办法。
关键字：缓存如何存放，怎么过期，如何使用缓存，版本过期问题

关键字： 执行方案也就定下来了

关键字：对表进行权限校验，而连接器验证的是用户的身份。

【导语】以下是小编为大家整理的通过日志恢复MS SQL数据案例备份恢复（共10篇），仅供参考，欢迎大家阅读。

篇1：通过日志恢复MS SQL数据案例备份恢复

本文介绍通过日志恢复MS SQL数据案例，以数据库的故障恢复改为非简单模式，去掉自动关闭和自动收缩两个选项为前提，

前提条件是数据库的故障恢复改为非简单模式，去掉自动关闭和自动收缩两个选项。

2、对数据库进行备份，备份时间为 09：42

篇3：程控交换机的数据备份和恢复论文

即从交换机当前激活的公共设备机架把数据库、杂项文件或ACD统计表拷贝到其他存储介质上。其中的杂项文件包括:专用缩位拨号码,人工呼叫转移,激活的呼叫转移组等。

使用系统维护终端执行联机操作,并输入用户名、密码后,选择当前所用的数据库,并进入EDT(Configuration Editor)程序,在该程序下输入UTI(Utility)命令,此时即可使用BAC命令来备份数据了。具体的操作如下:

键入“CTRL+C”命令;开启维护终端并联机。用户名…?ADMIN,回车;输入用户名“ADMIN”。口令…?*****,回车;输入口令。ADMIN…?EDT,回车;进入数据库编辑程序。EDT…?UTI,回车;进入UTI编辑程序。UTI…?BAC,回车;进入备存程序。备存[DB]…?DB,回车;指示系统备存数据库。此时有三个选项:DB(数据库),MIS(杂项文文件)与ACD(ACD统计),本例选择了备存数据库。

备存的数据库…?A,回车;输入备存数据库名称A。…将标有(1/*)的空盘插入机架并回车…;系统提示用户放入磁盘,“*”表示此次备份操作过程总共需要的磁盘数。需要指出的是:若磁盘上存有其它内容,系统会在向磁盘拷贝文件的过程中抹去磁盘上的信息。…备存数据库A…;备存过程的提示。系统会在磁盘满时提示用户插入下一张盘,直至备存完毕。UTI…?EXI,回车;返回上一级程序。EDT…?EXI,回车;返回最高一级程序,系统会提示“您已脱机”。

(2) 备存数据的恢复:

使用RES(Restore)命令将数据库、杂项文件或ACD统计从备份的软盘拷贝到激活的公共设备机架的硬盘中。具体操作如下:

联机后进入UTI程序(进入步骤同“数据备份”)。

恢复[DB]…?DB,回车;仍以恢复DB为例。

将标有(1/*)的空盘插入机架并回车。

此后,依次放入磁盘直至恢复完毕。然后退出。

篇4：程控交换机的数据备份和恢复论文

(1) 数据备份:MD110型交换机的数据做了改动以后,不会立即写入硬盘,而是由存储单元

MEU存储。因此,在做此种型号交换机的数据备份时,应遵循以下3个步骤:

MEU数据→交换机硬盘单元QDLU→维护终端硬盘→软盘

? 下面分别加以说明:

交换机的转储操作有2种,可根据需要分别执行。这里需要指出的是:交换机的QDLU硬盘单元上有原始程序文件“LOVOL”和包含程序代码与用户数据的后援加载文件“RELVOL”。

①系统转储:交换机MEU中正在运行的所有程序单元和所有数据转存到交换机硬盘。过程如下:

-执行EQ硬盘维护程序;

-将QDLU硬盘单元中的文件指针指向relvol文件,此文件应是新的或可以删除的;

-退出EQ程序,执行FIOL联机操作程序,输入指令;

此后,系统将把新的系统文件转存入交换机的.硬盘单元中。

②数据转储:维护人员修改交换机数据以后,将修改内容转存入交换机硬盘单元。过程如下:

第二步,运行EQ转存数据。

即把转储操作中存入交换机硬盘单元的文件转存到维护终端的硬盘。首先运行EQ软件,进入交换机硬盘维护界面,并找到上一步所创立保存的文件。

-在此文件上,按下字母C,选定做为要保存的源文件。

-在维护终端目录上选定目标文件,回车,系统开始根据设定速率转存数据。

此过程把交换机上的数据导入了维护终端。

第三步,将数据存入软盘,保存。

可以运行维护终端的WINDOWS操作系统,用压缩软件将其转换为压缩文件,拷贝入软盘保存。

(2) 备存数据的恢复:

若需以备份的文件为源文件恢复交换机系统的数据,首先将软盘的文件拷贝入维护终端的硬盘(或利用维护终端上已有的备份文件)。之后运行交换机的硬盘维护程序EQ,选定维护终端上的备份文件为源文件,并且在交换机硬盘目录上选定目标文件的位置,回车,开始拷贝。拷贝完毕后,将此文件激活,作为当前文件。

此后,需将交换机中央处理单元复位,使之执行加载过程,即将硬盘单元的数据重新读入MEU存储单元,从而使系统恢复到从前(数据丢失前)的运行状态。

要想使丢失数据尽快恢复,交换网络

维护管理人员就必须有一套严格的备份方案。业务数据的完整备份和科学的恢复方案可使交换设备在出现故障后迅速恢复。合理的备份策略应该容易操作并对各种重文秘站－中国最强免费！要业务的影响降至最低,这样才能最大限度地减少电力通信交换网络系统的风险。

篇5：备份重要性 数据灾难恢复五大问题

一直以来，提起数据安全，人们想到的是网络安全，如何防止 攻击等方面，而对于数据的完整性、可用性的重视不足。所谓数据安全，就是这些在企业中简单做了数据备份，就认为数据安全得到很好的保证，企业的系统完全有保障。其实这些都是最简单的想法，数据备份并不等于数据容灾，有了备份不等于万事大吉。因为备份的数据可以还会有其他因素造成的数据损坏，如地震、火灾等，对于这些企业应该在数据容灾方面提升能力，来进一步应对数据抵抗潜在不安全因素的能力。

这样来说，会有人问何为“容灾”?其实简单的说就是尽量减少和避免灾难发生所造成的数据损失。备份和恢复是这个“容灾”中最重要的部分，提供数据的恢复和保管能力。另外，还要有提高数据可用性的能力，以及预防自然灾难所造成的对系统存储数据的影响和损失。

提到容灾，首先想到数据备份，到底数据备份和容灾是怎样的关系?对于企业来说，这种关系体现在什么方面才是最关心的。企业关键数据的丢失会很大程度上影响业务发展，同时造成严重经济损失。但是很多企业至今都没有理解容灾，认为简单的建立备份系统之后就认为高枕无忧，其实容灾系统也是不可缺少的一环，其相互关系可以说明容灾系统的重要 性。

数据备份可以说是企业数据可用性的最后一道防线，其目的为了在系统崩溃时能够快速的恢复数据。尽管这也是体现容灾的一种形式，但是能力有限。因为如今传统的备份还是采用数据内外磁带机进行冷备份，备份机制也统一在机房中管理，一旦机房陷入灾难，备份磁带上的数据也将毁坏，起不到有效保护数据安全作用。

数据备份还是最基础的形式，没有数据备份任何容灾都没有现实意义。但是光有备份是不够，真正的数据容灾就是能够弥补传统备份不足，在灾难发生时可以及时恢复整个系统。所以，容灾对于IT而言就是提供一个能够防止各种灾难的计算机信息系统。

可见，了解到容灾真正目的后，对于企业来说，如何在数据备份上避免在容灾恢复所出现的问题，就需要企业明确数据容灾的真正意义和相关手段。

对于一个企业来说，数据进行备份仅仅是整个容灾工作的开始，备份目的就是为了能在系统故障的时候进行有效恢复，

但对于很多企业来讲，特别是中小企业，数据备份只是一项简单的工作，对于容灾计划方面没有弄清楚真正的意义，根本没有把数据容灾放在首要位置，所以会导致在容灾恢复上出现问题。

企业对于容灾没有进行效果方面的评估，认为花费巨大的精力和财力在数据备份方面，最终在问题出现时候就是简单的覆盖恢复，没有真正的感受到效果方面的实际意义。甚至缺乏完全的文档化恢复计划和措施。

许多企业在弄清楚容灾意义，并不是有效的进行计划，导致很多容灾计划只是在想当然的情况下进行的编写，没有进行过任何的模拟演练，缺乏真正的可行性。最终一旦灾难发生，根本就起不到足够的容灾作用，数据根本没有办法有效恢复。

3、容灾没有可用配置文档

对于大型企业而言，在容灾备份方面有着专业的IT人才，并不缺乏相关的经验和手段。但是，对于一些企业，特别是中小企业没有对于当前系统配置和相关文件的必要存档。在进行容灾恢复时，找不到相应的原始系统配置文档，导致给灾难恢复带来不必要的困难。

许多企业的IT人员通常对于数据存放介质和配置系统文档简单的存放，如柜子中、书架上，忽略这些数据所需的存放条件和所需要的安全防范保障措施，直接导致的后果是数据文档会因潮湿变质，配置文档丢失等情况，让企业在数据方面受到损失。

对于容灾备份，许多企业仅仅对于一些需要长期保存的数据进行简单的季度备份、年度备份，特别是一些文档资料。由于时间过长，难免会出现数据文档因潮湿变质不能使用，而企业这个时候没有对这类文档进行有效的多份备用策略，致使一旦出现类似问题数据造成丢失。所以，对于这类需要长期保存的关键备份，可以采用不同地方保存至少2个以上的备份应用。

由此可知，容灾恢复工作中应注意的问题十分关键，对于有效避免问题的产生，企业才可能在未来数据安全方面得到保证，进一步用核心数据应对市场的竞争。

篇6：对硬盘重要数据进行备份和恢复

凡是用过一次”字符串，注意：也可搜索您自己所熟悉的是英文字母的子目录名字，找到后，按回车键查看，如不对，可再按回车键，继续搜索。找到后，记下所在位置的扇区数值，再将这个保存的目录表用KV3000移写扇区功能，写到硬盘原目录区内。这样，再重新引导机器就OK了。

篇7：教你巧用数据库日志恢复数据到时间点备份恢复

问题：update或delete语句忘带了where子句，或where子句精度不够，执行之后造成了严重的后果，这种情况的数据恢复只能利用事务日志的备份来进行，所以如果你的SQL没有进行相应的全库备份或不能备份日志（truncate log on checkpoint选项为1），那么就无法进行数据的恢复了，或者只能恢复到最近一次的备份的数据了，

1，如果误操作之前存在一个全库备份（或已有多个差异备份或增量备份），首先要做的事就是进进行一次日志备份（如果为了不让日志文件变大而置trunc. log on chkpt.选项为不能是1）

2，恢复一个全库备份，注意需要使用with norecovery，如果还有其他差异或增量备份，则逐个恢复

3，恢复最后一个日志备份即刚做的日志备份，指定恢复时间点到误操作之前的时刻

以上这些操作都可以在SQL SERVER企业管理器里完成，难度不大，

当然，如果误操作是一些不记日志的操作比如truncate table，select into等操作，那么是无法利用上述方法来恢复数据的。

篇8：NTFS格式大硬盘数据恢复特殊案例

公司一块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和其它格式的图形文件，逐个打开完全正常，

恢复工作顺利结束，大功告成。

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

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

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

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

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

篇9：Oracle备份与恢复案例数据库教程

一. 理解什么是数据库恢复

当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计算机系统的故障（硬件故障、软件故障、网络故障、进程故障和系统故障）影响数据库系统的操作，影响数据库中数据的正确性，甚至破坏数据库，使数据库中全部或部分数据丢失，因此当发生上述故障后，希望能重构这个完整的数据库，该处理称为数据库恢复。恢复过程大致可以分为复原(Restore)与恢复(Recover)过程。

数据库恢复可以分为以下两类：

1.1实例故障的一致性恢复

当实例意外地（如掉电、后台进程故障等）或预料地（发出SHUTDOUM ABORT语句）中止时出现实例故障，此时需要实例恢复。实例恢复将数据库恢复到故障之前的事务一致状态。如果在在线后备发现实例故障，则需介质恢复。在其它情况Oracle在下次数据库起动时（对新实例装配和打开），自动地执行实例恢复。如果需要，从装配状态变为打开状态，自动地激发实例恢复，由下列处理：

1） 为了解恢复数据文件中没有记录的数据，进行向前滚。该数据记录在在线日志，

包括对回滚段的内容恢复。

2） 回滚未提交的事务，按步1重新生成回滚段所指定的操作。

3） 释放在故障时正在处理事务所持有的资源。

4） 解决在故障时正经历一阶段提交的任何悬而未决的分布事务。

1.2介质故障或文件错误的不一致恢复

介质故障是当一个文件、一个文件的部分或磁盘不能读或不能写时出现的故障。文件错误一般指意外的错误导致文件被删除或意外事故导致文件的不一致。这种状态下的数据库都是不一致的，需要DBA手工来进行数据库的恢复，这种恢复有两种形式，决定于数据库运行的归档方式和备份方式。

（1） 完全介质恢复可恢复全部丢失的修改。一般情况下需要有数据库的备份且数据库运行在归档状态下并且有可用归档日志时才可能。对于不同类型的错误，有不同类型的完全恢复可使用，其决定于毁坏文件和数据库的可用性。

（2） 不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库，使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有不同类型的使用，决定于需要不完全介质恢复的情况，有下列类型：基于撤消、基于时间和基于修改的不完全恢复。

挥诔废(CANCEL)恢复：在某种情况，不完全介质恢复必须被控制，DBA可撤消在指定点的操作。基于撤消的恢复地在一个或多个日志组（在线的或归档的）已被介质故障所破坏，不能用于恢复过程时使用，所以介质恢复必须控制，以致在使用最近的、未损的日志组于数据文件后中止恢复操作。

挥谑奔(TIME)和基于修改(SCN)的恢复：如果DBA希望恢复到过去的某个指定点，是一种理想的不完全介质恢复，一般发生在恢复到某个特定操作之前，恢复到如意外删除某个数据表之前。

第二章. 数据库恢复案例测试环境

以下的所有案例都是通过测试经过，环境为：

2.2 数据库备份脚本

1、以上脚本在数据库关闭状态下备份数据库所有的数据文件，联机日志，控制文件（在一个目

录下），如果成功备份，所有文件是一致的;

2、没有备份参数文件，参数文件可以另外备份，没有必要每次都备份，只需要在改变设置后备份一次;

3、如果以上命令没有成功依次执行，那么备份将是无效的，如连接数据库不成功，那么肯定关闭数据库也不成功，那么备份则无效;

4、冷备份建议下人工干预下执行。

数据库OS热全备份脚本

1、热备份必须在数据库归档方式下才可以运行；

2、以上脚本可以在数据库运行状态下备份数据库所有的数据文件（除了临时数据文件），没有必要备份联机日志；

3、归档日志至少需要一次完整备份之后的所有日志；

4、如果以上命令没有成功依次执行，那么备份也是无效的，如连接数据库不成功，那么备份则无效。

RMAN备份只讲叙有恢复目录的情况，如果没有恢复目录，情形大致相似。以下是RMAN的热备份全备份的脚本：

1、 数据库必须运行在归档模式下;

2、 RMAN将自动备份数据文件，运行可靠;

3、 归档日志另外备份处理，但至少需要保存一次备份来的日志;

4、 没有必要用RMAN做冷备份，效果不好。

以上举例说明了数据库的恢复案例的测试环境与部分备份测试脚本，其它的备份脚本可以根据以上脚本演变而来或在案例中加以说明。

数据库的自动实例将不加以说明，这里只举例说明媒体错误或人为错误造成的恢复可能。

以上包括以下案例都是在WINDOWS+Oracle816上测试验证的，在不同的操作系统与不同的数据库版本中略有差别。

第三章. 了解与恢复相关的信息

1、 理解报警日志文件

报警日志文件一般记载了数据库的启动/关闭信息，归档信息，备份信息，恢复信息，常见错误信息，部分数据库修改记录等。一般令名规则为Alrt.log或Alrt.log，如我的测试数据库的报警日志文件的名称为testalrt.log。

报警日志文件的路径是根据初始化参数background_dump_dest来决定的，如在我的机器上，该参数值为 D:\\Oracle\\admin\\test\\bdump，那么，你就可以在该路径下找到该文件。

2、 后台进程跟踪文件

后台进程跟踪文件的路径与报警日志文件的路径一致，在某些情况下，你可以通过后台跟踪文件的信息了解更多的需要恢复的信息。如在数据库需要恢复的时候，报警日志文件中常有这样的语句：

通过提示的DBWR跟踪文件，可以查询到更详细的信息。

这是两个动态性能视图，可以在mount下查看，通过这两个视图，你可以了解详细的需要恢复的数据文件与需要使用到的归档日志。

第四章. 数据库恢复案例

4.1非归档模式下的备份与恢复

备份方案：采用OS冷备份

1. 连接数据库并创建测试表

6. 重新启动数据库，会发现如下错误

在报警文件中，会有更详细的信息

8. 打开数据库，检查数据

这里可以发现，数据库恢复成功，但在备份之后与崩溃之前的数据丢失了。

1、非归档模式下的恢复方案可选性很小，一般情况下只能有一种恢复方式，就是数据库的冷备

份的完全恢复，仅仅需要拷贝原来的备份就可以(restore)，不需要recover；

2、这种情况下的恢复，可以完全恢复到备份的点上，但是可能是丢失数据的，在备份之后与崩溃之前的数据将全部丢失；

3、不管毁坏了多少数据文件或是联机日志或是控制文件，都可以通过这个办法恢复，因为这个恢复过程是Restore所有的冷备份文件，而这个备份点上的所有文件是一致的，与最新的数据库没有关系，就好比把数据库又放到了一个以前的“点”上；

4、对于非归档模式下，最好的办法就是采用OS的冷备份，建议不要用RMAN来作冷备份，效果不好，因为RMAN不备份联机日志，restore不能根本解决问题；

5、如果没有备份联机日志，如RMAN的备份，就需要利用不完全恢复(until cancel)的方法来重新创建联机日志文件。

4.2归档模式下丢失或损坏一个数据文件

在归档方式下损坏或丢失一个数据文件，如果存在相应的备份与该备份以来的归档日志，恢复还是比较简单的，可以作到尽量少的Down机时间，并能作到数据库的完全恢复。

1、 连接数据库，创建测试表并插入记录

3、 继续在测试表中插入记录

4、 关闭数据库，模拟丢失数据文件

5、 启动数据库错误，脱机该数据文件：

还可以查看报警文件（见上一个恢复案例）或动态视图v$recover_file

6、 打开数据库，拷贝备份回来(restore)，恢复(recover)该数据文件，并联机:

恢复成功，联机该数据文件

7、 检查数据库的数据（完全恢复）

1、采用热备份，需要运行在归档模式下，可以实现数据库的完全恢复，也就是说，从备份后到数据库崩溃时的数据都不会丢失;

2、可以采用全备份数据库的方式备份，对于特殊情况，也可以只备份特定的数据文件，如只备份用户表空间（一般情况下对于某些写特别频繁的数据文件，可以单独加大备份频率）；

3、如果在恢复过程中，发现损坏的是多个数据文件，即可以采用一个一个数据文件的恢复方法（第5步中需要对数据文件一一脱机，第6步中需要对数据文件分别恢复），也可以采用整个数据库的恢复方法；

4、如果是系统表空间的损坏，不能采用此方法。

RMAN也可以进行联机备份，而且备份与恢复方法将比OS备份更简单可靠。

1、连接数据库，创建测试表并插入记录

2、 备份数据库表空间users

3、 继续在测试表中插入记录

4、 关闭数据库，模拟丢失数据文件

5、 启动数据库，检查错误

恢复脚本可以是恢复单个数据文件

//输出内容冗长，省略--编者

8、 检查数据是否完整

1、RMAN也可以实现单个表空间或数据文件的恢复，恢复过程可以在mount下或open方式下，如果在open方式下恢复，可以减少down机时间;

2、如果损坏的是一个数据文件，建议offline并在open方式下恢复;

3、这里可以看到，RMAN进行数据文件与表空间恢复的时候，代码都比较简单，而且能保证备份与恢复的可靠性，所以建议采用RMAN的备份与恢复.

4.3丢失多个数据文件，实现整个数据库的恢复.

OS备份归档模式下损坏（丢失）多个数据文件，进行整个数据库的恢复

1、 连接数据库，创建测试表并插入记录

2、 备份数据库，备份除临时数据文件后的所数据文件

3、 继续在测试表中插入记录

4、 关闭数据库，模拟丢失数据文件

模拟媒体毁坏（这里删除多个数据文件）

5、 启动数据库，检查错误

详细信息可以查看报警文件

有四个数据文件需要恢复

7、 打开数据库，检查数据库的数据（完全恢复）

1、只要有备份与归档存在，就可以实现数据库的完全恢复（不丢失数据）;

2、适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复;

3、恢复过程在mount下进行，如果恢复成功，再打开数据库，down机时间可能比较长一些。

RMAN备份归档模式下损坏（丢失）多个数据文件，进行整个数据库的恢复

1、连接数据库，创建测试表并插入记录

3、 继续在测试表中插入记录

4、 关闭数据库，模拟丢失数据文件

5、启动数据库，检查错误

可以知道有四个数据文件需要恢复.

6、利用RMAN进行恢复

7、 检查数据库的数据（完全恢复）

1、只要有备份与归档存在，RMAN也可以实现数据库的完全恢复（不丢失数据）;

2、同OS备份数据库恢复，适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复;

3、目标数据库在mount下进行，如果恢复成功，再打开数据库;

4、RMAN的备份与恢复命令相对比较简单并可靠，建议有条件的话，都采用RMAN进行数据库的备份，

4.4 不完全恢复案例

4.4.1 OS备份下的基于时间的恢复

不完全恢复可以分为基于时间的恢复，基于改变的恢复与基于撤消的恢复，这里已基于时间的恢复为例子来说明不完全恢复过程。

基于时间的恢复可以不完全恢复到现在时间之前的某一个时间，对于某些误操作，如删除了一个数据表，可以在备用恢复环境上恢复到表的删除时间之前，然后把该表导出到正式环境，避免一个人为的错误。

1、 连接数据库，创建测试表并插入记录:

2、 备份数据库，这里最好备份所有的数据文件，包括临时数据文件:

3、 删除测试表，假定删除前的时间为T1，在删除之前，便于测试，继续插入数据并应用到归

4、 准备恢复到时间点T1，找回删除的表，先关闭数据库:

5、 拷贝刚才备份的所有数据文件回来

7、 开始不完全恢复数据库到T1时间

8、 打开数据库，检查数据

1、不完全恢复最好备份所有的数据，冷备份亦可，因为恢复过程是从备份点往后恢复的，如果因为其中一个数据文件的时间戳(SCN)大于要恢复的时间点，那么恢复都是不可能成功的;

2、不完全恢复有三种方式，过程都一样，仅仅是recover命令有所不一样，这里用基于时间的恢复作为示例;

3、不完全恢复之后，都必须用resetlogs的方式打开数据库，建议马上再做一次全备份，因为resetlogs之后再用以前的备份恢复是很难了;

4、以上是在删除之前获得时间，但是实际应用中，很难知道删除之前的实际时间，但可以采用大致时间即可，或可以采用分析日志文件(logmnr)，取得精确的需要恢复的时间;

5、一般都是在测试机后备用机器上采用这种不完全恢复，恢复之后导出/导入被误删的表回生产系统.

4.4.2 RMAN备份下的基于改变的恢复

以上用OS备份说明了一个基于时间的恢复，现在用RMAN说明一个基于改变的恢复

1、 连接数据库，创建测试表并插入记录

//屏幕输出内容冗长，省略--编辑

3、 删除测试表，在删除之前，便于测试，继续插入数据并应用到归档，并获取删除前的scn号。

4、 准备恢复到SCN 31014，先关闭数据库，然后启动到mount下

可以看到，表依然存在。

1、 RMAN也可以实现不完全恢复，方法比OS备份恢复的方法更简单可靠；

2、 RMAN可以基于时间，基于改变与基于日志序列的不完全恢复，基于日志序列的恢复可以指定恢复到哪个日志序列，如

3、 与所有的不完全恢复一样，必须在mount下，restore所有备份数据文件，需要resetlogs；

4、 基于改变的恢复比基于时间的恢复更可靠，但是可能也更复杂，需要知道需要恢复到哪一个改变号(SCN)，在正常生产中，获取SCN的办法其实也有很多，如查询数据库字典表(V$archived_log or v$log_history)，或分析归档与联机日志(logmnr)等。

5.1 损坏联机日志的恢复方法

5.1.1 损坏非当前联机日志

大家都清楚，联机日志分为当前联机日志和非当前联机日志，非当前联机日志的损坏是比较简单的，一般通过clear命令就可以解决问题。

从这里我们知道日志组1的数据文件损坏了

从报警文件可以看到更详细的信息

可以知道，该组是非当前状态，而且已经归档。

3、 用CLEAR命令重建该日志文件

如果是该日志组还没有归档，则需要用

4、 打开数据库，重新备份数据库

1、如果损坏的是非当前的联机日志文件，一般只需要clear就可以重建该日志文件，但是如果该数据库处于归档状态但该日志还没有归档，就需要强行clear；

2、建议clear，特别是强行clear后作一次数据库的全备份；

3、此方法适用于归档与非归档数据库。

5.1.2 损坏当前联机日志

归档模式下当前日志的损坏有两种情况，

一、是数据库是正常关闭，日志文件中没有未决的事务需要实例恢复，当前日志组的损 坏就可以直接用alter database clear unarchived logfile group n来重建。

二、是日志组中有活动的事务，数据库需要媒体恢复，日志组需要用来同步，有两种补救办法:

A. 最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份

B. 通过强制性恢复，但是可能导致数据库不一致。

下面分别用来说明这两种恢复方法：

1、 打开数据库，会遇到一个类似的错误

2、 查看V$log，发现是当前日志

4、 拷贝有效的数据库的全备份，并不完全恢复数据库：

先选择auto，尽量恢复可以利用的归档日志，然后重新

这次输入cancel，完成不完全恢复，也就是说恢复两次。

1、这种办法恢复的数据库是一致的不完全恢复，会丢失当前联机日志中的事务数据;

2、这种方法适合于归档数据库并且有可用的数据库全备份;

3、恢复成功之后，记得再做一次数据库的全备份;

4、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。

5.1.2.2 如果没有备份，进行强制性恢复

1、 打开数据库，会遇到一个类似的错误

2、 查看V$log，发现是当前日志

如果出错，不再理会，发出

7、 数据库被打开后，马上执行一个full export

1、该恢复方法是没有办法之后的恢复方法，一般情况下建议不要采用，因为该方法可能导致数据库的不一致；

2、该方法也丢失数据，但是丢失的数据没有上一种方法的数据多，主要是未写入数据文件的已提交或未提交数据；

3、建议成功后严格执行以上的7到11步，完成数据库的检查与分析；

4、全部完成后做一次数据库的全备份；

5、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。

5.2 损坏控制文件的恢复方法

5.2.1 损坏单个控制文件

损坏单个控制文件是比较容易恢复的，因为一般的数据库系统，控制文件都不是一个，而且所有的控制文件都互为镜相，只要拷贝一个好的控制文件替换坏的控制文件就可以了。

1、 控制文件损坏，最典型的就是启动数据库出错，不能mount数据库

查看报警日志文件，有如下信息

3、 拷贝一个好的控制文件替换坏的控制文件或修改init.ora中的控制文件参数，取消这个坏的控制文件。

1、损失单个控制文件是比较简单的，因为数据库中所有的控制文件都是镜相的，只需要简单的

拷贝一个好的就可以了；

2、建议镜相控制文件在不同的磁盘上；

5.2.2 损坏全部控制文件

损坏多个控制文件，或者人为的删除了所有的控制文件，通过控制文件的复制已经不能解决问题，这个时候需要重新建立控制文件。

以下是详细重新创建控制文件的步骤：

2、 删除所有控制文件，模拟控制文件的丢失

3、 启动数据库，出现错误，并不能启动到mount下

查看报警日志文件，有如下信息

5、 在internal或sys下运行如下创建控制文件的脚本，注意完整列出联机日志或数据文件的路径，或修改由alter database backup control file to trace备份控制文件时产生的脚本，去掉多余的注释即可。

6、 如果没有错误，数据库将启动到open状态下。

1、重建控制文件用于恢复全部数据文件的损坏，需要注意其书写的正确性，保证包含了所有的数据文件与联机日志；

2、经常有这样一种情况，因为一个磁盘损坏，我们不能再恢复(store)数据文件到这个磁盘，因此在store到另外一个盘的时候，我们就必须重新创建控制文件，用于识别这个新的数据文件，这里也可以用这种方法用于恢复。

5.3 损坏回滚数据文件的恢复方法

回滚段表空间中的一个数据文件丢失或者损坏导致数据库无法识别它，在启动数据库的时候会出现ORA-1157, ORA-1110的错误，或者操作系统级别的错误，例如ORA-7360。在关闭数据库的时候(normal或者immediate)会出现ORA-1116, ORA-1110的错误，或者操作系统级别的错误，例如ORA-7368。

感谢Coolyl的辛勤工作，关于回滚段的大部分内容都是摘自他在itpub的文章。

5.3.1 损坏数据文件，但数据库处于Open状态

如果你发现有回滚段的数据文件丢失或者损坏了，而此时的数据库是处于打开的状态下并且在运行，就千万不要关闭数据库了，因为在大多数的情况下打开的时候比关闭的时候好解决问题一些。

一般也是存在有两种情况：

A、是offline丢失或损坏的数据文件，然后从一个备份中恢复，执行介质恢复以保持一致性。但是这种情况要求数据库是归档方式下才可以采用的。

B、是offline那个存在丢失或损坏的数据文件所在的整个回滚段表空间，然后删除整个回滚段表空间并重建，但是你必须要杀掉那些在回滚段中已经激活的用户进程才可以offline的。

通常第一种情况就比较简单实现，但是更多的用户事务将会出错并且回滚。

1、 offline丢失或损坏的数据文件

2、 从一个有效的备份中恢复。

1、 offline存在丢失或损坏的数据文件的回滚段表空间中的所有回滚段。

2、 检测当然回滚段的状态。

4、 处理那些online状态的回滚段。

如果你已经执行过offline操作的回滚段状态仍然是online，则说明这个回滚段内有活动的事务。你要接着查询

如果没有返回结果，则证明存在丢失或损坏的数据文件的回滚段表空间中的所有回滚段都已经被offline了，然后重新执行第二步，第三步。如果查询有结果返回，则状态应该是“PENDING OFFLINE”.接着查看ACTIVE_TX列，如果值为0，则表明此回滚段中已经没有未处理的事务了，很快就会被offline的，然后等它offline后重新执行2，3步后跳至第六步。如果值大于0，则继续到第五步。

5、 强制那些包含活动事务的回滚段offline。

活动的事务应该被提交或者回滚，执行下面的查询看看哪些用户占用了回滚段：

最好能直接联系到那些user让他们自己去回滚或者提交事务，如果不能做到的话，那就只能强制性的杀掉进程了。

杀掉进程后再过一段时间后回滚段会自动清除那些事务，然后就可以回到第二步继续查询了。

7、 重建回滚段并online它们。

1、数据库如果是open状态，就可以直接在open状态下解决问题，没有必要停下数据库，增加down机时间；

2、不管上上面那种恢复方法都是正常性的恢复，不会引起数据的不一致或错误。

5.3.2数据库关闭，但是数据文件中没有活动事务

这种情况下最简单的方法就是offline drop掉这个坏了的或者丢失的数据文件，然后以restricted模式打开数据库然后删除并且重建包含损坏文件的回滚段表空间。

1、 确定数据库是正常的关闭的。方法是可以去查看alert文件，到最后看是否有如下信息：

如果有的话，就证明数据库是正常关闭的，否则就不能用这个方法去恢复。

2、 修改init参数文件，移去ROLLBACK_SEGMENTS中包含的损坏数据文件的回滚段表空间的回滚段，如果你不能确定哪些回滚段是坏的，简单的方法是你可以注释掉整个ROLLBACK_SEGMENTS。

7、 删除掉那个包含损坏文件的回滚段表空间。

8、 重建回滚段表空间，记得创建后要把回滚段都online。

9、 重新使数据库对所有用户可用。

10、然后正常关闭数据库，修改init文件，如果开始只是注释掉了ROLLBACK_SEGMENTS的，就去掉注释即可，如果加了隐含参数的，注释掉它，并在ROLLBACK_SEGMENTS加入所有的回滚段。

11、正常启动数据库：

1、这种方法的前提条件是数据库是正常关闭（不是abort）可用；

2、这种方法是正常方法，不会引起数据错误。

5.3.3 数据库关闭，数据文件中有活动事务，没有可用备份。

一般造成这种原因的情况是采用了shutdown abort或其它原因异常关机（如断电）导致的。

3、删除rbs的一个数据文件

14、重建新的回滚表空间及回滚段，并联机。

1、这种办法是万不得以的时候使用的方法，如果有备份，都建议从备份上进行恢复；

2、这种方法恢复的数据库，可能会引起数据库的数据错误；

3、恢复成功以后，建议exp/imp数据，并重新分析检查数据库。

5.3.4 数据库关闭，数据文件中有活动事务，从备份恢复

1、从一个有效的备份中恢复损坏的数据文件。

如果发现要恢复的文件是offline状态的话，要先online它：

5、如果数据库是非归档情况下，执行以下查询：

如果CHANGE#大于最小的redolog文件的FIRST_CHANGE#，则数据文件可以被恢复，记得在应用日志的时候要把所有redolog文件全部应用一遍。

如果CHANGE#小于最小的redolog文件的FIRST_CHANGE#，则数据文件就不可以被恢复了，这时候你要从一个有效的全备份中去恢复数据库了，如果没有全备份的话，那你就只能把数据库强制打开到一个不一致的状态去exp出数据，然后重新建库导入数据，因为这种方式的恢复Oracle是不推荐用户自己做的，所以这里我就不详细说明了。

1、这种方法要求在归档有备份的方式下进行，而且是建议方式；

2、这种方法不会导致数据库的错误。

5.4 损坏临时数据文件的恢复方法

临时数据文件的恢复是比较简单的，因为临时文件中不涉及到其它的有用的数据，所以可以删除后重建。

2、删除临时数据文件，模拟媒体失败；

3、启动数据库，检测到文件错误；

7、重新创建该表空间，并重新分配给用户。

1、临时数据文件是非重要文件，不保存永久数据，可以随时删除重建，不影响数据库的数据安全；

2、如果重新建立以后，别忘了重新分配给用户。

第六章. 常见恢复误区

1、可以不需要备份，只有归档就能进行数据库的向前的恢复

答：这个在Oracle 9i以前起码是不可能的，在别的数据库我也没有听说过，不完全恢复的主要思路是利用不完全点之前的备份，加上归档日志，恢复到不完全恢复点，9i中出现了一个flashback的特性，这个特性的使用，也是有很多局限的。

2、进行不完全恢复只需要拷贝一个需要恢复的备份数据文件

答：不完全恢复需要拷贝所有的数据文件，最好包括临时数据文件在内，否则需要另外的处理，如果有一个数据文件的SCN大于不完全恢复点，那么这个恢复都将是失败的。

3、使用RMAN目录与目标数据库在同一数据库能很好进行数据库的恢复

答：使用恢复目录与目标数据库在同一个数据库中，将存在很大的恢复局限，如该数据库的系统数据文件的损害，数据库根本不能open，那么RMAN也就无法连接恢复目录，也就不存在恢复了。

这里我们反复演示了多种情况下的恢复方案，通过这些演示，我们应该掌握了如下内容：

1、利用OS与RMAN进行各种常规备份与恢复。

2、熟悉没有备份或简单的非常规备份与恢复的方法。

篇10：通过免费数据恢复误删文件网络技巧

数据恢复最好的方法是做好数据备份工作，这些数据恢复软件都无法百分百完全能把你的数据恢复回来，而且一般数据恢复软件对一些文件格式恢复得并不理想，偶使用过的数据恢复软件中就图片格式的文件能恢复得比较理想，所以平时最好养成把重要文件数据备份的习惯。小建以前推荐过几款相当牛B的数据恢复软件：FinalData，O&O FormatRecovery，BadCopy Pro 等等，不过它们大多都不是免费的，今天在akaka中发现了一篇推荐利用免费的数据恢复软件恢复误删数据的文章，当中推荐了不少软件也相当不错。

当我们误删硬盘上文件的时候，第一时间应该怎么做？

当您没有通过回收站不小心删除一个重要文件，其实您的档案仍然存在于硬盘驱动器的某处，只需要使用合适的工具，很简单的点击您的鼠标，就可以寻找和恢复已删除的档案。

首先：停止电脑上的一切操作

因为当你删除了一个文件，系统只是在这个文件上做上一个记号，表示存储这个文件的空间可以从新写入别的文件，您的计算机现在会随时写入新的资料，如果继续操作电脑，很可能会在这个文件的空间写入其他文件，这样恢复起来就很困难了。

接着：使用适当数据恢复软件

（当然，你可能有自己所喜欢的软件）

跨平台恢复软件：免费、跨平台的命令行工具PhotoRec是一个开发用来找回不小心删除的照片的工具，但它几乎可以从您的可移动媒体或硬盘驱动器找回任何其他格式的文件。

再次：开始恢复误删文件

当你选择了恢复工具后，首先要做的是使用恢复工具扫描您的硬盘驱动器，当扫描完成后，一般您将会看到一个混乱的档案大名单，您所要做的只是寻找文件类型和名称和你删除的文件相匹配的，并选择恢复后的存储位置。

如果通过以上的步骤，你还没有能找到你删除的文件，你可能需要尝试使用不同的恢复软件来试试有没有效果，因为不同的软件有着不同的运算规则。

如何恢复其他存储介质上的数据？

1、恢复闪存卡上数据：如果您需要从您数码相机损坏的闪存卡里恢复的照片，你可以将闪存卡通过读卡器连接到电脑上，再使用恢复工具，这里建议你使用Zero Assumption Digital Image Recovery，它着重于图像文件复原。

2、恢复损伤的CD或DVD恢复数据：这种的恢复文件过程可能略有不同。使用免费的CD Recovery Toolbox，它可以从损坏的光盘中恢复尽可能多的数据，如果它没有效果，你还能使用有30天试用期的CDCheck。当然小建早几天推荐的BadCopy Pro也相当不错。

网盘也好，U盘也罢，反正现在许多网盘都是免费的，例如微软老大的：SkyDrive 就相当不错，而购买一个移动硬盘也并不贵！