到今天已经是2个通宵了，就在昨晚9点半左右一次勿操作，导致6个同事弄了个通宵才基本恢复了数据。教训深刻啊！
3天前接到公司通知，说公司的一个系统出现当机，前方人员发现是数据库存在一些问题，要我马上去现场，由于没有机票，过了2天，在周日到的现场。通过观察并不是由于我们的数据库的原因导致的问题，是别人的数据库引起的，但数据库的安装还是存在很的问题，跟客户协商决定重新做了一套Oracle系统。生产环境是10.2.0.1.0版本的，Linux x86_32bit，而且数据字典被破坏，无法导入导出，就连有时候访问某些数据字典都会报递归错误，重建数据字典也失败。当晚新的系统、DBMS都安装完毕，实例也创建成功。就只等数据的迁移了。但是通过exp expdp都无法正常导出。想通过第三方工具抽取，但数据较慢，当晚并没有完成数据的迁移。
第二天晚上继续通宵，当所有的表结构都过去了，用第三方工具抽取了部分数据，发现太慢，于是考虑使用dblink来完成抽取数据。就在这时生成了批量的truncate语句，拷贝到pl/sql的命令窗口执行的时候，发现报约束错误，但我之前是禁用了全部约束的啊。我当时还在想难道我重新导了次表结构？查了下数据字典确实约束都是启用的。我查了下数据字典还发现有大量的recyclebin对象，我还跑去清空这些recyclebin。过了大概1分钟，我才反应过来我连错库了，连的是生产环境，当时我的心啊 我知道这次完蛋了。给项目经理一说，访问网页就开始报错。真的完蛋了。数据字典被破坏无法备份，最新的备份都是上个月20多号的。而且没归档，执行的是truncate。oh我的天，我犯了个多么大的错误啊！客户马上就知道，也通知了公司领导。现在最重要的就是想办法恢复数据。好在由于约束部分表没有被truncate掉。我简直绝望了，以前从没有研究过truncate的恢复，我认为是不能很好的恢复，即使能恢复也是很复杂的。后来同事帮我找了下，odu能够恢复truncate，于是开始研究它，果然能全部恢复数据，但是中文都变成了乱码。另一路同事正在将上个月20多号的备份数据恢复到另一个环境。到了第二天早上快上班的时候，数据还是丢了一大截，似乎是没办法了，就在这个时候同事的一句话，让我想起了我头天做操作的时候将数据库做了一次冷备份。枉然大悟，于是将冷备份恢复，居然没有问题，同事马上将数据系统切换至该库，就只丢了一天的数据，我们根据文档进行了手工的补录。在下午3点的时候终于将数据基本恢复。
通过这次教训，认识深刻啊，勿操作要弄死人啊 啊 啊 啊
以后做啥都得仔细，特别在操作生产环境时，做啥都要先备份，有人监督，不要那么轻易执行delete truncate drop语句。
切忌切忌，自己一定要养成好的习惯啊！！！！
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/23135684/viewspace-673945/ ，如需转载，请注明出处，否则将追究法律责任。
