Task Scheduler(计划任务)是windows自带的功能,定时执行相应的程序,非常简洁好用.
在创建任务时有两个选项"Run only when user is logged on"(默认选项) 和 "Run whether user is logged on or not"
前者为默认选项,如果在创建时没有注意,就会选中该选项,那么在该用户没有登录的情况下,该任务到时间了也不会被执行.
一般程序员都会在创建任务后定个时间测试一下, 检查任务有没有在准确时间执行,那么这个时候是没有问题的,该用户仍然为登录状态,任务会被触发.
但当该用户登出,服务器重启等情况下,因为默认选中了"Run only when user is logged on",该任务就不会再被触发了.
笔者就是因为这个原因吃了个惨痛的教训, 我用Task Scheduler给数据库定期执行备份,创建了两个任务,每天一个差异备份,每周一个全备份(该任务忘记勾选"Run whether user is logged on or not").
因为在创建任务时已经测试过没有问题,后来就没有再检查,那么当什么时候才会意识到备份出问题了呢?没错,就是在数据库产生问题无法恢复去找备份文件的时候.
周五在导出数据时不小心点了"导出"按钮旁边的"清除记录"按钮(该设计容易引起误操作,已经修改),确认对话框也弹出来了,但其内容跟导出对话框的内容很相似,看也没看就点了"OK",于是悲剧开始了...
我在第一时间发现自己点错键后马上就上服务器找数据库备份文件,然后发现了数据库备份的异常,只有一堆差异备份文件,当时还不知道具体原因,也没有时间找,救火要紧.
于是在网上搜第三方数据库恢复软件,最有名的Log Expolorer却不支持SQL Server 2008, 在dudu的文章"实战 SQL Server 2008 数据库误删除数据的恢复"中知道Recovery for SQL Server支持SQL Server2008,于是下了个Demo版试用,发现确实恢复了几条记录,误删的有半个月一万多条记录,Demo版有限制, 大部分字符被恢复成"Demo"字样,网上没有该软件的破解版,当时考虑过购买该软件,但因为该软件一个方面价格较高,另一个方面是需要联系该软件的销售人员,没有在线通过网银直接购买Lincense的服务,而周末销售也不上班而放弃. 不过还好当时没有购买,因为买了也没用,因为我的数据库已经有备份机制,所以"Recovery Model"选择的是"Simple",什么第三方软件也无法恢复.
于是没有办法,到处找人求助,找老大,找各种牛人,都没有办法.后来突然想起产品经理前两天报告一个bug时说他导出了本月的明细记录报表,于是像抓到了救命稻草一样迅速联系该产品经理,他是德国人,住在澳大利亚,本来还以为老外周末不会看邮件,没想到几个小时后就收到了他的回复,并把该报表的的Excel文件发了过来.
下面的过程就比较简单了,我把Excel文件中的数据先导入到数据库的一个临时表,然后用批量update把其中的Description改为ID,最后再插入到主记录表.其中涉及到一些数据类型转换的操作,经过跟原来的几张汇总报表进行比对,数据完全一致.
最后将损失减小到两天,即为该产品经理导出报表后到我误删除期间的数据全部丢失了,这比之前丢失半个月的数据要好很多,已经报告给产品经理和Manager,反而是他们安慰了我半天,尤其这个产品经理说他之前也这么干过一次,误点击了"Clear record"按钮,当时数据没有找回来,所以才提出了数据备份的需求...
然后我就对该按钮进行了简单的改进,颜色改为红色,确认对话框会弹出两次,两次都点击"OK"后才会执行删除.
真是一次惨痛的教训,工作四年多第一次犯这么大的错,当时发现无法恢复数据时真是想死的心都有了,写下这篇博客,谨以铭记.
刚刚才发现距离上篇文章已经有一年多的时间了,下篇写一下这一年多来的总结.
