工作以来经历的数据灾难

1.在2001年暑假的时候，在和朋友一起做一个医院的mis，找了个录入员在辛辛苦苦的录入基础数据，自己的一次不经意的执行sql

   （数据库中所有对象的删除脚本，然后重新创建脚本），造成了录入工作成果的丢失，深刻记忆的一次。

 

   没有数据库备份，数据完全丢失。

 

2.2007年在一次生产环境中，由于程序校验条件的不足，异常数据的产生，导致了业务数据被莫名的删除。

   oracle，数据库一周前有一个完全的备份，最近一周的数据只能根据数据库的归档日志，进行处理。惊魂33小时。

 

3.2009年在客户现场，对数据库进行重建，创建了新的数据库，sql server2000，右键选择查询分析器执行脚本的时候，选择错误

   选择当前生产的数据库中，执行前在和其他人谈话，没有检查，造成数据的丢失。

 

   slq server2000 ，备份机制是每晚1：00 进行数据库完全备份，丢失了半天的业务数据，惭愧呀，几乎是第一次经历的重演。

 

4.项目中的经历，IBM的DS4700,两块磁盘竟然同时发生故障，就请厂家进行处理，换了新的硬盘，数据不能完全恢复，造成重新做raid5

 

   重新根据备份文件创建数据库，造成16个小时的数据丢失，几乎24小时的业务停止。惊魂24小时。

 

 

以上发生的几次故障，1和3，是操作不当引起，2是由于程序问题造成数据丢失，4是由于硬件故障造成数据灾难。

 

分析：

       1.在人为对数据库进行处理前，一定要做数据库的备份，在发生数据灾难的时候，还有挽回的余地。做好严密的计划，没执行一步操作，最好有相关的人员在旁边进行监督，多一个人多一份力量，一定要是非常了解的人，免得弄个闲人，仅仅是个监工。

 

       2.程序问题或者硬件故障，对数据造成丢失，这就是数据库的运行模式，一般的开发环境或者测试环境，没有运行在归档模式下，

生产环境已经要运行在归档模式下，补充备份任务完成后，丢失的实时的数据。一般都会有离线备份机制，但是备份计划一定要不能间隔太长的时间，最好是每天一次，或者一天2次，不能一周一次的。这样通过归档日志恢复的数据任务就比较小一些。

 

      3。大家可以查考一下。