用 第 三 方 工 具 恢 复 数 据 库

用 第 三 方 工 具 恢 复 数 据 库

第三方工具：Log Explorer for SQL Server v 4.0.2             http://js.fixdown.com/soft/8324.htm

注册机产生的是注册码，是两个         用解压缩密码解开后，压缩包里也有一个注册机的

打开log explorer file=>attach log file->选择服务器和登陆方式->connect->

选择数据库->attach->左面对话框中browse->view log->就可以看到log记录了

点击“View DDL Commands”里面就有很多drop table 命令

点击下面的“undo”按钮是生成表结构的语句（create table ....）

点击下面的“Salvage”按钮是生成插入语句的（insert into ...values....）

（以上lynx1111提供）

想恢复的话: 右键log记录 undo transation->选择保存文件名和路径->然后打开该文件到查询分析器里执行       ——T-sql代码就可以了

例如 如果log是delete table where ...的话,生成的文件代码就是insert table ....

使用经验总结帖:

http://community.csdn.net/Expert/topic/2954/2954818.xml?temp=.9148676

 

 

log explorer使用的几个问题

 

 

1)对数据库做了完全 差异 和日志备份

备份时选用了删除事务日志中不活动的条目

再用Log explorer打试图看日志时

提示No log recorders found that match the filter，would you like to view unfiltered data

选择yes 就看不到刚才的记录了

 

 

如果不选用了删除事务日志中不活动的条目

再用Log explorer打试图看日志时，就能看到原来的日志

 

 

2)修改了其中一个表中的部分数据，此时用Log explorer看日志，可以作日志恢复

 

 

3)然后恢复备份，(注意:恢复是断开log explorer与数据库的连接，或连接到其他数据上，

否则会出现数据库正在使用无法恢复)

恢复完后，再打开log explorer 提示No log recorders found that match the filter，would you like to view unfiltered data

选择yes 就看不到刚才在2中修改的日志记录，所以无法做恢复.

 

 

3)

不要用SQL的备份功能备份,搞不好你的日志就破坏了.

 

 

正确的备份方法是:

停止SQL服务,复制数据文件及日志文件进行文件备份.

 

 

然后启动SQL服务,用log explorer恢复数据

 

 

4)

如果你的数据库的日志恢复模型是simple,那就不可能用log explorer恢复

 

 

5)

Log explorer必须安装在要恢复数据库的sql server服务器上,或者在sql server服务器上安装服务端,在操作的电脑上安装客户端进行数据恢复

 

 

 

 

[故障起因：]

在使用数据导入导工具将本地表往服务器传输时，忘记点掉“选择全部对象”，因此将远程的140张表超过1000万条数据全部覆盖（操作员当时点完提交就去吃饭，因此中途没有取消），数据库没有备份。

 

 

[恢复过程：]

用第三方工具：log explorer

安装后打开log explorer file=>attach log file->选择服务器和登陆方式->connect->

选择数据库->attach->左面对话框中browse->view log->就可以看到log记录，

点击“View DDL Commands”里面就有很多drop table 命令

点击下面的“undo”按钮是生成表结构的语句（create table ....）

点击下面的“Salvage”按钮是生成插入语句的（insert into ...values....）

 

 

我是按照上述方法的“Salvage”来生成被删除表的Insert语句，实际上用这个方法生成的SQL脚本已经包含了CreateTable。该过程速度大概用了8个小时，当时觉得慢，后来相比恢复过程，这个速度简直快的不行。最大的表脚本生成后超过 1G。

 

 

生成所有的SQL脚本后，防止万一，我将数据库停下，并把Date文件夹的Log和.MDF文件拷出来（怕破坏LOG文件，没有使用数据库的备份方式备份），文件大小总共为 5.7G

 

 

此后开始进行正式的恢复工作。新建一个数据库，先试着用SQL查询分析器运行了一个小表的脚本，完全没有问题。但后来发现导入比较大的SQL脚本文件，查询分析器就报错了。请教了realgz得知logExplorer本身对大脚本有良好支持，因此改用LogExplorer--》Run SQL Script 功能来运行脚本。果然大文件也可以恢复了。

 

 

但开始运行后发现包含有ntext字段的表恢复起来异常缓慢，打开一个包含nText字段的表的恢复脚本发现里面使用writeText来写入数据。恢复一个30万数据的表居然用了将近12小时的时间，而数据库中又有大量这样的表，为了加快数据，我又在几个机器上装了LogExplorer加入恢复过程，终于经过3天的时间，全部的表都搞的差不多了，不过恢复过程有少量的错误。

 

 

接下来我将几个机器的表导到同一个数据库中，不过此时恢复的表是没有包含索引、标识等扩展属性的，因此需要重新建立索引、标识、默认值以及触发器。在建立主键的时候发现居然有数据重复。。。没办法只好删除重复数据。

 

 

使用 select distinct * into t_New from t_Old 可以删除重复数据，但遇到有ntext字段的表是不能用这个方法的，最后只好用 Delete From t_Table Where ID IN (Select ID From t_Table a where (Select Count(*) From t_Table a where a.ID = ID ) > 1 )直接删除了有重复数据的记录

 

 

经过72小时的努力，99.9%的数据恢复。并于 4月8日晚上恢复运行网站。

 

 

这时候部分用户反映无法登陆，一查发现是有小部分数据丢失，也就是LogExplorer里报错误的那些数据……没办法，我重新用UEdit打开SQL脚本，查找这些数据，发现还在，仔细一看发现，这些数据里都有部分内容里使用大量的回车，LogExplorer无法识别，因此才出的错误。

 

 

呵呵，顾客是上帝，没办法，只好将用户表重新在本地恢复一次，遇到错误就记录下ID，然后再考出SQL脚本到查询分析器运行（查询分析器可以运行）

 

 

现在建立了维护计划，每个星期做一次完整备份。另外操作数据库的流程也变的规范，防止此类事故出现

 

 

［一些收获：]

1、慎重使用Text/nText字段

2、LogExplorer的脚本执行工具对付大文件很不错，但执行过程会对多个回车产生误判断