自打去年从领导那儿接了“凿墙”的活，潭主就跟某些厂商划清了界限。
除了调研金融行业“去IOE”现状，也加强了对头部险企的了解，当然，也完成了几个PPT。
上个月，期盼已久的“启动会”终于召开，虽说是一次非典型的Kickoff，但与会双方达成共识。
这半年也算没白忙活，潭主作为“联络人”正式开启凿墙之旅。
杀鸡焉用牛刀
有时候我们把事情想的太复杂，其实真到实战时是怎么简单怎么来。
好像这次，“凿墙”打头阵的两个业务系统数据量不大，就单个应用系统而言，其数据库完全不需要分布式，一个单机版的达梦足矣（以下简称DM），这时哪轮得到OceanBase这种重量级选手出场。
但从更高的维度看，如果将多个系统整合起来就有了经济学上的规模效应，显然也配得上分布式，同样降本增效。
分布式虽然初始成本高，但后续增量的边际成本很低，再考虑到系统高可用和业务连续性等更为复杂的场景，潭主还是认为分布式固然难度大，但综合优势也很明显。
不过现实是用户更愿意选择传统的“烟囱式”解决方案，一主两从，架构简单。
曾经的V记U2VL
U2VL（Unix to Virtual Linux），这是传统行业用户第一次去IOE浪潮时VMware的招牌。
潭主当年受了VMware的蛊惑，借数据中心迁移的大好时机，通过U2VL成建制的干掉了一批IBM小型机。
如今，IBM小型机上只剩下屈指可数的核心和关键业务系统后台数据库，迁移进入深水区。
在VMware的加持下，当年去IBM小型机，降本增效，用户价值高，做U2VL算是水到渠成。
但要说去Oracle，潭主相关的实战经验确实少了些。
不过，随着云原生技术浪潮的涌动，目前我司又开启了一轮“新基建”，这次的目标是“残余”的旧势力。
去O的两阶段提交
在重要业务系统上，用户还是相当谨慎。
为了“凿墙”，潭主之前把相当一部分精力都放在了分布式数据库上。可惜，在实战时发现暂时都派不上用场。
如果一个U2VL就能搞定的事，干嘛非要搞出个分布式来小题大做。
受降本增效影响，同时叠加金融信创，目前用户采取了先去IBM小型机，再去O记数据库的两阶段工作目标。
第一阶段：U2VL，之前在VMware时代已经干过很多次了，并不复杂，主要是测试工作量。
因为只更换服务器硬件和操作系统，除了平台兼容性外，最主要的风险就是性能风险。
第二阶段：O2DM，Oracle迁移DM才是关键问题所在。
这个阶段倒是可以把之前为分布式改造准备的流程拿出来进行验证，积累经验。
工欲善其事，必先利其器
潭主在这次迁移任务中的角色更像是顾问，所以做项目的出发点和思考角度与以往不同。
以前是大刀阔斧的干，属于行动派，现在却成了思想派。
对于数据库系统，每次硬件变更或软件升级过程涉及最多的词就是“性能”，升级迁移前后如何保证性能的稳定性，甚至稳中有升，是工作重点。
但常规测试无法模拟实际工作负载，所以主要问题就成了如何在目标系统上模拟真实的工作负载，这也是运维和测试人员的工作痛点。
评价一个产品的好坏，除了技术之外，很重要的就是产品配套工具的便捷性。
以前讲熟能生巧，凭经验，现在讲标准化、自动化和人工智能。系统迁移工作也一样，最后慢慢变成了自动化测试。
再细节一些，其实就是Oracle的两个Package：DBMS_WORKLOAD_CAPTURE和DBMS_WORKLOAD_REPLAY。
有了工作负载还不够，系统环境的变更可能会导致SQL语句的执行计划发生变化，从而影响SQL的整体性能。
如果说数据库Replay是对迁移前后工作负载的容量评估，那么SQL性能分析（SQL Performance Analyzer，SPA）就是对整体业务性能评估。
同样的套路，在业务周期捕获生产端需要分析的SQL，并将其存储在SQL调优集（SQL Tunning Set）中，只不过Package变成了DBMS_SQLTUNE和DBMS_SQLPA。
翻了翻相关资料，技术思路让潭主不禁想起自己多年的数据复制工作经历，也算轻车熟路。
唯一的困惑是为啥不把上述内容整合在一起，一次性给Oracle做个全身的“SPA”，毕竟殊途同归，最后都落脚到AWR（Automatic Workload Repository）上。
反正重要的系统升级都有专业人员参与，作为“联络人”能操盘即可，具体技术细节还是留给DBA吧。
询问了DM工程师，对方也有类似O记SPA的工具，叫DMSQLCOPY。
下一阶段，潭主就会面临如何把O记的负载在DM上重现的技术问题，理论上会用到上述工具，到时候再分享。
虽说这次U2VL的两套系统并不复杂，但潭主还是在过程中找到了一些“新鲜感”。
我和达梦有个约会
前不久，网上看到了达梦要在A股上市的新闻。
其实，在没有信创东风之前，达梦一直是以国产数据库厂商的身份创业，那时DM在数据库领域的表现可以用不温不火来形容。
可现如今遇到了信创风口，达梦火了，火到潭主都不得不躬身入局。
不过，火爆的背后也有一些不和谐的声音，多次听圈内朋友抱怨DM跟Oracle比怎么不行。
由俭入奢易，由奢入俭难，这大概就是当下信创用户的心声。
潭主没有实际运维过达梦，缺少发言权，不过从之前的学习和使用感受上，差别不大。
反正达梦的目标很清晰，就是蚕食O记的市场，在产品使用上也充分考虑了用户的使用习惯和迁移成本。
但从长期看，这种模仿的“后发优势”如何持续下去才是国产化替代核心问题，只有真正转型为“创新模式”才能获得竞争优势和生存空间。
至于用户反映的产品问题，潭主觉得很正常，虽说DM出道多年，但其实产品在用户端并没有大规模应用，肯定需要时间磨合。
关于性能和稳定性，Oracle毕竟在全球积累了几十年，而国内数据库产品在这方面应该说才刚刚起步。
抱怨可以有，但应该对信创多一些包容，所以政策的连续性也很重要！
选择大于努力
以潭主之前在分布式数据库的测试经验看，其他厂商未必比达梦好多少，既然都是小白鼠，选个自己熟悉的，兼容性高的也没什么不好。
你觉得Oceanbase、TDSQL和GaussDB好，但是否想过你那仨瓜俩枣的投入够不够人家塞牙缝。
开弓没有回头箭，希望这一轮的去IOE可以走得顺利些，远一些。
时间是最好的答案，拭目以待！
董事长常说，“大事要敢想，小事要一点一点做。”
潭主说，“支持信创，我是认真的！”
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
