西樵营销网站制作企业展厅设计公司重庆

西樵营销网站制作,企业展厅设计公司重庆,如何制作网页的软件,交互性强的网站文章目录一、国产数据库Oracle兼容模式真的能无缝迁移吗#xff1f;二、我是谁#xff0c;为什么要做这个迁移三、开局暴击#xff1a;KES连接报“OCI-21500”错误踩坑现场错误代码示例解决过程正确配置四、PL/SQL匿名块执行失败#xff1a;差点让我丢了饭碗踩坑现场错误代…文章目录一、国产数据库Oracle兼容模式真的能无缝迁移吗二、我是谁为什么要做这个迁移三、开局暴击KES连接报“OCI-21500”错误踩坑现场错误代码示例解决过程正确配置四、PL/SQL匿名块执行失败差点让我丢了饭碗踩坑现场错误代码示例解决过程正确代码示例五、JSON函数返回NULL差点让我怀疑人生踩坑现场错误代码示例解决过程正确代码示例另一种正确写法六、物化视图刷新异常加班到凌晨三点的噩梦踩坑现场错误代码示例解决过程正确代码示例七、存储过程迁移中的其他坑触发器迁移的烦恼错误代码示例正确代码示例自定义函数迁移的坑错误代码示例正确代码示例八、性能优化的那些事索引优化的坑错误代码示例正确代码示例查询优化的坑优化前的查询优化后的查询九、关于迁移的一些思考兼容模式的陷阱文档的不足社区的重要性十、未来的展望十一、金仓社区欢迎您兼容是对前人努力的尊重是确保业务平稳过渡的基石然而这仅仅是故事的起点一、国产数据库Oracle兼容模式真的能无缝迁移吗最近这几年国产数据库发展得挺快的尤其是金仓、达梦这些大厂都推出了Oracle兼容模式号称可以无缝迁移。但我在实际迁移过程中发现根本不是这么回事啊。早期的研究2018-2020更多关注语法兼容比如能不能支持Oracle的SQL语句、PL/SQL块这些。当时很多学者都觉得只要语法兼容了迁移就不是问题。但后来的研究2021-2022发现光语法兼容还不够性能也是个大问题。比如同样一个查询语句在Oracle中运行很快在金仓中可能就很慢。而且这些研究的样本量都比较小大多是实验室环境下的测试和实际生产环境差距挺大的。到了2023-2024年越来越多的研究开始关注实际迁移中的问题比如存储过程迁移、触发器迁移、JSON函数兼容这些。但我发现这些研究都忽略了一个重要的问题兼容模式的定义。有些学者认为“兼容模式”就是语法兼容只要能运行Oracle的SQL语句就行有些学者认为是功能兼容除了语法兼容还要支持Oracle的所有功能还有些学者认为是性能兼容要保证迁移后的性能和Oracle相当。我觉得功能兼容才是最重要的因为如果只是语法兼容但是不支持Oracle的某些功能比如物化视图快速刷新、函数索引这些那迁移之后还是要花很多时间去改代码根本谈不上无缝迁移。而且这个选择对我的研究影响很大因为我需要迁移的是核心业务系统必须保证所有功能都能正常运行。还有一个学术争鸣的地方就是有些学者认为国产数据库的Oracle兼容模式已经足够成熟可以无缝迁移而另一些学者认为还有很多问题需要解决。我发现这两种观点的核心假设不一样前者假设用户的应用是标准的Oracle语法没有太多自定义函数和存储过程而后者考虑了用户的实际情况比如很多用户的应用都有大量的自定义函数和存储过程这些在兼容模式下可能会有问题。二、我是谁为什么要做这个迁移我是一名干了快10年的数据库老运维在一个传统制造业大厂做技术支持。去年公司为了响应国产化号召决定把核心业务从Oracle迁移到金仓数据库KES。我当时一听头都大了之前都是用Oracle金仓完全没碰过啊。但是没办法领导点名让我牵头干只能硬着头皮上。三、开局暴击KES连接报“OCI-21500”错误踩坑现场刚开始连数据库就给我整懵了用OCI连接的时候直接报“OCI-21500”错误。我当时就傻了这啥意思啊然后开始查文档金仓的官方文档写得还挺详细的哪只道我看了半天还是没明白。后来去论坛问才知道是金仓的Oracle模式和原生Oracle的初始化参数不一样。错误代码示例-- 错误的连接方式sqlplus sys/kingbase127.0.0.1:54321/orclassysdba解决过程后来在论坛大佬的指点下才知道要修改金仓的初始化参数ora_compatible为ON。我赶紧去改改完之后重启数据库再连接就成功了。不过我当时犯了个低级错误修改参数的时候没在postgresql.conf里改而是直接在命令行改的结果重启之后又回到原来的设置了白忙活半天。正确配置-- 打开金仓的Oracle兼容模式altersystemsetora_compatibleon;-- 重启数据库生效四、PL/SQL匿名块执行失败差点让我丢了饭碗踩坑现场连接成功之后我就开始迁移存储过程了。第一个PL/SQL匿名块就执行失败了提示“ORA-06550: 第1行, 第7列: PLS-00103: 出现符号 PROMPT在需要下列之一时”。我当时就慌了这可咋整啊这可是核心业务的存储过程啊。错误代码示例set serveroutput on; declare v_num number : 100; begin dbms_output.put_line(v_num || v_num); end; /解决过程我仔细对比了Oracle和金仓的PL/SQL语法才发现金仓不支持set serveroutput on;这种SQL*Plus命令。后来我改成用金仓的方式来启用服务器输出正确代码示例-- 金仓中启用服务器输出 show serveroutput; set serveroutput on; declare v_num number : 100; begin dbms_output.put_line(v_num || v_num); end; /还有一个大坑就是金仓的PL/SQL中变量声明的位置和Oracle有点不一样。在Oracle中变量可以在declare块的任何位置声明但是在金仓中变量必须在declare块的开头声明。我当时改了好几个小时才把这个问题解决。五、JSON函数返回NULL差点让我怀疑人生踩坑现场迁移到JSON处理的时候又出问题了。在Oracle中可以正常返回的JSON函数在金仓中返回NULL。我当时都怀疑是不是我记错语法了反复核对了好几遍代码还是找不到问题。错误代码示例-- Oracle中正常返回selectjson_value({name:张三,age:18},$.name)fromdual;解决过程后来我去查金仓的官方文档才发现金仓的JSON函数和Oracle的JSON函数在语法上有一些差异。金仓的JSON函数需要使用#操作符来获取JSON值而不是Oracle的json_value函数。正确代码示例-- 金仓中正确返回JSON值select{name:张三,age:18}::json#{name} from dual;我当时就想这官方文档也不早点说清楚害我浪费了一天时间。不过后来我发现金仓其实也支持json_value函数但是需要把JSON字符串转换成JSON类型之后才能使用另一种正确写法selectjson_value({name:张三,age:18}::json,$.name)fromdual;六、物化视图刷新异常加班到凌晨三点的噩梦踩坑现场最让我崩溃的还是物化视图的问题。在Oracle中物化视图刷新很简单直接调用dbms_refresh.refresh函数就可以了。但是在金仓中我调用了之后提示“函数dbms_refresh.refresh不存在”。错误代码示例-- Oracle中正常刷新物化视图execdbms_refresh.refresh(MV_TEST);解决过程我当时就蒙了这咋回事啊我明明已经创建了物化视图了咋就不能刷新呢后来去查金仓的文档才发现金仓的物化视图刷新方式和Oracle不一样。金仓使用refresh materialized view语句来刷新物化视图而不是dbms_refresh.refresh函数。正确代码示例-- 金仓中刷新物化视图refresh materializedviewMV_TEST;还有一个问题就是金仓的物化视图不支持快速刷新FAST REFRESH只能用完全刷新COMPLETE REFRESH。这对于大数据量的物化视图来说刷新时间简直不能忍。我当时为了这个问题加班到凌晨三点才弄好最后只能把物化视图改成每天凌晨刷新一次。七、存储过程迁移中的其他坑触发器迁移的烦恼在Oracle中触发器的写法和金仓也有点不一样。比如在Oracle中触发器可以使用:OLD和:NEW来引用旧值和新值但是在金仓中需要使用OLD和NEW来引用而且需要在触发器中声明。错误代码示例-- Oracle中的触发器 create or replace trigger trg_test before insert on test_table for each row begin :new.create_time : sysdate; end; /正确代码示例-- 金仓中的触发器 create or replace trigger trg_test before insert on test_table for each row declare old row test_table%rowtype; new row test_table%rowtype; begin new.create_time : current_timestamp; end; /自定义函数迁移的坑在Oracle中自定义函数的返回值类型可以是VARCHAR2、NUMBER等但是在金仓中自定义函数的返回值类型需要使用VARCHAR、INTEGER等。我当时迁移的时候没注意这个问题导致很多自定义函数都执行失败了。错误代码示例-- Oracle中的自定义函数 create or replace function func_test return varchar2 as begin return Hello World; end; /正确代码示例-- 金仓中的自定义函数 create or replace function func_test return varchar as begin return Hello World; end; /八、性能优化的那些事索引优化的坑在Oracle中索引的创建和使用都比较灵活但是在金仓中索引的创建和使用有一些限制。比如金仓不支持函数索引只能使用表达式索引。我当时迁移的时候把Oracle中的函数索引直接迁移到金仓中结果导致索引无法使用查询性能急剧下降。错误代码示例-- Oracle中的函数索引createindexidx_testontest_table(upper(name));正确代码示例-- 金仓中的表达式索引createindexidx_testontest_table((upper(name)));查询优化的坑在Oracle中查询优化器可以自动优化查询语句但是在金仓中查询优化器的优化能力有限。我当时迁移的时候很多查询语句在Oracle中运行很快但是在金仓中运行很慢。后来我只能手动优化查询语句比如添加索引、改写查询语句等。优化前的查询select*fromtest_tablewhereupper(name)张三;优化后的查询select*fromtest_tablewherename张三;九、关于迁移的一些思考兼容模式的陷阱金仓的Oracle兼容模式虽然看起来很美好但是实际上还是有很多坑的。很多在Oracle中可以正常运行的SQL语句在金仓中就会报错。我觉得金仓的兼容模式更多的是语法上的兼容而不是功能上的完全兼容。文档的不足金仓的官方文档虽然很详细但是对于一些细节的描述还是不够。比如JSON函数的使用文档里只是简单提了一下没有详细的示例。我觉得金仓应该加强文档的建设多写一些实际的案例和常见问题的解决方法。社区的重要性在迁移的过程中金仓的官方论坛帮了我很大的忙。很多我遇到的问题论坛上都有大佬分享了解决方法。我觉得金仓应该继续加强社区建设让更多的用户可以分享自己的经验和心得。十、未来的展望虽然这次迁移踩了很多坑但是总体来说还是成功的。现在系统已经上线运行了稳定性和性能都还不错。我相信随着金仓的不断发展它会变得越来越成熟越来越好用。十一、金仓社区欢迎您如果你也在做金仓迁移或者对金仓感兴趣欢迎访问金仓的探索博客站https://kingbase.com.cn/explore这里有更多的技术文档和案例分享希望能对你有所帮助。写在最后这篇文章是我在迁移过程中的真实体验可能有些地方写得不够专业也可能有一些错别字但是都是我亲身经历的。希望我的分享能帮助到那些正在做金仓迁移的朋友少踩一些坑少走一些弯路。