聊聊SQL Server迁移最怕的几件事看看KES V9R4C019是怎么解决的最近这阵子我一直在帮几个客户弄数据库替换的事情。从SQL Server往国产库上挪。其实这活儿干过的人都知道表结构和数据倒好说真正的麻烦在后面。很多同事跟我吐槽说一听到SQL Server迁移就头大。那么到底怕什么呢今天咱们就掰开揉碎了聊一聊。刚好最近看到了金仓出的KES V9R4C019版本针对这些麻烦做了一些处理。我也结合自己的实战经验给大家盘一盘这里面的事。先放一张图把整个迁移过程中大家最担心的几个点和对应的大致解决思路串一下。大家有个整体概念。SQL Server 迁移痛点痛点1: T-SQL大量改写痛点2: 数据类型不匹配痛点3: 特有语法报错痛点4: 停机时间太长KES V9R4C019: 深度语法解析与转换KES V9R4C019: 底层类型自动映射KES V9R4C019: S模式高兼容度KES V9R4C019: 全量增量同步工具一、SQL Server 迁移到底怕什么很多时候做迁移评估的同事拿个工具扫一下表发现几千张表都能对上就觉得这活儿轻松了。这是一个误区。表结构能对上往往仅仅只是最表层的东西。真正让人难受的是藏在代码里的那些东西。1.1 最怕的就是那堆T-SQL的存储过程和函数你打开SQL Server的数据库看一眼。很多老系统尤其是企业层级里的系统业务逻辑全写在数据库里。存储过程动辄几千行。函数也是一个接一个。这些代码里面全是T-SQL的特有语法。你要把它改成目标库的语法往往仅仅只是改几个关键字吗根本不是的。逻辑全乱了。比如SQL Server里处理字符串的函数和标准SQL或者别的数据库差别很大。还有那种用游标写的复杂循环逻辑。你要把这些全用人肉去改工作量非常大。而且很容易改错一个符号导致业务跑不通。这种情况是最让人崩溃的。1.2 数据类型对不上号的情况SQL Server的数据类型体系是比较特别的。比如它的datetime到了别的库里可能就得分开存或者精度对不上。再比如nvarchar它在底层是双字节存储的。你迁过去之后如果目标库的字符集处理不一样查出来的数据可能就是乱码。或者长度计算方式变了原来能存下的字符串存不下了。这就会导致应用层直接报错。排查这种问题其实很耗时间。因为你不会第一时间想到是类型映射的问题。1.3 开发人员写代码留下的那些特有习惯这个情况太常见了。开发人员写SQL的时候习惯了SQL Server的那种写法。比如查前几条数据SQL Server是用TOP N。比如查询的时候不想锁表习惯加一个WITH(NOLOCK)。再比如判空的函数ISNULL。你把库换了这些语法在新的库里可能直接就不识别了。那怎么办你要去改应用代码吗应用代码可能堆积了十几年了。改一处可能牵连出好几个bug。这种牵一发而动全身的事情往往是最不敢碰的。1.4 业务停机时间窗口不够用数据量大的话你怎么搬用工具做全量导出再导入太慢了。有时候几个T的数据导一遍就要好几天。但是业务那边往往只给你几个小时的停机窗口。也就是说你必须在极短的时间内把数据同步完然后把应用切过去。如果同步过程中出了错回滚都来不及。这是一个很大的风险点。二、KES V9R4C019 是怎么接招的上面说的这些怕的事情其实也是整个行业做SQL Server迁移普遍遇到的坎。金仓在这个KES V9R4C019版本里针对这些情况给了一些解法。我仔细看了一下其实思路还是很直接的。2.1 先说说这个版本的模式选择KES这个数据库大家都知道它是基于PostgreSQL内核做的。但是它有一个很特别的地方就是有兼容模式。你要接SQL Server的活在初始化数据库的时候就得选对模式。你得选S模式。也就是SQL Server兼容模式。选了这个模式之后数据库底层的很多行为就会发生变化。它会去模拟SQL Server的一些特征。比如默认的字符串处理方式比如一些参数的默认值。这是后面所有兼容工作的基础。如果你选错了模式选成了PG模式或者Oracle模式那后面全白搭。2.2 T-SQL兼容到底做到啥程度了回到1.1说的存储过程的问题。KES V9R4C019在这个版本里对T-SQL的语法解析做了增强。它不是简单地做个关键字替换。它是在底层建了一套语法解析的树。你把那段几千行的T-SQL代码扔过去它能试着去理解你的逻辑。比如那些复杂的流程控制语句IF...ELSEWHILE循环还有TRY...CATCH异常处理。在S模式下这些语法往往可以直接跑起来。不需要你再去改成PG标准的RAISE EXCEPTION之类的写法。这对减少改写工作量来说其实帮助很大。你可以先把代码拿过来跑报错的地方再去针对性修改。而不是从头到尾重写一遍。2.3 数据类型的自动处理机制针对1.2说的类型问题。KES在S模式下内置了一套类型映射规则。当你用迁移工具把表结构导过来的时候它会自动做转换。比如SQL Server里的datetime它会自动映射成KES里的timestamp without time zone。再比如bit类型它会映射成boolean。nvarchar也会根据长度和字符集做相应的处理。你不需要手动去建表对类型。工具帮你搞定了大部分的情况。当然一些极端特殊的自定义类型可能还是需要人工看一眼。但是常规的这些类型基本都能平稳落地的。2.4 针对那些特有语法的兼容处理开发人员代码里的那些TOP N、NOLOCK、ISNULLKES V9R4C019是怎么处理的呢它是在引擎层做了一个拦截和转换。当你发过来一条SELECT TOP 10 * FROM table引擎接收到之后知道这是SQL Server的语法。它会在内部把它转成标准PG的SELECT * FROM table LIMIT 10再去执行。对于NOLOCK它也会做一些等价的处理忽略锁的要求。对于ISNULL它会自动转成COALESCE。这个过程对应用是透明的。开发人员不用改代码。应用发什么SQL过来KES就接什么SQL。这在很大程度上保护了原有的应用资产。你不需要去翻那些十几年前的烂代码。三、实际操作中的一些细节分享理论说完了咱们聊点实操的东西。真要从SQL Server迁到KES V9R4C019具体怎么个搞法。这里我按我的经验分享一下大致的步骤。3.1 迁移工具的用法思路金仓有自己的迁移工具叫KDTS。这是一个图形化的工具。你装好之后连上源端的SQL Server再连上目标端的KES。# 这里只是示意一下连接串的大致格式具体以工具界面为准# 源端 SQL Serverjdbc:sqlserver://192.168.1.100:1433;DatabaseNamemydb# 目标端 KESjdbc:kingbase8://192.168.1.200:54321/mydb在工具里你选好要迁的表、视图、存储过程。然后点开始。工具会先拉结构再拉数据。对于存储过程它会尝试做语法的自动转换。转换完之后工具会标出哪些是成功的哪些是有警告的哪些是失败的。你重点看失败和警告的那些。往往仅仅只是几个不兼容的函数调用你手动改一下就行了。不需要全盘推翻。3.2 关于停机时间的数据同步方案如果数据量真的很大停机窗口又很小。那就不能傻乎乎地停机导数据了。通常来说我们会用一种全量加增量的办法。第一步在业务不停机的情况下先做一个全量的备份恢复或者用工具做一次全量数据迁移。这时候数据是旧的。第二步开启增量同步。你可以用KES自带的逻辑复制组件或者用一些第三方的同步工具。把SQL Server的日志实时解析然后往KES里灌。第三步等到正式割接的那天。你先把应用停掉。这时候确认一下增量同步追平了。然后切断同步把应用的数据源配置改成KES的地址。重启应用。这样的话停机时间往往仅仅只是切配置和验证的这几十分钟。这个方案是很成熟的。3.3 改造后的验证方法数据迁完了应用也连上了。别以为这就完事了。你还得验证。怎么验证呢不能光看页面不报错。你要去查日志。看看应用层有没有抛出SQL语法错误的异常。然后挑几个核心的业务流程走一遍。看看数据落库对不对。特别是那些有金额计算、有时间字段更新的地方重点核对。因为类型转换很容易在这些地方出现精度丢失或者时区错位的情况。四、总结几句掏心窝子的话其实说实话没有任何一个数据库迁移工具或者兼容引擎能做到100%的零修改迁移。如果有谁这么跟你承诺那肯定是不负责任的。KES V9R4C019在SQL Server兼容这个方向上做得确实比较细。它把大家最怕的那些大坑比如存储过程改写、类型不对齐、应用代码不改的问题都通过底层的机制给兜住了很大一部分。这就能让你在项目里的工作量大打折扣。原来可能需要三个月的改造期现在可能半个月就能把应用跑起来跑通。剩下的时间你可以慢慢去优化那些警告的SQL。做国产化替换这事儿其实没有想象中那么玄乎。就是得找对工具找对方法。遇到报错别慌看日志看引擎到底把它转成了什么。拆解开来一步步处理这活儿也就干下来了。希望今天聊的这些能给正在或者准备做SQL Server迁移的兄弟们一点参考。