今天在思考一个问题。如果在平时的工作中遇到一些不规范的操作，比如drop、truncate、delete，恢复起来还是非常困难的。如果Oracle中的drop操作开启回收站基本就安全了。删除操作可以借助闪回删除进行操作。可能有一些更细微的操作如update、insert等引起问题。当需要进行数据恢复时，此时可以使用闪回查询来辅助。如果你做一个截断，那么它没有任何问题。实际上，truncate操作完成后，一般来说，数据还在数据文件中。这时，您可以尝试借助第三方数据恢复工具进行恢复。这时候数据恢复不是毫秒级的。水平，公差分分钟甚至几小时都没有关系。但是在Oracle中，如果你之前开启了闪回数据库功能，那么truncate的数据是可以找回来的。不过话说回来，整个系统都被重启给停了，影响可能更大。如果不使用闪回数据库，直接通过dataguard或其他标准恢复到数据删除前进行时间点恢复也是一种方式。所以Oracle中的数据恢复方式很多，使用场景也可以根据需要选择。MySQL中的数据恢复选项相对较少。但是有一个亮点就是MySQL中的redologs是可读的，mysqlbinlog可以很容易的解析出里面的内容。而truncate、drop以及一些DML错误操作的场景对于MySQL来说难度更大。一旦出现问题，只能借助最新的备份来进行数据恢复，这就需要有相应的备份，然后在最新备份的基础上，通过解析相关的binlog，直到出现故障时间点的数据数据更改被恢复。一般来说，这个过程还是需要不少时间的。首先是判断备份和binlog的时间点，可以在其他测试环境完成，时间应该比较长。想到了下面的方案，将oracle和mysql结合起来，充分利用了oracle强大的闪回功能。也许这个解决方案对于许多数据恢复有很多亮点。还没有在本地测试过，因为还需要一些额外的定制和数据类型映射，所以只是一个粗略的想法。首先，保持MySQL原有架构，一主二备。因为主库中的binlog是数据同步的关键，所以可以考虑设置一个sql分析的路径，使用binlog进行sql分析，然后做适当的改动。这个过程可以是一个异步过程，然后结合Oracle部署到Oracle中的schema。MySQL中的数据量比较小，可以考虑在一个Oracle中用多个schema映射多个MySQL数据库。数据类型可以适当映射，比如MySQL中的bigint、smallint等直接映射到Oracle中的number。varchar和varchar2映射等等。数据到位后，可以考虑使用各种闪回特性来恢复数据。truncate等操作可以使用flashbackdatabase恢复，drop操作可以通过回收站、flashbackdatabase或基于时间点恢复。delete可以通过flashbackdelete、flashbackquery等方式恢复，update可以通过flashbackquery等方式恢复。拿到相应的技术局后，可以直接导出csv文件或insert语句。在MySQL中，通过mysqlimport或insert完成数据部署。这个过程可以让MySQL端继续前进。例如，一支军队正在行军，突然一名军官发现他没有带地图，中途摔倒了。这时可以派一名士兵骑马去取地图。.这个时候，甲骨文就是能够完成这项艰巨任务的士兵，部队依然会继续前进，不会受到其他任何影响。原文链接：http://www.linuxidc.com/Linux/2015-05/117337.htm?utm_source=tuicool
