做数据库替换的人最怕的问题不是怎么迁是你敢不敢给个数。工期多少风险在哪哪些对象要改改多少。以前这些问题我全靠经验估估完自己心里都发虚。直到最近用上数据迁移工具 KDMS 做了一轮正经的迁移前评估才头一回拿到一份能量化的报告兼容度多少不兼容多少处分布在哪些对象类型上全都列出来。这上下两篇就聊聊我这次评估的完整过程上篇讲采集下篇讲报告本身和怎么用它做决策写的时候想到哪说到哪可能有点乱凑合看。先把痛点说透不然有人觉得评估就是个走过场。评估难到底难在哪我干替换项目四五年每次立项会都是同一个剧本。业务方问这个库迁过去要多久。我说得看对象复杂度。对方追问多复杂。我说几百个存储过程里面啥写法都有。对方再问那到底几个人几周。到这一步我就开始编了。拍个脑袋报三个月心里想的是最好能拖到四个月。问题出在哪。出在没数据。你手里只有一堆模糊的印象这个库挺老的存储过程挺多的有几段代码特别恶心。印象没法拿去排期更没法拿去扛责任。有次我报了三个月做到第二个月发现有个排产过程两千三百行游标套游标中间还夹着动态 SQL 拼 MERGE光理清主干就花了两天。那项目最后超期了超期的原因复盘来复盘去就是评估阶段根本不知道库里有这种货色。这事还牵扯到一个更麻烦的点就是兼容这个词本身。兼容度这个词先得掰扯清楚市面上一说国产库兼容 Oracle 兼容 MySQL听着都挺唬人但兼容度到底怎么算出来的各家口径不一样。我在论坛上翻过不少帖子同一个库有人说兼容度九十多有人说不兼容的地方多得吓人吵得不可开交。后来我琢磨明白了不是谁撒谎是大家量的东西不在一层。我自己习惯把兼容掰成三层看。最底下一层是建得起来DDL 能跑对象能创建存储过程能编译通过。中间一层是跑得对语义等价结果跟原来一模一样。最上面一层是跑得快性能不掉链子。工具类评估包括 KDMS 这种能量化的其实主要是第一层。它把源库对象抓过来在目标库上做转换和编译验证编译过了算兼容编译报错算不兼容。这个界定不完美我很清楚它的局限第二层的语义等价它测不了比如两个函数空值处理行为差一点点语法上谁都没错结果就是对不上。第三层性能更不用想评估环境里根本没有真实流量。但话说回来第一层难道就没价值吗。不是的。我宁可要一个明明白白的第一层数字也不要一句基本兼容问题不大。前者我至少知道有多少对象连编译都过不去后者就是一句空话。所以我对评估工具的定位一直很明确它给不了全部真相但它能把最硬的那部分骨头先啃出来剩下的靠人工补。这个认知是吃亏吃出来的。而且这个界定本身还有个绕不开的问题评估工具算兼容度的时候分子分母怎么定是按对象个数算还是按 SQL 语句条数算。同样一个库一百个表一个不兼容十个过程五个不兼容按对象算兼容度 95%按过程这个维度看就只剩一半了。数字这个东西算法一变面貌全变。所以后面看到报告里的百分比我的习惯是先翻到明细去看统计口径分类型看了心里才踏实。这个后面还会提。往下倒几年这活儿全靠手工。早几年怎么评估时间线捋一捋最早那会儿大概五六年前没人拿工具评估。大家的办法土得掉渣。连上源库把 dba_objects 之类的视图查一遍数一数有多少表多少过程Excel 里一填。然后 grep 关键字Oracle 的库就搜 MERGE、ROWNUM、CONNECT BY 出现次数MySQL 的库就搜 ON DUPLICATE KEY、GROUP_CONCAT数出来个大概乘以一个拍脑袋系数就是工期。-- 那时候的土办法大概长这样SELECTobject_type,COUNT(*)AScntFROMdba_objectsWHEREownerMYTESTGROUPBYobject_typeORDERBYcntDESC;这个方法的毛病显而易见只数了数量没看内容。三百个存储过程和三百个存储过程难度能差十倍关键看里面写了啥。而且那时候的统计粒度也糙表和过程混在一个数里你没法回答不兼容的都在哪类对象上这种问题。业务方其实就要这么个答案表好办还是过程好办直接决定改造重点压在 DBA 身上还是压在开发身上。土办法给不出只能含糊说都有一些。这种含糊在立项会上就是被追着打的软肋。后来大家学聪明了开始抽样把存储过程按行数排序挑最长的十个打开人工看。-- 按行数排序找硬骨头这个土办法我到现在还留着SELECTname,lineFROMdba_sourceWHEREownerMYTESTGROUPBYnameORDERBYlineDESCFETCHFIRST10ROWSONLY;这招我到现在还在用说实话某些时候比工具的数字还准因为你看到的是真实的代码长相恶心程度一目了然。但抽样的软肋同样明显看十个未必代表三百个万一第十一行开始全是另一种流派呢。统计学的常识样本外的风险永远存在。所以土办法和工具不是替代关系是互为补充工具给全量人去看典型。再往后厂商们开始做工具化的评估。这背后有个大势替换项目多了实施团队就那几个人不可能每个项目都扑上去人工数对象。工具化的思路也分两派一派是做静态扫描扫代码扫对象出报告另一派偏重在线测试拿一堆典型 SQL 到目标库上跑分。两派各有道理也各有盲区静态扫描覆盖全但深度浅在线测试深度够但样本有限。论坛上这俩路线的支持者也吵我的看法是别二选一覆盖面的问题用扫描解决关键路径用测试解决评估报告只是起点不是终点。KDMS 走的是前一条路线采集加静态评估。全名挺长叫金仓数据库迁移评估系统下面我全用简称。它整体分三块数据库采集应用采集兼容度评估。这个产品定位说白了就是把评估这步从老师傅带徒弟变成人人可复制的流程老师傅的经验编码成了采集范围和评估规则换个新人来也能跑出一份像样的报告。当然报告的解读还是得靠人这是后面下篇要说的重点。下面挨个说我上手的体验。部署比想象中轻先说部署。这东西跑在 Linux 上资源要求不算高内存 16G软件包占 2G 磁盘安装路径再留 5G就这些。我们拿了一台虚拟机就装了。建议用独立账号跑别拿 root 或者公用账号凑合。shell# adduser kdmsshell# su - kdms有个小坑提醒下默认安装目录是 /opt/KDMS你要直接用 kdms 这个用户装装到一半会提示没权限因为 /opt 下建目录的权限不在它手里得提前把目录授权给这个用户。访问端口默认 19007跟机器上已有的服务撞了的话安装过程中可以改。装完先做个功能验证看下日志别急着连生产。整体感觉这工具不是那种笨重的企业软件采集端和评估端是分开的采集客户端可以放到源库那边的机器上跑评估系统单独部署。这个分离设计后面会说到它的好处。好处其实一句话就能说明白采集包是隔空传话的载体。很多替换项目源库在内网 A 区评估的机器在 B 区中间隔着防火墙甚至物理隔离你不可能让评估系统直连生产库。分离之后采集器进 A 区拿包人把 zip 拷出来传到 B 区的评估系统上传链路就通了。数据不出区包能出区安全部门那边也好交代。要是评估系统直连源库的方案光安全评审就能卡你半个月。我这次是测试环境无所谓真到生产那就是另一套流程了所以提前把这种架构跑熟是有意义的。采集结构信息不碰业务数据重点说说采集这是评估的地基。地基歪了后面全歪。先说让我最安心的一条KDMS 的数据库采集只抓结构信息表、视图、触发器、约束、序列、函数、存储过程这些的 DDL不读业务数据。对生产库来说这点太重要了。你想想评估阶段就要连生产库DBA 第一个问题就是会不会影响业务会不会拖数据出来。只采结构这个答案能把 DBA 的戒心放下一大半。哦对了它还有个可选项能顺手采每张表有多少条数据、占多大磁盘空间这个是统计信息也不碰数据本身后面评估概要里会用到。采集用户也别用业务账号。手册里明确建议建临时采集用户采完就删。Oracle 这边我实际用的授权大概这么一堆。-- 建采集用户给权限采完删掉createuserKINGBASE_USER identifiedbykingbasePASSWORDdefaulttablespaceUSERS;grantconnect,resource,select_catalog_role,selectanydictionarytoKINGBASE_USER;grantexecuteonDBMS_LOGMNRtoKINGBASE_USER;grantexecuteondbms_metadatatoKINGBASE_USER;grantselectanytransactiontoKINGBASE_USER;grantanalyzeanytoKINGBASE_USER;grantEXP_FULL_DATABASEtoKINGBASE_USER;能看到这些权限对应啥吗。DBMS_LOGMNR 是挖日志的DBMS_METADATA 是抽对象 DDL 的EXP_FULL_DATABASE 是为了采 DBLINK 结构。每个权限都有明确的用途这点我喜欢不是让你直接 root 级别梭哈。要是 Oracle 12c 的 CDB 架构还有点麻烦得连到 CDB 上建 COMMON USER用户名得带 c## 前缀授权全要加 containerall踩过一次坑就记住了。-- 12c CDB 模式用户名前缀 c## 不能少createuserc##KINGBASE_USER identified by kingbasePASSWORDdefaulttablespaceUSERS;grantconnect,resource,select_catalog_role,selectanydictionarytoc##KINGBASE_USER containerall;grantexecuteondbms_metadatatoc##KINGBASE_USER containerall;grantselectanytabletoc##KINGBASE_USER containerall;支持的源库类型Oracle、DB2、MySQL、SQL Server、Sybase主流的都覆盖了。新建采集的时候填 IP 端口用户密码然后选对象类型。Oracle 那边能选的对象类型列出来感受下INDEX、SEQUENCE、SYNONYM、TABLE、VIEW、MATERIALIZED VIEW、TYPE、TYPE BODY、FUNCTION、PACKAGE、PACKAGE BODY、PROCEDURE、TRIGGER、DATABASE LINK、JOB、CONTEXT。十六种比我手工评估时看的全。以前我就看表和过程SYNONYM 和 TYPE 这些经常漏漏了之后迁移时就出幺蛾子。有个细节Oracle 填 SID 还是服务名RAC 环境必须选服务名填 Schema 的时候注意大小写。这种小地方手册里都会提一句但真上手的时候十个人有八个第一次就栽在这我算其中一个。还有采集耗时的事我这个测试库两千来个对象从开始到采集完成一分半钟进度条到 100% 就能下载采集包了。包很小压缩前不到 1M。当然这是结构信息的量级要是勾了数据量统计会稍微大一点但也就几十 M 的级别跟数据本身比可以忽略。别小看这点有的评估方案要把数据导出来搭影子库再测几 T 的库光倒腾一遍就得几天评估还没开始成本先堆上去了。顺便说下采集包里的结构。解压开是个按时间戳命名的文件夹里面是各对象的 DDL 文件再配上前面说的那个 meta 文件。这里有个坑COLLECTOR_META.dat 记录了这次采集的元信息建评估项目的时候要校验它不存在或者不合法就建不了。所以不同库的采集包别混着用也别拿一个 meta 文件到处复制老老实实一次采集一个包。我一开始没当回事两个库的包放一个目录里改名混用结果建评估项目直接报错翻日志才发现是 meta 校验没过。规矩就是规矩人家这么设计也是为了防止张冠李戴评估一个库的结果挂在另一个库头上那报告就成废纸了。历史SQL采集从 shared pool 里捞真实语句上面说的是对象采集评估的是库里住着的东西。但还有一类东西对象采集看不见就是应用实际跑的 SQL。老系统的 SQL 一半在存储过程里还有一大半在应用代码里拼着光看库不知道业务到底怎么用它。KDMS 给了两条路补这块。一个叫历史 SQL 采集原理挺有意思走 Oracle 的 v$sqlarea 视图。-- 采集器本质上是查这个视图字段说明SELECTSQL_FULLTEXT,-- SQL 完整文本含绑定变量LOADS,-- 加载进共享池的次数LAST_ACTIVE_TIME,-- 最后活动时间用它控制采集范围COMMAND_TYPE,-- 语句类型 SELECT/INSERT/...PARSING_SCHEMA_NAME-- 执行时用的模式名FROMv$sqlarea;这个视图持续跟踪 shared pool 里所有共享 cursor跑过的 SQL 基本都在里面躺着。好处是不用改应用不用重启坏处也明显shared pool 是滚动的老 SQL 会被挤出去所以得定期采LAST_ACTIVE_TIME 就是拿来圈时间范围的。这个思路不是它一家独有但做成工具自动跑确实省事。采这个有什么用我举自己的例子。有个老系统库里的存储过程看着风平浪静评估兼容度也高但业务方死活不敢说应用不用改。为什么因为应用里 Mybatis 拼的 SQL 有一千多句全在 java 代码和 xml 里你评估库对象等于只看了半张地图。这时候历史 SQL 采集就顶用了把 shared pool 里捞出来的真实语句跑一遍评估哪些写法在目标库上会翻车列得清清楚楚。比翻代码一页页人肉看强太多。当然它也有覆盖盲区刚跑完一批不常见的报表 SQLshared pool 还没来得及淘汰正好在你采集窗口里它就被抓到了反过来错过窗口的就成了漏网之鱼。所以真要较真就得在业务高峰后采一次月底结账后再采一次多采几轮拼全貌。另一条路是应用采集分静态和动态。静态的扫代码把 Java 项目里的 Mapper xml 文件和 SQL 脚本打包成 zip 传上去选好语法类型就开扫。动态的更狠挂到运行中的应用上采实际执行的 SQL 加调用堆栈。我这次只试了静态的 Mapper 扫描动态那个需要在应用侧动东西得开发配合评估阶段还没走到那步。踩坑记录采集环节报错不少捡几个典型的。先说结论这环节的报错九成都是环境和权限问题跟工具本身关系不大但每个都得耗你一阵。Oracle 那边最容易碰 insufficient privileges就是采集用户权限没给够回去对着授权清单补补完重试就好最气的是它不会一次告诉你要哪些权限缺一个报一个。MySQL 那边我碰到过两次报错一次是 Latin1 is not supported字符集的事源库建库用了 latin1得先统一到 utf8 再采这个没绕的办法老库改字符集本身就是个课题。另一次是 CLIENT_PLUGIN_AUTH is required这个是驱动版本对不上老驱动连新协议不支持换个高版本的驱动包就好了。SQL Server 的坑更刁钻连接报 18456 登录失败查了半天发现是实例认证模式的问题改完又冒出来一个 SetARITHABORT 不正确执行采集语句前得把 ARITHABORT 设置对齐还有个备份集中的数据库备份与现有的数据库不同的报错那是拿错备份还原的库元数据对不上这种属于自己坑自己。一个个都解决了但过程确实烦建议采集前先拿个小库把流程走通别一上来就连生产。测试连接失败这种通用报错就不用说了先查网络和端口。采集完就到评估了。把采集包上传系统自动识别出源库类型和兼容模式评估名称带出来可以改然后选目标版本点确认评估任务就跑起来了。如果部署的时候装了评估插件采集完成页面上会直接给个立即评估按钮一步到位省得下载再上传那个 zip。采完了顺手还试了个小功能在线评估。评估菜单下面单独一个入口进去就是一个 SQL 编辑页选好目标版本和兼容模式把一句话贴进去立刻告诉你这句在目标库上能不能跑。这功能看着不起眼评审会上特别好使。有次开发质疑某个写法迁过去行不行我当场贴进去跑给他看比嘴上争十分钟管用。当然它也是只验编译不验语义这个前面说过的局限在这里同样成立别迷信。评估跑完进详情页第一眼看到概要兼容数量不兼容数量还有一个大大的兼容度百分比。我看到那个数字的第一反应不是高兴是犯嘀咕这数字怎么算的可信吗能直接拿去汇报吗。而且这轮评估我还发现一个此前没细想的点评估对象是死的人是活的。同一个库这周采一遍和下周采一遍结果可能就不一样因为开发可能又改了两个过程。评估报告是有时效的快照不是一锤定音的判决书。所以我的做法是把评估放在对象冻结之后跟开发约好评估窗口期内谁也别动库评估完再解冻。这么点小事但它决定了报告的严肃性。这些疑问的答案还有那份评估报告到底长啥样、细到什么程度、怎么拿它算工作量放下篇细说。采集这块最后再啰嗦一句临时用户采完记得删别嫌麻烦留着就是留风险。