犹记得那是2003年，我刚毕业不到一年，当时我们公司使用的oracle数据库还是oracle 7，我还是个学程序的，公司没有专职DBA，往往数据库部署还有软件开发都是一个人。我到一个县电力局去实施我们开发的MIS系统，这套系统前段时间我同事来实施过，但当时他被急着调到其它项目叫我过来接手对用户进行一下培训，如果他们有什么小需求就直接在现场改了。
这时我已经有了好几个月的工作经历，对oracle安装，建表空间，建用户导入导出数据已经非常熟练了。同事当时走得很急，很多基础数据还是其它单位的，还有很多其它单位的测试数据，我很熟练的调试好了我们的电力MIS系统，清理了一些垃圾数据并更新了一些基础数据。可是MIS系统才跑了几天就出问题了，MIS系统能顺利登录，好像是报数据库的一个什么错，具体情况忘记了，反正当时我知道重装oracle肯定能解决问题。
于是有了重装oracle的想法，肯定比定位问题和解决问题来得快，反正每天我都做了数据库备份的，这事我在其它项目上都干过了，只要有备份啥都不怕，反正系统还没正式用，都是些测试数据。这样悲剧也就此发生了，我熟练的把oracle卸载掉，我还知道光卸载还不行，还得清注册表，这可是我在上一个项目中不断实践得到的宝贵经验。我熟练的把oracle整个目录干掉(又是上一个项目自己总结的经验，这样卸载得才彻底)，又熟练的重装oracle，再熟练的把备份数据导进系统，我们的MIS系统终于运行正常了，弄完这些我也就出去吃饭回宾馆休息了。
晚上用户就打电话来问我有没有动什么东西，现在数据库连不上，叫我马上过去看看。我到现场后用pl/sql连接我们的数据库，发现一切正常呀，运行MIS系统也正常。用户告诉我不是我们的数据库，是另一个公司的业务数据库，大概就是抄的县里的一些电表数据和收费的一个业务数据库。“啊?你们这还有其它数据库?”，我心里一凉，用户问我是不是做了什么操作，我也就老实的告诉了他们，我重装了oracle。这时用户脸色都变了，具体情况现在也记不清了，只记得用户叫我马上解决问题。
当时想着他们的数据库应当也是每天要做备份的，如果每天做了备份，只丢了几个小时的数据的话叫补录一下应当问题也不大。马上到服务器上找数据库备份，可是没结果，问用户他们的数据有没有每天做备份，用户也说不知道，赶紧打电话问了他们的开发商，得到的结果是从来没做过备份，我的个心啊彻底凉了。这可是全县几年的电表抄表数据和计费数据，弄没了营业厅的工作人员估计要直接放假了，会不会要罚我钱，会不会叫我坐牢啊，于是一整晚都在那边查资料看有没有恢复的可能。
但是没有备份，更绝的是我把oracle目录全干掉了，还是shift+del(自从我在网上看了shift+del删除文件可以彻底删除文件而不进入回收站后我便养成了 shift+del删除文件的习惯)。硬是一通宵没睡，心里那个急啊。 第二天一大早那套计费系统的软件开发商出现了，他们也没法，一个劲的说我胆子也太大了，只见他们一通电话打来打去。后来我只好求助我来过这的同事，问他还有没有什么办法补救，他对oracle还比较了解。结果戏剧性的情况又发生了，同事告诉我他前些天来的时候正是冲击波病毒发作的厉害的时候，他怕出问题就把我们的数据库用户和那家软件公司的数据库用户一起备份了一下，放在某某地方。
备份都是用 exp命令导出的 dmp文件，于是马上把这好消息告诉了他们的软件开发商，他们把数据恢复了一下，检查没发现什么问题，只是丢了近几天的数据，只能是叫电力局的工作人员补录这几天的数据了。终于一切都恢复正常了，用户负责人居然也没敢把这事报告给他们领导，也没到我公司进行投诉，所以这事我公司一直都不知道。现在想来，我估计也是用户负责人看到都解决了，也不想把事搞大，到底追究责任起来他也没好处，而那家软件开发商呢，更不想把事搞大，到底系统运行几年了，从来没做过数据库备份，这追究起来他们也没好结果。
就这样事情过去了，就当什么也没发生过一样。过程是惊险的，但结局也算美满，不然后果不敢想象啊。 可爱的冲击波病毒救了我一命啊，从那以后只要碰到数据库相关的操作我就格外小心，第一反应就是先做好各种备份是否正常，是否有效备份，有没有其它业务在数据库中，做什么重要的改动前都尽量先进行模拟。当然我当时只是个软件开发人员，在2009年的时候我终于转型当了DBA，在我转DBA之前，领导评价说我很细心，具备DBA的素质，这么多年项目做了很多，我事事都比较小心，没出过什么致命的误操作，跟这一事件也是有很大关系的，这个经历也算是一笔财富吧。
