dba_hist_active_sess_history中MERGE STATEMENT与MERGE的差异

在dba_hist_active_sess_history视图的sql_plan_operation字段中，执行计划Id 0行的MERGE STATEMENT与Id 1行的MERGE有什么区别？

某SQL的sql_id在选定sample_time内仅执行一次，其简化执行计划及dba_hist_active_sess_history子集显示，这两种SQL操作均存在“ON CPU”和“db file sequential read”等待，但MERGE STATEMENT无sql_plan_line_id（推测对应Id 0）且无有效对象信息，数据库时间主要消耗在这两者上，需明确二者差异。

执行计划示例 #

Plan hash value: 2410236922

-----------------------------------------------------------------------------------
| Id  | Operation                                   | Name                        |
-----------------------------------------------------------------------------------
|   0 | MERGE STATEMENT                             |                             |
|   1 |  MERGE                                      | [TABLE_NAME]                |
|   2 |   VIEW                                      |                             |
|   3 |    SEQUENCE                                 | [SEQUENCE_NAME]             |
|   4 |     TEMP TABLE TRANSFORMATION               |                             |
...

dba_hist_active_sess_history数据示例 #

SQL_EXEC_ID   SQL_ID          SQL_PLAN_HASH_VALUE   SQL_PLAN_LINE_ID   EVENT                         CURRENT_OBJ#   OBJECT_NAME                     SUBOBJECT_NAME         OBJECT_TYPE          SQL_PLAN_OPERATION   DBTIME
------------- --------------- --------------------- ------------------ ----------------------------- -------------- ------------------------------- ------------------     -------------------- -------------------- --------
                52yu6v2ba5jm5   0                                        ON CPU                        -1                                                                                        MERGE STATEMENT       6070
                52yu6v2ba5jm5   0                                        db file sequential read       -1                                                                                        MERGE STATEMENT       3210
                52yu6v2ba5jm5   0                                        ON CPU                        0                                                                                         MERGE STATEMENT       1970
                52yu6v2ba5jm5   0                                        db file sequential read       0                                                                                         MERGE STATEMENT        440
                52yu6v2ba5jm5   0                                        PGA memory operation          -40004158                                                                                 MERGE STATEMENT         20
                52yu6v2ba5jm5   0                                        latch: cache buffers chains   -1                                                                                        MERGE STATEMENT         10
  16777216      52yu6v2ba5jm5   2410236922            1                  ON CPU                        7253322        [TABLE_NAME]                    [SUBPARTITION_NAME]   TABLE SUBPARTITION   MERGE                  460
  16777216      52yu6v2ba5jm5   2410236922            1                  ON CPU                        7253316        [TABLE_NAME]                    [SUBPARTITION_NAME]   TABLE SUBPARTITION   MERGE                  390
  16777216      52yu6v2ba5jm5   2410236922            1                  ON CPU                        7253342        [INDEX_NAME]                                          INDEX                MERGE                  280
  16777216      52yu6v2ba5jm5   2410236922            1                  db file sequential read       7253343        [INDEX_NAME]                                          INDEX                MERGE                  170
  16777216      52yu6v2ba5jm5   2410236922            1                  db file sequential read       7253357        [INDEX_NAME]                    [PARTITION_NAME]      INDEX PARTITION      MERGE                  140
  16777216      52yu6v2ba5jm5   2410236922            1                  ON CPU                        7253501        [INDEX_NAME]                                          INDEX                MERGE                  140
  16777216      52yu6v2ba5jm5   2410236922            1                  db file sequential read       7253342        [INDEX_NAME]                                          INDEX                MERGE                  120
  16777216      52yu6v2ba5jm5   2410236922            1                  db file sequential read       7253322        [TABLE_NAME]                    [SUBPARTITION_NAME]   TABLE SUBPARTITION   MERGE                  120
  16777216      52yu6v2ba5jm5   2410236922            1                  db file sequential read       7253372        [INDEX_NAME]                    [PARTITION_NAME]      INDEX PARTITION      MERGE                  100
...

回答 #

1. 执行计划定位差异

   • MERGE STATEMENT（Id 0）是整个MERGE语句的顶层标识，代表SQL语句的整体执行框架，不属于具体执行步骤。执行计划中Id 0行永远对应语句类型（如SELECT STATEMENT、MERGE STATEMENT），不关联实际物理操作。
   • MERGE（Id 1）是具体执行步骤，对应MERGE语句中“匹配源数据与目标表、执行插入/更新”的核心物理逻辑，是实际消耗资源的操作节点。

2. ASH记录字段特征差异

   • MERGE STATEMENT对应的ASH记录无sql_plan_line_id，SQL_PLAN_HASH_VALUE为0，也无有效CURRENT_OBJ#和对象名称——因为它不绑定具体执行步骤与对象，记录的是语句执行过程中无法精准关联到某一步的开销，比如初始化、全局调度、资源分配等环节。
   • MERGE对应的ASH记录有明确的sql_plan_line_id=1，SQL_PLAN_HASH_VALUE匹配实际执行计划哈希值，且关联具体表、分区、索引对象，记录的是该MERGE步骤处理具体对象时的CPU消耗与IO等待。

3. 时间消耗场景差异

   • MERGE STATEMENT的DBTIME消耗，主要来自语句准备阶段（解析、执行计划加载、临时资源初始化）、收尾阶段（事务提交清理），以及无法归属到具体步骤的全局开销。
   • MERGE的DBTIME消耗，完全来自MERGE核心逻辑执行：匹配目标表数据、读取源数据、执行插入/更新、维护索引等具体操作的资源消耗。

内容的提问来源于Stack Exchange，提问作者Alex Bartsmon