Oracle SQL Profile实战：手动绑定执行计划的三种高效方法

1. 为什么需要手动绑定Oracle执行计划？

做过Oracle数据库优化的朋友都知道，执行计划飘忽不定是让人最头疼的问题之一。想象一下这样的场景：一条关键业务SQL昨天还跑得好好的，今天突然就变慢了，检查发现执行计划完全变了样。这种情况在OLTP系统中尤为常见，往往会导致业务高峰期出现性能雪崩。

我遇到过最夸张的一个案例是某电商平台的订单查询SQL，原本走索引只需要几十毫秒，执行计划突变后改为全表扫描，直接拖垮了整个数据库。当时凌晨三点被叫起来处理，那种酸爽至今难忘。

SQL Profile的本质就是给SQL语句"打补丁"，在不修改原SQL文本的情况下，通过Hint来引导优化器生成我们想要的执行计划。与SQL Patch不同，SQL Profile是通过DBMS_SQLTUNE包来创建和管理的，属于Oracle官方推荐的执行计划绑定方式。

2. 三种手动绑定方法的原理对比

2.1 极简版脚本的核心逻辑

这个方法的精髓在于直接从内存中提取好的执行计划对应的Hint：

sql复制select extractvalue(value(d), '/hint') 
from xmltable('/*/outline_data/hint' 
     passing (select xmltype(other_xml) 
              from v$sql_plan 
              where sql_id = '&good_sqlid')) d;

我曾经在客户严格管控的内网环境用过这个方法，当时连脚本都无法上传，只能手敲这几十行代码。虽然看起来简陋，但效果一点不打折扣，就像瑞士军刀一样小巧但实用。

2.2 coe_xfr_sql_profile脚本的运作机制

这个由Oracle ACE总监Carlos Sierra编写的脚本，实际上做了三件事：

1. 从V$SQL_PLAN中提取目标SQL的完整执行计划信息
2. 将这些信息转换为SQL Profile所需的XML格式
3. 调用DBMS_SQLTUNE.IMPORT_SQL_PROFILE创建Profile

它的独特价值在于支持跨数据库迁移执行计划。我曾在数据仓库迁移项目中使用它，将测试环境调优好的执行计划批量应用到生产环境，节省了大量重复调优时间。

2.3 coe_load_sql_profile的智能之处

这个脚本是前者的升级版，最大的改进是交互式操作：

sql复制SQL> @coe_load_sql_profile
Enter original_sql_id: 18z48fk2jy688  -- 问题SQL
Enter modified_sql_id: 189a578w09x47   -- 优化后的SQL
Enter plan_hash_value: 4244861920      -- 好的执行计划

它自动完成好坏SQL的Hint提取和替换，就像有个专家在旁边手把手指导。实测下来，用这个脚本绑定一个执行计划平均只需2分钟，特别适合紧急故障处理。

3. 手把手实战演示

3.1 场景准备：模拟执行计划突变

我们先创建一个经典的两表关联查询：

sql复制-- 创建测试表
CREATE TABLE t1 AS SELECT * FROM dba_objects;
CREATE TABLE t2 AS SELECT * FROM dba_objects;

-- 创建问题索引
CREATE INDEX t2_idx ON t2(object_id);

-- 收集统计信息
EXEC dbms_stats.gather_table_stats(user, 'T1');
EXEC dbms_stats.gather_table_stats(user, 'T2');

然后故意制造一个性能问题：

sql复制-- 好的SQL：走索引
SELECT * FROM t2 WHERE object_id = 100;

-- 坏的SQL：强制全表扫描
SELECT /*+ FULL(t2) */ * FROM t2 WHERE object_id = 100;

3.2 使用coe_load_sql_profile绑定

查询两个SQL的ID和执行计划：

sql复制SELECT sql_id, plan_hash_value, sql_text 
FROM v$sql 
WHERE sql_text LIKE '%t2 WHERE object_id = 100%';

假设得到如下结果：

