3. 性能监控工具链入门

SAP S/4HANA 的性能问题很少是单一层次造成的。一个“界面卡顿”的现象，可能来自 ABAP 应用层的低效循环、数据库层的缺失索引、HANA 内存中的列存扫描，也可能是网络往返或前端渲染。因此，运维人员需要一条覆盖“历史趋势—单次追踪—代码级剖析—数据库—HANA 平台”的工具链，而不是只依赖某一个事务码。本节围绕六个核心工具，说明它们各自回答什么问题、在什么场景下使用，以及如何串联成一条排查路径。

先建立工具链的分层认知

可以把这条工具链理解为从“面”到“点”、从“应用”到“平台”的逐层收敛：

• ST03N（工作负载监控）：回答“系统整体忙不忙、哪类任务耗时最多”，提供历史聚合视图。
• ST05（SQL 与性能追踪）：回答“这一次操作到底执行了哪些 SQL、耗时多少”，是单次请求的放大镜。
• ST12（ABAP 与 SQL 组合追踪）：回答“ABAP 代码哪一段慢、对应哪些数据库访问”，把代码与 SQL 关联起来。
• DBACOCKPIT（数据库管理驾驶舱）：回答“数据库层当前状态如何、有哪些等待与告警”。
• HANA Cockpit：回答“HANA 实例的资源、内存、会话、SQL 负载处于什么状态”。
• SQL Monitor（HANA SQL 监控）：回答“某条具体 SQL 在 HANA 中如何执行、瓶颈在哪个算子”。

这六个工具并非互相替代，而是层层递进。下面这张图展示了它们在同一性能问题上的定位与数据流向关系。

ST03N：先看整体，再决定往哪里深挖

ST03N 是工作负载分析的核心入口。它按时间区间聚合系统负载，典型视图包括“工作负载”“任务类型”“用户/会话”“数据库请求”等。运维人员通常先看总响应时间与总数据库时间的变化趋势，再按任务类型（对话、后台、更新、RFC）拆分。例如，若发现某天后台任务的平均数据库时间从 120 ms 突增到 900 ms，而对话任务基本不变，就说明问题更可能集中在批处理 SQL 上，而不是前端或网络。

ST03N 的价值在于“定位方向”，而不是“定位语句”。它不会告诉你具体是哪条 SQL 慢，但会告诉你哪类任务、哪个时间段、哪个应用组件异常。使用时要特别注意时间区间与聚合粒度：过粗会掩盖尖峰，过细则噪声大。建议先看日粒度趋势，再对异常日下钻到小时粒度。

ST05：单次请求的 SQL 放大镜

当 ST03N 指向某个功能或某类任务后，下一步是用 ST05 做单次追踪。典型操作是：先激活追踪（Trace On），在另一个会话中执行目标操作，然后关闭追踪并显示结果。ST05 会列出该操作期间执行的所有 SQL 语句、执行次数、总耗时、平均耗时以及访问的表。

实际使用中，重点看三类信号：一是执行次数异常高的语句，往往对应循环内单条 SELECT；二是单次耗时异常大的语句，可能是缺失索引或全表扫描；三是重复执行的相同语句，说明存在可缓存或可合并的访问。例如，某报表执行 3 秒，ST05 显示同一条 SELECT 被调用 1200 次，每次约 2 ms，总耗时约 2.4 秒，这就明确指向了循环访问问题，而不是数据库本身慢。

ST12：把 ABAP 代码与 SQL 关联起来

ST05 能看到 SQL，但看不到“是哪段 ABAP 代码发出的”。ST12 正是为此设计：它同时记录 ABAP 调用栈与数据库访问，形成代码级剖析。ST12 的典型输出包括调用层次、各代码段的净耗时、数据库请求次数与耗时，以及最耗时的 SQL 列表。

当问题涉及自定义程序、增强或复杂调用链时，ST12 比 ST05 更有效。例如，一个自定义报表在 ST05 中显示大量对某透明表的访问，但无法判断是标准函数还是自定义循环造成的；ST12 可以直接定位到具体 FORM、方法或类，并显示该段代码的数据库时间占比。使用 ST12 时，建议先设置过滤条件（如只追踪特定用户或特定程序），否则结果会非常庞大。

DBACOCKPIT：数据库层的统一驾驶舱

DBACOCKPIT 是 SAP 提供的数据库管理入口，对 HANA 而言，它整合了数据库状态、告警、空间、备份、性能等多个面板。运维人员常用它查看当前等待事件、活动会话、锁、表空间增长以及数据库告警。它的定位是“数据库层总览”，适合在应用层工具指向数据库后，快速确认数据库整体是否健康。

例如，当 ST05 显示某条 SQL 耗时很高时，可以打开 DBACOCKPIT 查看当前是否存在大量锁等待、内存不足或磁盘 I/O 压力。如果数据库整体指标正常，问题更可能在 SQL 本身；如果数据库指标异常，则需要先处理数据库层问题。

HANA Cockpit：HANA 平台的资源与负载视图

HANA Cockpit 是面向 HANA 实例的 Web 管理平台，提供内存、CPU、磁盘、会话、服务、SQL 负载等监控能力。与 DBACOCKPIT 相比，它更贴近 HANA 自身特性，例如列存表大小、内存池使用、行存与列存分布、HANA 内部服务状态等。

典型使用场景包括：确认 HANA 内存是否接近上限、检查是否存在长时间运行的会话、观察 SQL 负载趋势、查看某个服务的资源占用。对于 S/4HANA 系统，HANA Cockpit 是判断“平台层是否成为瓶颈”的关键工具。若 HANA Cockpit 显示内存持续高位、SQL 负载队列增长，则即使应用层代码没有明显问题，也可能出现整体响应变慢。

SQL Monitor：单条 SQL 在 HANA 中的执行真相

SQL Monitor 是 HANA 提供的 SQL 执行分析工具，可以查看某条 SQL 的执行计划、各算子耗时、扫描行数、返回行数、内存消耗等。它回答的是“这条 SQL 在 HANA 内部到底怎么执行、慢在哪个算子”。

使用 SQL Monitor 时，重点关注：是否发生全表扫描、是否使用了错误的连接顺序、是否出现大量中间结果、是否在某个算子（如 JOIN、AGGREGATE、SORT）上耗时集中。例如，一条报表 SQL 在 ST05 中显示耗时 4 秒，SQL Monitor 显示其中 3.5 秒消耗在某个 JOIN 算子，且扫描行数远大于返回行数，这就提示需要检查连接条件、索引或统计信息。

如何串联使用：一条典型排查路径

实际运维中，这六个工具通常按以下顺序收敛：

1. 用 ST03N 发现异常时间段与异常任务类型，确定问题范围。
2. 用 ST05 对目标操作做单次追踪，找出高耗时或高频 SQL。
3. 若涉及自定义代码或复杂调用，用 ST12 定位到具体代码段。
4. 用 DBACOCKPIT 确认数据库整体状态，排除锁、空间、备份等干扰。
5. 用 HANA Cockpit 检查 HANA 资源与负载，判断平台层是否受限。
6. 用 SQL Monitor 对具体 SQL 做执行计划级分析，找到算子级瓶颈。

需要强调的是，这条路径不是固定流程，而是“从面到点”的收敛逻辑。有时 ST03N 已经足够定位问题，有时需要直接进入 SQL Monitor。关键在于理解每个工具回答什么问题，避免在错误的层次反复排查。

工具选择速查