菜鸟运维的悲剧

菜鸟运维的悲剧-一次数据库恢复与迁移##

我们公司与另一家大公司合作为客户开发了一个服务端平台，其中服务端的开发完全由这家大公司完成，客户端是在他们原有的产品的基础了，我们做了一些符合客户要求的调整。项目完成了，我们负责运维，但是我们对服务端的业务层面了解，技术和实现知之甚少。作为一个小公司，是不可能各个方面的人员都有的，比如开发、测试、DBA。我是开发人员，我也负责运维这个项目，平时有什么问题我负责处理或者反馈给合作公司。

最近呢平台投入使用，数据库服务器却挂了，事情是这样的：

1. 系统破解过期，重新破解系统挂掉

   当然了，再次作为一个小公司，我们的服务器操作系统也是盗版的。偶然有一天我发现有个oracle数据库服务器操作系统的破解失效了，整个桌面背景都是黑的。其实这样也并没有影响服务端平台 功能，但是有点强迫症的我，还是又重新用注册机注册了一下。

   重启，睡觉。然而这个服务器再也启动不起来啦，为什么，我也不知道。

2. 从远古备份恢复数据库

   挂掉就挂掉呗，系统很重装好了，但是心里不踏实的是这是个数据库服务器，需要恢复数据库。然而，我们貌似平常没有做过数据库的备份，因为平台刚投入使用，功能问题就一大堆。当然了，幸运的是有一个很早的备份，八个小时完成恢复。这个时候第一次浏览了一下这个oracle数据库，我也是傻眼了：

   1. 数据库文件大小是8G;
   2. 打开tables节点，花了我两分钟时间；
   3. 表名各种乱码，统计表的数量将近4万个；
   4. 乱码表，查询也查不了，删除也删不了；
   5. 任何一个操作，都够NBA打满两个24秒。
   6. 跟合作公司沟通，我需要在这个环境下配置一些表的分区。

   这能忍，忍不了。

3. 迁移有效数据库架构到新数据库

   跟合作公司一沟通，坚定了我迁移数据库的想法。在茫茫4万个表中，有效的表结构不到50个。于是重建表空间，迁移有效表结构。

   各位注意，没有文档，其实这里迁移的表结构有漏掉的，关键还漏掉一些包、触发器、序列。

4. 删除恢复数据库，重命名迁移数据库，避免程序又不必要调整

   迁移完了，跟合作公司提供了迁移数据库的表空间用户名和密码。合作公司说，你们可不可以使用原来的表空间名称、用户名、密码，这样程序就不用做任何调整。想想说得挺有道理，这很简单嘛，删掉原来的数据，重命名迁移的数据库就OK了。

   各位可能猜到了，8G的4万张表的乱码的数据库删除也不是一件容易的事，费了九牛二虎之力，把恢复的数据库搞得访问不了了，也没能删除。

5. 放弃删除，使用迁移数据库

   恢复的数据库删除不了，只能使用迁移数据库了，合作公司调整了程序的相关配置。

   前面埋下的问题冒泡了，迁移数据库没有文档，迁移不完整，程序跑不起来

6. 恢复数据库状态错误，迁移数据库缺少部分数据库结构

   这下完了，恢复的数据库被我搞得删除不了，访问不了；迁移数据库缺少部分表和包。怎么办？

   1. 数据库再恢复一遍，迁移出缺少的表和包；
   2. 重写开发oracle的包。

   一个是耗费时间，一个耗费时间不一定能完成，选择自然是前者

7. 再次恢复数据库，迁移出必须对象

   是的，我借着晚上的时间，电脑工作了一夜的时间，删除了状态错误的恢复数据库。再花半天时间，再次恢复那个远古备份。

   再次恢复那个数据库，这是个痛苦的经历。

8. 恢复相关程序功能，保留恢复数据库，测试并不断迁移必须对象

   接下来的工作就是平台跑起来，报什么错，治什么病，蚂蚁搬家一点一点的把有效的数据库结构，搬到迁移数据库。

   我再也不会删掉那个笨重讨厌的恢复的数据库了，里面垃圾与宝藏并存。

   目前我已经走到这里了，迁移数据库基本完善，下面是我期待的结果。

9. 程序功能OK，保留恢复数据库，备份迁移数据库

10. 计划：定期备份迁移数据库

痛苦经历写出来，满眼都是泪。

这是一个糟糕的过程，我甚至觉得你看到都不会觉得有任何价值，我也觉得这样的项目简直就是在折磨人。但是痛苦中还是吸取了一些教训的：

1. 文档啊，数据库设计文档，必须有，而且必须和项目保持同步更新，垃圾表等必须尽早清除出去；
2. 数据库备份，必须做数据库备份，定时备份；
3. 数据库操作一定要谨慎，不要说删就删。

当然，这些就是教训，还希望各位博客园的运维大神们指导一些运维经验。真的是心累呀，这次数据库恢复和迁移。