• 好SQL：sql_id='7m93h2qn1r4st', plan_hash_value=4244861920
• 坏SQL：sql_id='a12bc34d56efg', plan_hash_value=1513984157

执行绑定：

sql复制@coe_load_sql_profile
-- 依次输入坏SQL ID、好SQL ID、好执行计划的HASH值

验证效果：

sql复制-- 再次执行原问题SQL
SELECT /*+ FULL(t2) */ * FROM t2 WHERE object_id = 100;

-- 查看执行计划
SELECT * FROM TABLE(dbms_xplan.display_cursor('a12bc34d56efg',null,'ALL'));

你会看到执行计划已经从全表扫描变为索引扫描，同时Note部分显示SQL Profile已生效。

3.3 常见踩坑点

1. Hint不生效：确保Hint包含Query Block Name，例如INDEX(@"SEL$1" "T2"@"SEL$1")而不是简单的INDEX(T2)

2. 统计信息干扰：手动绑定后，建议锁定统计信息：

   sql复制EXEC dbms_stats.lock_table_stats('SCOTT','T2');
   

3. 环境差异：测试环境绑定的Profile迁移到生产环境时，要检查索引是否一致

4. 高级应用技巧

4.1 批量绑定技巧

当需要处理大量SQL时，可以用这个PL/SQL块自动生成绑定脚本：

sql复制DECLARE
  CURSOR c_bad_sql IS
    SELECT sql_id, plan_hash_value
    FROM v$sql
    WHERE executions > 100 
    AND buffer_gets/executions > 10000;
BEGIN
  FOR r IN c_bad_sql LOOP
    DBMS_OUTPUT.PUT_LINE('@coe_load_sql_profile '||r.sql_id||' [good_sql_id] '||r.plan_hash_value);
  END LOOP;
END;

4.2 执行计划稳定性监控

建议创建定期检查Job：

sql复制BEGIN
  DBMS_SCHEDULER.CREATE_JOB(
    job_name        => 'CHECK_SQL_PROFILES',
    job_type        => 'PLSQL_BLOCK',
    job_action      => 'BEGIN
                         FOR c IN (SELECT name FROM dba_sql_profiles) LOOP
                           -- 检查Profile是否生效的逻辑
                         END LOOP;
                       END;',
    start_date      => SYSTIMESTAMP,
    repeat_interval => 'FREQ=DAILY;BYHOUR=2',
    enabled         => TRUE);
END;

4.3 与SQL Plan Baseline的配合使用

在Oracle 11g之后，可以形成防御体系：

1. SQL Profile解决当前紧急问题
2. SQL Plan Baseline防止执行计划再次突变
3. SQL Patch处理特殊复杂场景

5. 性能对比测试

我用100万数据量的测试表做了组对比实验：

其中coe_xfr_sql_profile在跨实例迁移时稳定性最好，而coe_load_sql_profile在紧急处理时效率最高。

6. 疑难问题解决方案

问题1：绑定后执行计划没变化？

• 检查Hint是否包含Query Block Name
• 确认没有其他更强的Hint冲突
• 检查SQL Profile是否被禁用

问题2：绑定后性能反而下降？

• 可能是绑定错了执行计划
• 用SQLT解绑后重新分析：

  sql复制EXEC dbms_sqltune.drop_sql_profile('profile_name');
  

问题3：生产环境不敢直接操作？

• 先在测试环境用SQL Playback重放负载
• 使用DBMS_SQLTUNE.CREATE_STGTAB创建传输表
• 通过Datapump将Profile安全迁移到生产环境

7. 真实案例分享

去年某证券交易系统升级后，关键的风控查询SQL执行时间从200ms暴涨到15秒。通过分析发现：

1. 新版本优化器错误估计了分区表的基数
2. 导致选择了低效的并行全表扫描
3. 使用coe_load_sql_profile绑定原有执行计划
4. 同时创建SPM防止再次变化

整个过程只用了30分钟就解决了问题，比回退版本或修改SQL的风险小得多。这个案例让我深刻体会到手动绑定执行计划的价值。