【Oracle版本升级】在实际开发中，Oracle11G版本升级到19C过程中遇到的问题

• Oracle升级性能优化须注意的

        1.在升级过程中，简单SQL（指单表操作，where条件与索引第一二键匹配）通常不会有性能影响，这类SQL不是最需要关注的。
        2.复杂的sql（比如多子表查询、多表关联、循环嵌套）运行过程中，有些SQL会遇到性能变化情况，重点关注。
        3.Oracle优化器方面，优化器模式有两种主要原则：
            （1）第一种模式_optimzer_cost_based_transformation=off, _optimizer_squ_bottomup=false
            （2）第二种模式_optimzer_cost_based_transformation=on, _optimizer_squ_bottomup=true
            （3）这两种模式优化器需要在性能测试时，重点评估选择哪种模式。目前看，对于SQL很复杂与OLAP查询类比较多的建议选择第二种模式。
        4.通过测试已决定优化器选择哪种优化器模式的情况下，需要重点关注部分复杂SQL性能发生了变化的，对于个别性能变化的SQL需要通过hint等指定执行计划，规避优化器对此类SQL的性能影响。
        5.对于在程序开发、编码和测试过程中，已明确SQL执行计划的，也可以采用hint固定执行计划，确保SQL执行效率不受软件版本升级影响。

• sql性能问题查找，如何确定哪些SQL性能会在升级后发生变化呢？

        1.测试场景要齐全。很多人在性能测试时只关注联机交易（一直在压测联机交易tips），其实联机交易通常SQL简单，反而不容易出问题；可能有时候就容易忽略批处理、报表类交易（因为相比联机，这些交易相对来说显得不重要），但此类交易往往是复杂SQL，更容易在升级过程中出现问题，此部分交易也需要重点压测；
        2.测试数据需来自生产，确保数据量一致，性能测试结果才准确；
        3.重要系统、报表类系统，推荐全面对比执行计划，确保执行效率稳定（非常有效）  但是有点耗时
          方法一：采用SPA获取Oracle 11g下业务系统所有SQL与SQL执行计划，然后将这些SQL在待投产的Oracle 19C数据库进行回放，然后比对执行计划效率变化，对于有执行计划变化的SQL，继续宁重点分析或固定执行计划。（此方法需要花费很多开发DBA工作量），需要两套环境，一套Oracle 11G,一套Oracle 19C；
          方法二：对于无法对比的业务系统，可在压测过程中（覆盖所有业务场景），捕获平均执行时间大于X秒的语句，然后批量解释这些SQL在Oracle 19C的执行计划，然后进行挨个优化或固定执行计划；
          方法三：类似于方法二，捕获SQL后，在Oracle 11G批量解释执行计划；然后在Oracle 19C环境批量解释一下执行计划，获取执行计划变化的SQL，继续调优。

• 实际项目中的解决办法

系统采用的是优化器降级的方式进行性能优化，在升级了19C之后报表或者复杂sql的执行计划变大，效率变低，怀疑是高版本的19C导致的
        1.查看优化器版本，对比11g和19c  
            show parameter optimizer_features_enable;---用Oracle用户登录查询
        2.调整优化器版本
            alter system set optimizer_features_enable='11.2.0.3' scope=both;
        3.收集统计信息
            exec dbms_stats.gather_schema_stats (ownname=>'数据库实例名',estimate_percent=>dbms_stats.auto_sample_size,method_opt=>
            'for all columns size auto',degree=>4,cascade=>true);
 

mark学习。