数据库迁移是DBA经常面临的工作。在过去的20年里，我们也做了大量的数据库迁移工作。早期，作为DBA，我总是从数据库的角度来考虑迁移计划。随着项目的增多，知识面不断扩大，增加了很多系统级的迁移方案，让迁移工作变得更加简单。如果做了大量的迁移工作，难免会遇到鬼。在过去的20年和数百个移民项目中，你们确实遇到过很多陷阱，有时甚至会面临命悬一线的绝境。后期在面临迁移方案的选择时，如果是非常重要的核心系统，一定要选择最稳妥的方案，以备不时之需。昨天微信群里有人问数据库想迁移存储有没有什么好的解决方案。脑子里冒出的迁移方案都是系统级的迁移方案，群里的DBA小伙伴们也常说数据库级的迁移。技术。事实上，没有最好的技术和解决方案，只有最合适的。选择哪种数据库迁移方案取决于具体的系统环境和迁移实施团队的技术能力。1.存储复制存储复制是我最近比较喜欢的数据库跨存储迁移方式，可以用于很多迁移需求。尤其是在一个环境中有多个数据库/多个数据库的场景下，使用存储复制一次性处理所有数据库是非常方便的。存储复制的主要实现工作由存储厂商完成，对于DBA来说是最简单的。出了问题，也没必要让DBA去追究。肯定是存储厂商的问题。DBA要做的就是打开数据库，使用rmanvalidate检查数据文件中是否存在物理/逻辑坏块。十年前，某金融客户的核心数据库数据库从9iHA升级到10gRAC，存储从IBM8000系列迁移到HDS高端存储。这个解决方案被采纳了。利用HDS自带的异构存储虚拟化能力，先将数据从IBM8000系列存储复制到HDS，在切换的最后一晚停止生产数据库，最后一次增量复制后，挂掉10gRAC环境下的数据上newvolume，然后UPGRADEthedatabase，一个多小时就完成了整个数据库的迁移和升级工作。许多DBA将卷复制和存储复制视为一回事。对于DBA来说，存储和卷没什么区别，反正看到的就是一堆裸设备。其实两者还是有区别的。卷复制利用卷管理软件的数据同步功能，如VERITASLVM。卷管理软件本身就支持异构平台，因此使用卷复制技术同步数据具有更广泛的适用性，而存储复制技术需要存储本身的支持（但是大部分高端存储都支持异构存储的存储虚拟化，所以大部分情况下是可以支持的，如果你环境中的存储不支持异构复制，你可以也可以考虑租用一个虚拟化头，它支持你需要复制实现的存储，费用从几千到几万不等，具体取决于你租用的设备和租用的时间）。大约十年前，运营商将一个数据库从惠普小机迁移到IBM小机，存储也从惠普存储换成了EMC存储。当时他们原来的系统用的是VCS，所以数据迁移是用VERITASvolumereplication做的。.在IBM这边转换数据库的时候（因为HP-UX和AIX都是big-endian，可以做DATABASECONVERT而不用XTTS），遇到了Oracle10G的bug。UNDO表空间CONVERT失败，无法打开数据库。当时也是一身冷汗，最后通过强制OFFLINE相关的UNDOSEGMENT，重新创建UNDO表空间切换等方式解决了这个问题，但是迁移完成的时候已经接近8点了上午，超过了申请关闭窗口，几乎影响了第二个营业厅的营业。因此，再简单的迁移计划也不能保证不出意外。2.逻辑复制逻辑复制是宕机窗口比较紧的情况下常用的数据库迁移方案。2000年代，在帮助运营商将计费/会计两大核心系统从Oracle8i迁移到Oracle10g时，为了缩短宕机窗口，使用Ogg进行逻辑复制。当时的OGG比较垃圾，在功能和性能上都存在一定的问题，bug也很多。切换当晚，发现好几个表都跟不上了，最后决定直接通过dblinkCTAS重构进行迁移。幸运的是，数据库迁移和数据验证工作在规定的时间窗口内完成。使用OGG进行迁移时，数据校验的工作量非常大。如果是非常核心的系统，对数据的一致性和完整性要求很高，所以一定要留出足够的时间进行数据校验。逻辑导出和导入一直被认为是最安全的迁移方式，但是世界上没有绝对安全的迁移方案。大约6/7年前，某银行核心系统从HDS存储迁移到华为18K时，想顺便把数据库从10g升级到11g。因为核心应用也需要升级，所以申请了36小时的业务关停Window，其中核心系统完全停止业务18小时，在这18小时内，给了8小时的数据库迁移时间。经过综合考虑，他们决定采用最安全的方式导出和导入数据库逻辑。先导出旧存储上的数据，然后将整个卷挂载到新服务器上，再导入。按理说是够安全的。没想到主机工程师在挂载这个盘的时候没有注意挂载为只读。DBA没有检查就开始导入。几个小时后，报磁盘数据无法写入，impdp异常退出。此时8小时的时间窗口已经使用了5个多小时。如果再导入，时间肯定不够了。我当时刚好在现场，通过检查发现impdp在输出日志的时候无法写入磁盘，导致报错。一开始写日志的时候是写在buffer里面，并没有刷盘，所以没有报错，就等刷盘了。是时候报错了。通过验证数据表和索引，发现所有的索引都已经创建。所以报错的时候可能主要的数据导入过程已经完成了。最后经过讨论，决定暂时不回滚整个工作，继续进行后续工作。但是因为这个小插曲，原计划的所有表和索引重新统计（经过SPA分析发现11g对统计数据的依赖比较大，所以建议做一个finaltableanalysis）没有进行.核心系统启动顺利完成，主要功能测试也顺利完成，大家松了口气。然而，前台很快传来了更坏的消息。应用开发者在测试性能时认为，主要核心事务的延迟慢了数十毫秒，平均核心事务延迟从升级前的80毫秒增加到120多毫秒，因此拒绝启动新系统。大家折腾了这么久还得回去，这对IT部门来说是一个非常严重的打击。因此，CIO希望我们能尽快发现并解决问题。通过分析存储的性能，数据库的整体性能没有发现任何问题。时间已经接近8小时窗口期，按理说现在必须回滚。我当时跟CIO说，能不能再给我20分钟，我再分析一遍，如果找不到原因，我就回去了。当时CIO说，我给你40分钟，不行的话我得去找总裁道歉。终于，经过将近半小时的时间，终于定位到部分核心交易延迟增加的主要原因。几个表的统计太旧了。更新统计后，核心事务延迟恢复到90毫秒左右，低于开发供应商的要求，不高于120毫秒的要求。从这个案例来看，最简单可靠的迁移方案并不完美。3.向ASM磁盘组添加/删除磁盘向ASM磁盘组添加新的存储磁盘，然后逐渐删除旧的存储磁盘。利用ASM的REBALANCE功能实现存储迁移也是一个很好的解决方案，但是REBALANCE时间比较长（如果数据量大，业务负载大），DBA需要注意整个随时处理。如果系统负载高，IO吞吐量大，这期间可能会导致一些IO性能问题。在严重的情况下，应用系统的整体性能可能会严重下降。一旦出现这些问题，我们只能暂时降低REBALANCE的优先级来缓解问题，并不能彻底解决问题。因此，对于特殊核心系统使用该方法还是要引起高度重视的。我把这个方法教给一家银行后，他们很喜欢这个迁移方法，并用这个方法迁移了大量的系统。总体来说还是比较顺利的。但是，他们还是不敢动用核心交易系统。数据库迁移的方法有很多，结合今天的时间我就不一一举例了。但是，无论采用哪种方法，实施者都不能掉以轻心，对每一个环节都要做好最周密的准备。但是，我绝对可以提醒大家，如果跳出DBA的思维方式，也许你会找到更好的方法。
