Oracle 11g RAC升级19c后SQL性能衰退解决方法

Oracle 11g RAC升级到19c之后，SQL变慢，十有八九不是SQL写坏了，而是优化器“误判”了数据分布——统计信息没重收集、直方图缺失、采样失真，这三类问题占了实际性能衰退案例的八成以上。

查执行计划突变比查SQL本身更有效

别急着改SQL或者加HINT。先把执行路径确认清楚：

• 在19c中对慢SQL执行 EXPLAIN PLAN FOR SELECT ...，然后用 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY) 看看实际走的路径。
• 重点对比：是不是从 INDEX RANGE SCAN 变成了 TABLE ACCESS FULL，或者从 NESTED LOOPS 变成了 HASH JOIN。
• 如果和11g里用 DBMS_XPLAN.DISPLAY_AWR 查到的历史计划不一致，基本可以锁定是统计信息或优化器行为变化导致的。

DBMS_STATS.GATHER_SCHEMA_STATS不能直接开跑

直接跑 DBMS_STATS.GATHER_SCHEMA_STATS 很可能救不了火，反而火上浇油——尤其是在分区表、LOB字段多、状态码字段集中的业务库里。几个关键点要小心：

• 避免 estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE：19c对超大表的默认采样逻辑更激进，容易低估高频值密度，导致直方图不准。
• method_opt => 'FOR ALL COLUMNS SIZE AUTO' 在19c中倾向少建直方图；对于取值少但倾斜严重的字段（比如 order_status 只有'P','S','C'），必须显式写成 'FOR COLUMNS SIZE 254 order_status'。
• cascade => TRUE 必须配合 degree => 4 或更高：否则索引统计滞后于表统计，优化器看到“表小但索引大”，反而弃用索引。

驱动和优化器兼容性开关要同步验证

有些SQL在PL/SQL Developer里反赌，但在应用里慢，根本原因往往是JDBC驱动或客户端行为不一致。如果用的是旧版JDBC（比如ojdbc6），可能触发隐式类型转换或绑定变量窥探失效；优先升级到 ojdbc8 或 ojdbc11。临时验证可以用 /*+ OPTIMIZER_FEATURES_ENABLE('11.2.0.4') */ 强制回退优化器行为，但仅作诊断用，不可长期依赖。另外注意 sqlnet.ora 中的 SQLNET.ALLOWED_LOGON_VERSION_SERVER 设置，如果设为8以下，可能影响部分安全特性启用，间接干扰统计信息收集权限。

最容易被忽视的坑是：迁移后没有清理11g遗留的动态采样（dynamic_sampling）Hint，或者没有禁用已经废弃的隐式转换参数（比如 _optimizer_ignore_hints=FALSE 在19c中的默认值已经变了）。这些问题不会报错，但会让统计信息和执行计划一直处于“半失效”状态。