菜鸟运维的悲剧-一次数据库恢复与迁移##
我们公司与另一家大公司合作为客户开发了一个服务端平台，其中服务端的开发完全由这家大公司完成，客户端是在他们原有的产品的基础了，我们做了一些符合客户要求的调整。项目完成了，我们负责运维，但是我们对服务端的业务层面了解，技术和实现知之甚少。作为一个小公司，是不可能各个方面的人员都有的，比如开发、测试、DBA。我是开发人员，我也负责运维这个项目，平时有什么问题我负责处理或者反馈给合作公司。
最近呢平台投入使用，数据库服务器却挂了，事情是这样的：
-
系统破解过期，重新破解系统挂掉
当然了，再次作为一个小公司，我们的服务器操作系统也是盗版的。偶然有一天我发现有个oracle数据库服务器操作系统的破解失效了，整个桌面背景都是黑的。其实这样也并没有影响服务端平台 功能，但是有点强迫症的我，还是又重新用注册机注册了一下。
重启，睡觉。然而这个服务器再也启动不起来啦，为什么，我也不知道。
-
从远古备份恢复数据库
挂掉就挂掉呗，系统很重装好了，但是心里不踏实的是这是个数据库服务器，需要恢复数据库。然而，我们貌似平常没有做过数据库的备份，因为平台刚投入使用，功能问题就一大堆。当然了，幸运的是有一个很早的备份，八个小时完成恢复。这个时候第一次浏览了一下这个oracle数据库，我也是傻眼了：
- 数据库文件大小是8G;
- 打开tables节点，花了我两分钟时间；
- 表名各种乱码，统计表的数量将近4万个；
- 乱码表，查询也查不了，删除也删不了；
- 任何一个操作，都够NBA打满两个24秒。
- 跟合作公司沟通，我需要在这个环境下配置一些表的分区。
这能忍，忍不了。
-
迁移有效数据库架构到新数据库
跟合作公司一沟通，坚定了我迁移数据库的想法。在茫茫4万个表中，有效的表结构不到50个。于是重建表空间，迁移有效表结构。
各位注意，没有文档，其实这里迁移的表结构有漏掉的，关键还漏掉一些包、触发器、序列。
-
删除恢复数据库，重命名迁移数据库，避免程序又不必要调整
迁移完了，跟合作公司提供了迁移数据库的表空间用户名和密码。合作公司说，你们可不可以使用原来的表空间名称、用户名、密码，这样程序就不用做任何调整。想想说得挺有道理，这很简单嘛，删掉原来的数据，重命名迁移的数据库就OK了。
各位可能猜到了，8G的4万张表的乱码的数据库删除也不是一件容易的事，费了九牛二虎之力，把恢复的数据库搞得访问不了了，也没能删除。
-
放弃删除，使用迁移数据库
恢复的数据库删除不了，只能使用迁移数据库了，合作公司调整了程序的相关配置。
前面埋下的问题冒泡了，迁移数据库没有文档，迁移不完整，程序跑不起来
-
恢复数据库状态错误，迁移数据库缺少部分数据库结构
这下完了，恢复的数据库被我搞得删除不了，访问不了；迁移数据库缺少部分表和包。怎么办？
- 数据库再恢复一遍，迁移出缺少的表和包；
- 重写开发oracle的包。
一个是耗费时间，一个耗费时间不一定能完成，选择自然是前者
-
再次恢复数据库，迁移出必须对象
是的，我借着晚上的时间，电脑工作了一夜的时间，删除了状态错误的恢复数据库。再花半天时间，再次恢复那个远古备份。
再次恢复那个数据库，这是个痛苦的经历。
-
恢复相关程序功能，保留恢复数据库，测试并不断迁移必须对象
接下来的工作就是平台跑起来，报什么错，治什么病，蚂蚁搬家一点一点的把有效的数据库结构，搬到迁移数据库。
我再也不会删掉那个笨重讨厌的恢复的数据库了，里面垃圾与宝藏并存。
目前我已经走到这里了，迁移数据库基本完善，下面是我期待的结果。
-
程序功能OK，保留恢复数据库，备份迁移数据库
-
计划：定期备份迁移数据库
痛苦经历写出来，满眼都是泪。
这是一个糟糕的过程，我甚至觉得你看到都不会觉得有任何价值，我也觉得这样的项目简直就是在折磨人。但是痛苦中还是吸取了一些教训的：
- 文档啊，数据库设计文档，必须有，而且必须和项目保持同步更新，垃圾表等必须尽早清除出去；
- 数据库备份，必须做数据库备份，定时备份；
- 数据库操作一定要谨慎，不要说删就删。
当然，这些就是教训，还希望各位博客园的运维大神们指导一些运维经验。真的是心累呀，这次数据库恢复和迁移。