首页

OceanBase 存储过程性能调优分析手册

瑞蓝创软件

2026-11-11

导读：存储过程调优分析手册

作者简介：宋旭亮，瑞蓝创数据库工程师

原创内容未经授权不得随意使用，转载请联系小编并注明来源

一、概述

（一）常见性能问题场景

常见的存储过程性能问题场景包括：全表扫描导致的IO瓶颈、嵌套循环中重复执行相同查询、未使用绑定变量导致的硬解析开销、事务范围过大导致的锁竞争、以及存储过程中包含大量DML操作但未做批量处理等。针对这些场景，需要采用系统化的调优方法进行分析和优化。

（二）调优方法论

存储过程调优应遵循"先定位、后优化"的原则。首先通过性能剖析工具定位耗时最高的代码行，然后分析该行的执行计划和相关参数，最后针对性地进行优化。调优过程应遵循以下流程：性能剖析→瓶颈定位→方案制定→实施优化→效果验证→回归测试。

二、DBMS_PROFILER工具介绍

（一）工具概述

DBMS_PROFILER是OceanBase数据库V4.2.3及之后版本提供的专门用于存储过程调优的工具。该工具能够对存储过程进行行级耗时的性能定位，帮助开发人员精确识别存储过程中每一行代码的执行耗时，从而快速定位性能瓶颈所在。

（二）核心能力

DBMS_PROFILER的核心能力包括：行级耗时统计，精确记录存储过程中每一行PL代码的执行时间；PL单元信息追踪，记录每次执行中涉及的PL单元（存储过程、函数、包等）的详细信息；运行会话管理，支持多次调优分析的并行执行与结果区分。

（三）架构原理

DBMS_PROFILER通过编译插桩（Compile-time Instrumentation）机制实现性能监控。在存储过程编译时，工具会自动在每行代码中插入性能采集指令，运行时这些指令会记录执行时间等性能数据，并将数据写入系统表中。这种方式相较于运行时采样具有更高的精度，能够捕捉到每一行代码的执行情况。

三、DBMS_PROFILER使用指南

（一）环境准备

在使用DBMS_PROFILER之前，请确保满足以下条件：数据库版本为OceanBase V4.2.3或更高版本；当前用户具有执行DBMS_PROFILER系统包的权限；目标存储过程已编译通过；有足够的权限访问plsql_profiler_runs、plsql_profiler_units和plsql_profiler_data等性能数据表。

（二）启动剖析器

使用DBMS_PROFILER.start_profiler过程启动性能剖析器。该过程会创建一个新的分析运行会话，并分配唯一的runid标识符。建议通过run_comment参数传入存储过程名称和执行时间，便于后续结果查询时进行区分。

启动剖析器的SQL语句如下：

call DBMS_PROFILER.start_profiler(run_comment =&gt; '存储过程名称: ' || SYSDATE);

执行该语句后，剖析器将在当前会话中启动，后续执行的存储过程将被自动监控。run_comment参数用于标注本次分析的目标，可以包含存储过程名称、执行时间等信息，方便在查询结果时进行筛选和识别。

（三）执行目标存储过程

剖析器启动后，执行需要分析的存储过程。存储过程将以正常方式执行，同时DBMS_PROFILER会持续采集每一行代码的执行耗时数据。

执行存储过程的SQL语句如下：

call your_procedure_name();

如果存储过程需要传入参数，请根据实际情况替换参数值。在执行过程中，请确保会话保持活跃状态，避免会话超时导致剖析数据丢失。对于执行时间较长的存储过程，建议适当调整会话超时参数。

（四）关闭剖析器

存储过程执行完毕后，调用DBMS_PROFILER.stop_profiler过程关闭剖析器。该过程会将当前会话中采集的所有性能数据持久化到系统表中，并结束本次分析会话。

关闭剖析器的SQL语句如下：

call DBMS_PROFILER.stop_profiler();

