接手一个 Oracle 迁移评估任务时大家习惯先看语法兼容性这个存储过程能不能跑、这个函数有没有对应实现、这张视图的写法要不要改。这些问题好查工具能扫跑一遍报错日志就知道改哪。真正让人头疼的不是这些——是那些语法完全合法、迁移后照样能跑通、只是结果跟原来不一样的地方。这类问题不报错不会出现在任何迁移报告的失败项里只会在业务侧发现报表对不上、对账差了几行的时候才暴露出来而且往往已经是上线之后了。这次评估里踩到两个这样的问题一个是外连接消除一个是空字符串到底算不算 NULL。前者排第一因为老系统里到处都是()写法的历史 SQL谁都说不清当初是不是故意要保留左表全量后者第二因为它牵扯到KES 跟 Oracle 到底像不像这个问题本身没有固定答案得看配置。环境是KES V009R001C010业务账号连接ksql-h127.0.0.1-p54321-Uapp_user-dapp_db先搭场景客户表和客户等级表createtableapp_schema.t_mig_customer(cust_idintegerprimarykey,cust_namevarchar(50)notnull,grade_codevarchar(10));createtableapp_schema.t_mig_grade(grade_codevarchar(10)primarykey,grade_namevarchar(30)notnull,grade_levelintegernotnull);insertintoapp_schema.t_mig_customer(cust_id,cust_name,grade_code)values(1,customer-a,G1),(2,customer-b,G2),(3,customer-c,null),(4,customer-d,G3);insertintoapp_schema.t_mig_grade(grade_code,grade_name,grade_level)values(G1,silver,1),(G2,gold,2);customer-c从来没定过级grade_code是 NULLcustomer-d的grade_code是G3但等级表里压根没有 G3 这一级——这是很多老系统的常态等级表维护跟不上业务扩张历史数据里留着一堆对不上号的外键值。查所有客户的场景下这两个客户理论上都应该被保留只是等级信息显示为空。陷阱一()语法本身没毛病加个条件就变味了先确认 KES 对 Oracle 这个老写法的兼容程度。()标在哪一边哪一边就是外连接里可以为空的一侧最基础的写法selectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer c,app_schema.t_mig_grade gwherec.grade_codeg.grade_code();四个客户全部返回customer-c、customer-d的grade_name是空。这一步没什么好说的()语法接得很到位老代码原样搬过来完全能用这也是 KES 主打 Oracle 兼容的地方确实兑现了。麻烦出在老系统里更常见的写法上关联条件之外业务上往往还要再加一层过滤比如只看正式定级等级值大于等于 1的客户selectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer c,app_schema.t_mig_grade gwherec.grade_codeg.grade_code()andg.grade_level1;只返回 2 行customer-a、customer-b。customer-c、customer-d不见了——这条 SQL 里明明写着()摆明了想要外连接的语义结果却只剩下内连接才会有的行数。跑一下执行计划确认这背后发生了什么explainanalyzeselectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer c,app_schema.t_mig_grade gwherec.grade_codeg.grade_code()andg.grade_level1;Hash Join没有Left或者Right字样纯内连接。原因不难理解g.grade_level 1这个条件是加在右表上的customer-c、customer-d对应的g.grade_level是 NULLNULL 1的结果是未知在WHERE里等于被扔掉。既然这些因为外连接才该保留的行反正都会被这个条件滤掉外连接 这个过滤和内连接 这个过滤结果完全一样优化器就选了开销更小的内连接去跑——这就是外连接消除跟()写没写没关系()只是外连接的一种写法底层判断逻辑跟 ANSI 的LEFT JOIN是同一套。为了确认这一点把同样的逻辑换成 ANSI 写法再跑一遍作为迁移验收阶段常用的排查方式explainanalyzeselectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer cleftjoinapp_schema.t_mig_grade gonc.grade_codeg.grade_codewhereg.grade_level1;同样是Hash Join同样没有Left字样跟()写法的表现完全一致。这也提醒做迁移验收的人不管老系统用的是()还是转译后的LEFT JOIN只要WHERE里对右表字段做了这种会把 NULL 判定为假的过滤这个坑就跑不掉光看语法转译对不对没用得拿执行计划和行数说话。修复办法是把这个过滤条件挪进关联条件里selectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer cleftjoinapp_schema.t_mig_grade gonc.grade_codeg.grade_codeandg.grade_level1;四行全部回来customer-c、customer-d的等级字段照常显示为空。这不是换个位置随便试出来的ON决定的是怎么连先按条件筛一遍右表再去外连接WHERE决定的是连完之后再筛掉什么条件放这儿就已经是连接做完之后的事了NULL 行躲不掉。迁移验收阶段发现这类问题没有捷径对每一条涉及外连接的存量 SQL迁移前后的行数必须逐条比对光看能不能跑通是不够的。陷阱二空字符串算不算 NULL得看这一套环境怎么配置这一节动笔之前先把两件事确认清楚不能凭KES 内核衍生自 PostgreSQL这种直觉去猜showdatabase_mode;showora_input_emptystr_isnull;database_mode是oracleora_input_emptystr_isnull是on。这套环境默认走的是 Oracle 兼容模式——很多人下意识觉得内核是 PG 系的行为应该跟 PG 一致这个假设在这里是不成立的还是要先确定兼容模式除非建库时特意指定成 PG 模式。而ora_input_emptystr_isnull这个参数顾名思义就是用来复刻 Oracle 那个经典行为把长度为零的字符串当成 NULL 处理。实测验证一下insertintoapp_schema.t_mig_customer(cust_id,cust_name,grade_code)values(5,customer-e,);selectcust_id,cust_name,grade_code,grade_codeisnullasis_null_flag,length(grade_code)ascode_lenfromapp_schema.t_mig_customerwherecust_id5;插入的空字符串查出来is_null_flag是t——被当成 NULL 存了code_len也是空白不是0。这跟很多人预想的PostgreSQL 体系不会这样正好相反KES 在 Oracle 兼容模式下把 Oracle 这个特有行为原样复刻了下来。对迁移读者来说这其实是个好消息如果老系统的 PL/SQL 或者业务代码依赖了空字符串等于 NULL这个假设比如用col 判断未填写只要迁移后的 KES 还在 Oracle 兼容模式下这批代码不用改行为跟原来一致。真正要小心的是反过来的情况——如果运维后续把数据库切换成 PG 兼容模式或者手动关掉了这个参数这批老代码会在没有任何报错的情况下悄悄失效。这也是这个坑最值得记住的地方它不是一个写死的结论是随兼容模式和参数走的迁移评估阶段必须在目标环境里把这两项亲自确认一遍不能凭经验预判。迁移避坑清单对所有涉及外连接LEFT/RIGHT JOIN或()的存量 SQL 做台账登记迁移前先跑一遍拿到基准行数。迁移后同样的 SQL 在 KES 上重跑行数逐条比对光凭能不能跑通判断不了对错。审查WHERE子句里是否有对右表Nullable 一侧字段的过滤且没有对称写()或没有下推到ON。迁移前先确认目标环境的database_mode和ora_input_emptystr_isnull把空字符串算不算 NULL这件事钉死再决定这部分代码要不要改。涉及财务、库存、审批类的判断逻辑这两类问题都不会报错只会悄悄改变结果验收时间再紧也不能省这两项检查。
接手一个 Oracle 迁移评估任务时大家习惯先看语法兼容性这个存储过程能不能跑、这个函数有没有对应实现、这张视图的写法要不要改。这些问题好查工具能扫跑一遍报错日志就知道改哪。真正让人头疼的不是这些——是那些语法完全合法、迁移后照样能跑通、只是结果跟原来不一样的地方。这类问题不报错不会出现在任何迁移报告的失败项里只会在业务侧发现报表对不上、对账差了几行的时候才暴露出来而且往往已经是上线之后了。这次评估里踩到两个这样的问题一个是外连接消除一个是空字符串到底算不算 NULL。前者排第一因为老系统里到处都是()写法的历史 SQL谁都说不清当初是不是故意要保留左表全量后者第二因为它牵扯到KES 跟 Oracle 到底像不像这个问题本身没有固定答案得看配置。环境是KES V009R001C010业务账号连接ksql-h127.0.0.1-p54321-Uapp_user-dapp_db先搭场景客户表和客户等级表createtableapp_schema.t_mig_customer(cust_idintegerprimarykey,cust_namevarchar(50)notnull,grade_codevarchar(10));createtableapp_schema.t_mig_grade(grade_codevarchar(10)primarykey,grade_namevarchar(30)notnull,grade_levelintegernotnull);insertintoapp_schema.t_mig_customer(cust_id,cust_name,grade_code)values(1,customer-a,G1),(2,customer-b,G2),(3,customer-c,null),(4,customer-d,G3);insertintoapp_schema.t_mig_grade(grade_code,grade_name,grade_level)values(G1,silver,1),(G2,gold,2);customer-c从来没定过级grade_code是 NULLcustomer-d的grade_code是G3但等级表里压根没有 G3 这一级——这是很多老系统的常态等级表维护跟不上业务扩张历史数据里留着一堆对不上号的外键值。查所有客户的场景下这两个客户理论上都应该被保留只是等级信息显示为空。陷阱一()语法本身没毛病加个条件就变味了先确认 KES 对 Oracle 这个老写法的兼容程度。()标在哪一边哪一边就是外连接里可以为空的一侧最基础的写法selectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer c,app_schema.t_mig_grade gwherec.grade_codeg.grade_code();四个客户全部返回customer-c、customer-d的grade_name是空。这一步没什么好说的()语法接得很到位老代码原样搬过来完全能用这也是 KES 主打 Oracle 兼容的地方确实兑现了。麻烦出在老系统里更常见的写法上关联条件之外业务上往往还要再加一层过滤比如只看正式定级等级值大于等于 1的客户selectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer c,app_schema.t_mig_grade gwherec.grade_codeg.grade_code()andg.grade_level1;只返回 2 行customer-a、customer-b。customer-c、customer-d不见了——这条 SQL 里明明写着()摆明了想要外连接的语义结果却只剩下内连接才会有的行数。跑一下执行计划确认这背后发生了什么explainanalyzeselectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer c,app_schema.t_mig_grade gwherec.grade_codeg.grade_code()andg.grade_level1;Hash Join没有Left或者Right字样纯内连接。原因不难理解g.grade_level 1这个条件是加在右表上的customer-c、customer-d对应的g.grade_level是 NULLNULL 1的结果是未知在WHERE里等于被扔掉。既然这些因为外连接才该保留的行反正都会被这个条件滤掉外连接 这个过滤和内连接 这个过滤结果完全一样优化器就选了开销更小的内连接去跑——这就是外连接消除跟()写没写没关系()只是外连接的一种写法底层判断逻辑跟 ANSI 的LEFT JOIN是同一套。为了确认这一点把同样的逻辑换成 ANSI 写法再跑一遍作为迁移验收阶段常用的排查方式explainanalyzeselectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer cleftjoinapp_schema.t_mig_grade gonc.grade_codeg.grade_codewhereg.grade_level1;同样是Hash Join同样没有Left字样跟()写法的表现完全一致。这也提醒做迁移验收的人不管老系统用的是()还是转译后的LEFT JOIN只要WHERE里对右表字段做了这种会把 NULL 判定为假的过滤这个坑就跑不掉光看语法转译对不对没用得拿执行计划和行数说话。修复办法是把这个过滤条件挪进关联条件里selectc.cust_id,c.cust_name,g.grade_namefromapp_schema.t_mig_customer cleftjoinapp_schema.t_mig_grade gonc.grade_codeg.grade_codeandg.grade_level1;四行全部回来customer-c、customer-d的等级字段照常显示为空。这不是换个位置随便试出来的ON决定的是怎么连先按条件筛一遍右表再去外连接WHERE决定的是连完之后再筛掉什么条件放这儿就已经是连接做完之后的事了NULL 行躲不掉。迁移验收阶段发现这类问题没有捷径对每一条涉及外连接的存量 SQL迁移前后的行数必须逐条比对光看能不能跑通是不够的。陷阱二空字符串算不算 NULL得看这一套环境怎么配置这一节动笔之前先把两件事确认清楚不能凭KES 内核衍生自 PostgreSQL这种直觉去猜showdatabase_mode;showora_input_emptystr_isnull;database_mode是oracleora_input_emptystr_isnull是on。这套环境默认走的是 Oracle 兼容模式——很多人下意识觉得内核是 PG 系的行为应该跟 PG 一致这个假设在这里是不成立的还是要先确定兼容模式除非建库时特意指定成 PG 模式。而ora_input_emptystr_isnull这个参数顾名思义就是用来复刻 Oracle 那个经典行为把长度为零的字符串当成 NULL 处理。实测验证一下insertintoapp_schema.t_mig_customer(cust_id,cust_name,grade_code)values(5,customer-e,);selectcust_id,cust_name,grade_code,grade_codeisnullasis_null_flag,length(grade_code)ascode_lenfromapp_schema.t_mig_customerwherecust_id5;插入的空字符串查出来is_null_flag是t——被当成 NULL 存了code_len也是空白不是0。这跟很多人预想的PostgreSQL 体系不会这样正好相反KES 在 Oracle 兼容模式下把 Oracle 这个特有行为原样复刻了下来。对迁移读者来说这其实是个好消息如果老系统的 PL/SQL 或者业务代码依赖了空字符串等于 NULL这个假设比如用col 判断未填写只要迁移后的 KES 还在 Oracle 兼容模式下这批代码不用改行为跟原来一致。真正要小心的是反过来的情况——如果运维后续把数据库切换成 PG 兼容模式或者手动关掉了这个参数这批老代码会在没有任何报错的情况下悄悄失效。这也是这个坑最值得记住的地方它不是一个写死的结论是随兼容模式和参数走的迁移评估阶段必须在目标环境里把这两项亲自确认一遍不能凭经验预判。迁移避坑清单对所有涉及外连接LEFT/RIGHT JOIN或()的存量 SQL 做台账登记迁移前先跑一遍拿到基准行数。迁移后同样的 SQL 在 KES 上重跑行数逐条比对光凭能不能跑通判断不了对错。审查WHERE子句里是否有对右表Nullable 一侧字段的过滤且没有对称写()或没有下推到ON。迁移前先确认目标环境的database_mode和ora_input_emptystr_isnull把空字符串算不算 NULL这件事钉死再决定这部分代码要不要改。涉及财务、库存、审批类的判断逻辑这两类问题都不会报错只会悄悄改变结果验收时间再紧也不能省这两项检查。
