经常看到有人误删数据，或者误操作，特别是Update和Delete的时候没有加WHERE ... 然后就喊爹喊娘了，怕是亲爹妈也无奈摇肩。

  话说，如果没有犯过错误，那你还算是搞程序的吗？！没了偶尔的心跳，注定一辈子的孤独啊，哈哈哈.... 

        OK，书归正传，要分享一下我的当时的处理方案，与诸君共勉，欢迎吐槽，多多沟通。 

        遇到这种情况，一般都是没有做备份，或者备份不及时（比如，当时我公司的数据，就没有做实时备份，不过还好的是我25号数据误操作，组长也然在19号做了备份，万幸万幸哦！），不然也不会来发问了。首先要淡定，否则会有更大的麻烦。

       不过，不用担心，现在就告诉你，三行sql脚本，数据恢复到指定的时间。客官，请上眼..

        首先，你要确定的是你数据恢复模式是哪一种。具体方法：选择操作的数据库，“属性”——》“选项”——》“恢复模式”，是否选择的是“完整”。

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

  backup database Demo to disk='D:\db.bak'

确保数据库的恢复模式最起码不能为【简单】。至于如何修改成完整模式，这个应该没必要多说了。

或者使用脚本检查：

select recovery_model,recovery_model_desc  

from sys.databases  

where name ='AdventureWorks'  

 

 

然后，要确保别人不再链接数据库 ，然后做一次日志尾部备份

 

看下这段剁手都来不及的脚本吧 ...

UPDATE Person SET Gender='女'

操作前：               >>       操作后：   

 

如果，这是张客户表，呃，，，

当然，我相信你是无心之举，无论如何，淡定，淡定，相信我，这个时候，老板是不会炒了你的，但是，你抓鸡也是要赶紧找回丢失的数据。 

 

ONLY三行脚本， SQL数据恢复到指定时间点 

 --1、 首先，备份事务日志（还原日志必须在 还原完全备份的基础上进行。而使用事务日志才能还原到指定的时间点）

   BACKUP  LOG Demo TO disk='D:\\db_log.bak' WITH FORMAT

</div>

 

  --2、接下来,我们要先还原完全备份(还原日志必须在还原完全备份的基础上进行)   

  RESTORE DATABASE Db FROM DISK='c:\db.bak' WITH REPLACE,NORECOVERY   

 

 

 3、将事务日志还原到删除操作前（这里的时间对应上面的删除时间，并比删除时间略早    

RESTORE LOG Db FROM DISK='c:\db_log.bak' WITH RECOVERY,STOPAT=''     --获取比表被删除的时间略早的时间   

 

 

 

如果发现备份不了可以用下面语句查看，并把spid杀掉：

 SELECT  * FROM sys.sysprocesses WHERE dbid=DB_ID('Demo')  

 

 

 --查询一下,看表是否恢复   

SELECT * FROM Demo.Person   

</div>

 

ps，  操作这些脚本的时候 ，建议是在master 数据库下进行，很好， 解决数据恢复喽

 

 

After All：

 平时不做备份，出了问题就抓鸡，这也是你们咎由自取！如果你的公司是这样，建议你赶紧离去，一个对数据不重视的公司，你留着有何意义。

但是，任谁也避免不了工作中的一些失误，关键是咱们解决问题的能力。但作为久经沙场的战友们，此时，不是要你想到多少种方案解决，你的朋友圈有多少酒友可以求助，有多路大神求支援 ... 

你只需做两件事：1、30秒认真想想你前后都做了哪些操作；

                       2、15秒内向你的直属领导如实汇报。

 

这种方法有几个缺点（此处杜撰被人，也然找不到作者何人）：

1、如果你发现误操作以后还有很多人做了操作，那么你还原成功后，别人的操作就会冲掉，所以发生误操作后，要马上停止别人对数据库的操作。

2、这个方法要对数据库独占，所以你想偷偷恢复是不行的了。勇敢承认错误吧。

对于核心数据表，还是要先做好预防操作。

来自：http://www.cnblogs.com/fuguoliang/p/4642004.html