关闭剖析器后，建议等待几秒钟确保数据完全写入磁盘后再进行查询分析。如果在同一会话中需要多次分析不同的存储过程，可以重复"启动剖析器→执行存储过程→关闭剖析器"的流程。

（五）查询与分析结果

查询运行记录

通过查询plsql_profiler_runs表可以获取每次启动剖析器的基本信息，包括runid、启动时间、注释内容等。该表是分析结果的入口，通过runid可以关联查询其他两张表获取详细的性能数据。

查询语句如下：

select * from plsql_profiler_runs;

该表返回的字段通常包括：runid（运行标识符）、starttime（启动时间）、stoptime（停止时间）、run_comment（运行注释）等。通过查看run_comment可以快速定位到对应的存储过程分析会话。

查询PL单元信息

通过查询plsql_profiler_units表可以获取每次执行中每个PL单元（存储过程、函数、包等）的详细信息。该表记录了在分析过程中被执行的各个PL单元的名称、类型、行数等元数据信息。

查询语句如下：

select * from plsql_profiler_units where runid=17;

其中runid为启动剖析器时系统分配的标识符。通过该表可以了解哪些PL单元在本次执行中被调用，以及每个单元的代码行数等信息，为后续的行级分析提供上下文。

查询行级耗时数据

通过查询plsql_profiler_data表可以获取每次执行中每一行代码的耗时信息。这是最核心的分析数据表，包含了每行代码的执行次数、总耗时、平均耗时等关键性能指标。

查询语句如下：

select * from plsql_profiler_data where runid=17;

该表返回的字段通常包括：line#（代码行号）、total_occur（总执行次数）、total_time（总耗时）、min_time（最小耗时）、max_time（最大耗时）、avg_time（平均耗时）等。通过分析这些数据，可以精准定位到耗时最高的代码行，进而进行针对性优化。

（六）完整调优操作流程示例

以下是一个完整的存储过程调优操作流程示例：

步骤一：启动剖析器，指定分析目标。

call DBMS_PROFILER.start_profiler(run_comment =&gt; '存储过程名称: sp_calc_report' || SYSDATE);

步骤二：执行目标存储过程。

call sp_calc_report();

步骤三：关闭剖析器。

call DBMS_PROFILER.stop_profiler();

步骤四：查询运行记录，获取runid。

select * from plsql_profiler_runs order by starttime desc limit 1;

步骤五：根据runid查询PL单元信息和行级耗时数据，定位性能瓶颈。

select * from plsql_profiler_units where runid=[获取的runid];

select * from plsql_profiler_data where runid=[获取的runid] order by total_time desc;

步骤六：根据分析结果进行代码优化，然后重复上述流程验证优化效果。

四、注意事项与最佳实践

（一）编译插桩机制说明

DBMS_PROFILER通过编译插桩方式实现性能监控，这意味着在存储过程编译时就会插入性能采集代码。因此，被分析的存储过程必须是已编译状态。插桩机制会对存储过程的执行产生一定的性能开销（通常为10%-30%），因此建议在测试环境或低峰时段进行性能分析，避免对生产环境造成显著影响。

（二）Package嵌套调用技巧

DBMS_PROFILER.start_profiler会在当前package中启动剖析器，因此无法直接捕获当前package内部调用的执行情况。如果需要分析某个package A的执行情况，需要采用嵌套调用的方式：创建一个包装package B，在package B中调用package A中的目标过程。具体做法如下：

创建包装package B，在其中定义一个过程调用package A的目标过程；
在当前会话中启动DBMS_PROFILER剖析器；
调用package B中的包装过程，从而间接执行package A的目标过程；
关闭剖析器并分析结果。

这种方式可以确保剖析器能够捕获到package A中所有代码行的执行情况。

（三）Schema权限说明

DBMS_PROFILER生成的数据统计表（plsql_profiler_runs、plsql_profiler_units、plsql_profiler_data）会生成在当前执行DBMS_PROFILER系统包的schema下。因此，需要确保当前用户对这些表具有查询权限。如果使用的是非管理员用户，可能需要DBA协助授予相关权限。