从删库跑路未成功到补数据的经验总结

各位读者大家好，从文章的标题来看，从事软件开发的童鞋应该能意识到事件的严重。
这件事情也在作为当事人的我来说，也算是终生难忘的经历。为以后避免再次踩坑，大
概描述一下这件事以及针对这件事情算是做经验总结。
本着记叙文六要素的原则，开始阐述这个事件的始末。在2021年的某个周五，本人和同事
一起去xxx银行的运维中心，进行xxx系统的升级工作。该次工作涉及的内容是单机的架构升
级成集群架构，并且需要进行针对缓存、数据库数据的迁移工作。预计上午的工作中进行新
环境的准备工作，把应用集群、ES集群、数据集群的基本配置等设置完毕。然后下午可以很
清闲的工作，晚上直接上线新环境即可。真实的情况却是上午按照安排基本完成，下午补充
数据库的相关配置，在进行数据库配置的时候却发生了意外，由于打开的窗口太多，并没有
留意到地址栏的地址，直接drop tablespace XXX。当反应过来的时候，已经晚了。当时的
冷汗立刻从头上流下来了，大脑里第一反应是立刻寻找备库进行还原，然而却只是找到了2019
年11月的一个数据库的dmp文件。我去咨询培训的老师、网上资料都表示没有备份是没有办法
恢复了。当即决定只是恢复2019年的dmp文件，由于很紧张也造成了恢复失败的情况。虽然最后
恢复成功了，却造成了2020年以及2021年上半年的数据丢失。最终无奈只能向自己的领导告知
这件事，领导也是很是真震惊。当天立刻采取了很多补救措施，比如重新跑批进行一部分业务功
能的恢复，然后下午重新给业务人员打电话确认业务人员各项信息，重新设置系统各项参数。最终
在当天的凌晨12点左右，基本还原功能的80%，但是历史的数据确实没有办法恢复。之后寄希望
于业务人员不能发现数据的丢失，然而确实事以愿违。最终被发现，公司领导来到现场道歉。
重新索取以往的数据，进行所有数据的重新再执行。这样就开始了时达3周的补数操作，真的是
天作孽犹可恕，自作孽不可活。这三周的补充数据的艰难程度不亚于重新构建一个小型的系统。
具体流程如下：
1、索取业务数据，走各种业务流程，并且还需要接收别人的冷嘲热讽。
2、搭建实际的环境进
3、编写流程代码，将原有功能进行重新整理，并且将流程简化。这个流程并没有想象中的那么简单，
在补录数据的过程当中体现的淋漓尽致。
4、开始跑批补录数据，这个过程真的是痛苦的很。在跑批的过程中，遇到很多坑坑哇哇的事情，比如
跑批数据的不归整、跑批过程很慢（很急的任务）等等很多很多问题。特别特别痛苦，也很压抑。
5、最终完成
虽然补充数据完毕，但是这个事情确实是很痛苦且艰难。
此次之间的经验总结如下：
1、软件在完成上线之后，给客户方运维人员编写每日数据备份以及定时清理历史备份脚本
2、进行任何删除操作之前，一定要进行备份工作，不要相信自己的操作不会出错
3、建议新旧环境的数据库名称、表空间、用户名称，在没有软件环境要求的情况下，最好不要使用一致的名称，
这样不会在操作界面多的情况下进行清理或删除的时候，将不想删除的环境进行错误的删除操作。