---
title: 编组
description: 了解OceanBase数据库在实际应用中关于 OceanBase 的 TRACE EVENT 是如何采集和实现的相关的常见问题和使用技巧，帮助您快速解决 OceanBase 的 TRACE EVENT 是如何采集和实现的的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# OceanBase 的 TRACE EVENT 是如何采集和实现的

更新时间：2024-01-22 01:56

适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x 内容类型：TechNote  

OceanBase 日志中有很多类似如下的日志，这些信息是如何采集的，耗时是如何计算的。

```shell
[2022-07-08 11:26:20.535074] TRACE [TRACE]obmp_base.cpp:948 [59127][2532][YB420A0A34F5-0005E247B18CF116] [lt=16] [dc=0] [slow query](TRACE=begin_ts=1657250749896387 2022-07-08 03:25:49.896387|[process_begin] u=0 in_queue_time:11, receive_ts:1657250749896375, enqueue_ts:1657250749896376|[start_sql] u=0 addr:{ip:"10.xx.xx.xxx", port:3xxxx}|[query_begin] u=1 trace_id:YB420A0A34F5-0005E247B18CF116|[before_processor_run] u=4 |[session] u=2 sid:3223166492, tenant_id:1013|[parse_begin] u=16 stmt:"select * from ac01 where aac002 = '510xxxxxxxxxxxxxxx';", stmt_len:55|[cache_get_plan_begin] u=4 |[calc_partition_location_begin] u=64 |[tl_calc_by_range_end] u=10 |[tl_calc_part_id_end] u=0 |[get_location_cache_begin] u=0 |[get_location_cache_end] u=182 |[calc_partition_location_end] u=1 |[pc_choose_plan] u=46 |[check_priv] u=25 |[cache_get_plan_end] u=0 |[plan_id] u=1 plan_id:9320739|[exec_begin] u=2 arg1:false, end_trans_cb:false|[post_packet] u=46 ret:0, pcode:1808, addr:{ip:"10.xx.xx.xxx", port:2xxx}|[do_open_plan_begin] u=557 plan_id:9320739|[sql_start_stmt_begin] u=1 |[sql_start_stmt_end] u=0 |[exec_plan_begin] u=1 |[exec_plan_end] u=14 |[sql_start_participant_begin] u=0 |[sql_start_participant_end] u=1 |[do_open_plan_end] u=1 |[post_packet] u=533 ret:0, pcode:1311, addr:{ip:"10.xx.xx.xxx", port:28xx}|[post_packet] u=109 ret:0, pcode:1311, addr:{ip:"10.xx.xx.xxx", port:2xxx}|[post_packet] u=93 ret:0, pcode:1311, addr:{ip:"10.xx.xx.xxx", port:2xxx}|[post_packet] u=90 ret:0, pcode:1311, addr:{ip:"10.xxx.xx.xxx", port:2xxx}|[post_packet] u=88 ret:0, pcode:1311, addr:{ip:"10.xx.xx.xxx", port:2xxx}|[post_packet] u=93 ret:0, pcode:1311, addr:{ip:"10.xx.xx.xxx", port:2xxx}|[post_packet] u=85 ret:0, pcode:1311, addr:{ip:"10.xx.xx.xxx", port:2xxx}|[post_packet] u=88 ret:0, pcode:1311, addr:{ip:"10.xx.xx.xxx", port:2xxx}|[post_packet] u=87 ret:0, pcode:1311, addr:{ip:"10.xx.xx.xxx", port:2xxx}|[sqc_finish] u=387 dfo_id:0, sqc_id:0|[sqc_finish] u=129 dfo_id:0, sqc_id:4|[sqc_finish] u=134 dfo_id:0, sqc_id:3|[sqc_finish] u=3 dfo_id:0, sqc_id:2|[sqc_finish] u=135 dfo_id:0, sqc_id:6|[sqc_finish] u=45 dfo_id:0, sqc_id:5|[sqc_finish] u=61 dfo_id:0, sqc_id:8|[sqc_finish] u=447 dfo_id:0, sqc_id:7|[sqc_finish] u=30634787 dfo_id:0, sqc_id:1|[close_plan_begin] u=8 |[end_participant_begin] u=100 |[end_participant_end] u=0 |[start_end_stmt] u=0 |[end_stmt] u=0 |[close_plan_end] u=0 |[affected_rows] u=1 affected_rows:0|[store_found_rows] u=0 found_rows:0, return_rows:1|[auto_end_plan_begin] u=1 |[auto_end_plan_end] u=2 |[result_set_close] u=0 ret:0, arg1:0, arg2:0, arg3:-4008, async:false|[exec_end] u=16 |[query_end] u=100 |[process_end] u=17 run_ts:1657250749896392|total_timeu=30638618)

```

这段日志采集了一次 SQL 查询的执行信息，记录了该查询的执行路径、时间戳、持续时间、资源消耗以及其他相关信息。以下是这段日志中记录的信息和用户可以如何使用。

- 时间戳和持续时间：记录了操作开始的时间戳（begin_ts）和操作的持续时间（total_timeu），可以用于分析操作的执行时间和耗时情况。
 - 执行路径：通过多个 [xxx_begin] 和 [xxx_end] 的记录，可以追踪操作的执行路径，包括解析（parse_begin）、缓存获取计划（cache_get_plan_begin）、计算分区位置（calc_partition_location_begin）、执行计划（exec_plan_begin）等。用户可以根据执行路径来了解操作的各个阶段和函数调用关系。
 - 资源消耗：记录了操作期间使用的系统资源，如 CPU 时间、内存的分配和释放等。用户可以通过这些信息评估操作对系统资源的消耗情况，以及性能优化的方向。
 - SQL语句和参数：记录了执行的 SQL 语句和相关参数，如 `stmt:"select * from ac01 where aac002 = '510xxxxxxxxxxxxxxx';"`。这对于了解具体执行的 SQL 语句和参数是非常有用的。
 - 错误和异常信息：如果操作发生错误或异常，会记录相关的错误码、异常信息和堆栈跟踪。用户可以根据这些信息进行故障排查和错误定位。

用户可以通过分析这些日志信息来进行以下操作。

- 性能分析：根据时间戳和持续时间，用户可以评估查询的执行时间和性能瓶颈，找出潜在的优化点，并进行性能调优。
 - 故障排查：如果查询出现错误或异常，用户可以根据错误信息和堆栈跟踪来定位问题的根源，并进行故障排查和修复。
 - SQL 优化：通过分析执行路径和计划 ID 等信息，用户可以评估 SQL 查询的优化效果，选择更优的查询计划，并进行 SQL 调优。
 - 资源管理：根据资源消耗的记录，用户可以评估操作对系统资源的占用情况，优化资源分配和管理策略。

这些信息的采集以及耗时的计算原理如下。

- 一条 SQL 在 OceanBase 内运行，运行过程中会触发 OceanBase 内多个采集事件，OceanBase 会将触发的采集事件的相关信息进行存储，这些信息包括 `event_name`、执行时间戳等，当 SQL 执行结束，这些存储的信息会经过二次加工，通过 `observer.log` 日志进行输出。
 - 二次加工的主要工作是计算各个采集事件的耗时，`u=xxxx` 表示的是本次采集事件和前一个采集事件之间的间隔，单位是 us。

## 适用版本

OceanBase 数据库 V2.x 和 V3.x 版本。

上一篇

[SQL_ID, Plan_ID 与 Plan_hash](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000217866)

下一篇

[OceanBase 数据库的 sql_id 和 plan_id 的稳定性介绍](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000000038) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线
