灾后反思之SQL错误操作

 前言
      昨天用户根据业务需求，需要在数据库端调整一些具有特征的数据，我首先写好了条件的语句（select  uninstand from table1 where col='gg'）,然后更新另外一张表 update table2 set col='string'  ,忘记在更新语句加 where uninstand in 。灾难后果就在轻轻点击一下运行后屁颠屁颠的到来，table2那一列20w条数据变成一样。顿时我疯掉，立刻停掉程序，禁止用户使用，发布系统维护公告。为了找回以前数据，备份当前数据，然后恢复以前的数据总是不成功，一直弄到深夜两点才搞定。不过也有一些关于错误操作和海量数据备份的思考。

 恢复过程
     1.Log Explorer ：他可以根据日志系统记录，进行反操作，单前提必须系统备份模式是full。而且盗版的不能访问自定义库。
     2.backup exec ：赛门铁克的一个产品，用来备份数据的，公司的dba都是用这个软件备份数据库，特点是速度快。但是昨天用它却无法恢复数据库，老是会提示用户名和账号错误，要么就是其它一些错误。而且这个软件有个特点，对备份的系统环境要求很严，也就是说备份和恢复的系统要一样。
     3.bak文件：也是以前的数据的备份文件，比较老，所以到最后一直没有采用，大概有50g左右，恢复起来要2个多小时。
     4.数据分析：由于系统是我设计的，所以数据结构我比较清楚，在做这个系统的时候，由于偷懒，对这一列数据做了冗余，而这些冗余都分散在各个表中，我通过一个一个对照，最后找回了tabel2这一列的数据，不过这个是侥幸的。

 思考
     1.我们都开发人员，后期的时候，几乎都要调整数据，而这样就有肯能用到update 和 delete  这样的语句。sql 的查询分析器，能不能整加对这样语句的智能分析，当用户一运行这样的语句的时候就跳槽对话框，提示是否要执行改语句，并列出要影响的数据条数，确认就继续执行。
     2.sql查询分析器能不能增加，预操作或者回滚这样的操作，当用户操作错误的时候可以进行恢复或提示。
     3.对于海量的数据库的备份问题，我的数据库已经到了50g以上，对于海量数据如何处理，是否可以考虑磁带机或使用拷盘和集群的方式。以及备份和恢复的效率如何解决
  
 尾声
   希望有微软的人可以，向你们的开发部门反映这样的问题，这个对于他们应该很容易解决。
   夜已深，茶已凉。