--- title: "SQL Audit - OceanBase 数据库 V4.5.0 | OceanBase 文档中心" description: SQL Audit GV$OB_SQL_AUDIT 是最常用的 SQL 监控视图，能够记录每一次 SQL 请求的来源、执行状态、资源消耗及等待事件，除此之外还记录了 SQL 文本、执行计划等关键信息。该视图是诊断 SQL 问题的利器。 该视图字段较多，我们分段介绍。其主要字段介绍如下： TENANT_ID ：请求的租… --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.5.0 # SQL Audit 更新时间：2026-04-09 19:53:00 [编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.5.0/zh-CN/600.manage/700.monitor/200.monitor-items-introduction/300.sql-monitor/200.sql-audit.md) `GV$OB_SQL_AUDIT` 是最常用的 SQL 监控视图，能够记录每一次 SQL 请求的来源、执行状态、资源消耗及等待事件，除此之外还记录了 SQL 文本、执行计划等关键信息。该视图是诊断 SQL 问题的利器。 该视图字段较多，我们分段介绍。其主要字段介绍如下： - `TENANT_ID`：请求的租户 ID。 - `SVR_IP`：接受请求的服务端节点 IP。 - `CLIENT_IP`：发送请求的客户端 IP。 - `REQUEST_TIME`：请求到达时间。 - `REQUEST_ID`：请求的 ID，标识请求的一次执行，随时间而递增。外部监控系统可以将该字段作为游标拉取审计信息。 - `IS_INNER_SQL`：是否内部 SQL 请求。 - `IS_EXECUTOR_RPC`：当前请求是否 RPC 请求。 - `SQL_ID`：标识一条具体的 SQL，同一条 SQL 的多次执行具有相同的 `SQL_ID` 和不同的 `REQUEST_ID`。 - `QUERY_SQL`：SQL 语句完整的文本。OceanBase 数据库支持通过 `SQL_ID` 和 `SQL_TEXT` 绑定执行计划。 - `SID`：标识一个 Session，可以关联该连接上的所有 SQL，及等待事件。对应 `GV$OB_PROCESSLIST` 视图中的 `ID` 字段。 - `TX_ID`：标识一个事务，可以关联该事务的所有 SQL。如果一个事务中连续执行的两条 SQL 的起止时间存在较大差距，说明链路上的耗时较大。 - `TRACE_ID`：该 SQL 请求的 trace ID，可以关联查询其他监控指标，也可以关联查询日志。 - `IS_HIT_PLAN`：是否命中 Plan Cache 中的 Plan。SQL 优化比较耗时，为了避免反复执行 SQL 优化，会将生成的计划放进 Plan Cache，再次执行时直接从 Plan Cache 获取 Plan。未命中 Plan Cache 的情况称为硬解析，命中 Plan Cache 的情况称为软解析。硬解析会影响 SQL 性能，增加耗时。如果租户 Plan Cache 命中率过低，需要确认 Plan Cache 空间是否过小导致 Plan 频繁被淘汰。 - `PLAN_ID`：执行计划 ID，可以关联查询该计划的详细信息和统计信息。 - `PLAN_HASH`：执行计划的 Hash 值。 - `PLAN_TYPE`：执行计划的类型，取值为 `0`、`1`、`2`、`3`，其中：`1`、`2`、`3` 分别对应本地计划、远程计划、分布式计划；`0` 表示无执行计划，例如 commit 语句。 - `AFFECTED_ROWS`：影响行数。 - `RETURN_ROWS`：返回行数。 - `RET_CODE`：执行结果返回码。 - `EVENT`：最长等待事件名称。 - `P1TEXT ~ P3TEXT`：等待事件参数 1 ~ 3。 - `P1 ~ P3`：等待事件参数的值 1~3。 - `LEVEL`：等待事件的 level 级别。 - `WAIT_CLASS_ID`：等待事件所属的类别 ID。 - `WAIT_CLASS`：等待事件所属的类别名称。 - `STATE`：等待事件的状态。 - `WAIT_TIME_MICRO`：该等待事件所等待的时间（微秒）。 - `TOTAL_WAIT_TIME_MICRO`：执行过程所有等待的总时间（微秒）。 - `TOTAL_WAITS`：执行过程总等待的次数。 - `ELAPSED_TIME`：本次执行的总时间（从请求到达到执行结束），由多个子阶段组成： - `NET_TIME`：发送 RPC 到接收到请求的时间。 - `NET_WAIT_TIME`：接收到请求到进入队列时间。 - `QUEUE_TIME`：队列时间，反映当前租户的请求积压情况。 - `DECODE_TIME`：出队列后 Decode 时间。 - `GET_PLAN_TIME`：生成执行计划的时间，反映当前租户 Plan Cache 的健康状况。 - `EXECUTE_TIME`：计划的执行时间。 - `EXECUTE_TIME`：本次实际执行的时间，由 CPU 时间和 `TOTAL_WAIT_TIME_MICRO` 组成。`TOTAL_WAIT_TIME_MICRO` 由 `APPLICATION_WAIT_TIME`、`CONCURRENCY_WAIT_TIME`、`USER_IO_WAIT_TIME`、`SCHEDULE_TIME` 等几个部分组成。`EXECUTE_TIME` 为实际上花费执行的总时间，包含 CPU 计算所需的时间（`CPU_TIME`）和各种等待时间（`TOTAL_WAIT_TIME_MICRO`）。 - `APPLICATION_WAIT_TIME`：所有 application 类事件的总时间。 - `CONCURRENCY_WAIT_TIME`：所有 concurrency 类事件的总时间。 - `USER_IO_WAIT_TIME`：所有 `user_io` 类事件的总时间。 - `SCHEDULE_TIME`：所有`schedule 类事件的时间。 - 逻辑读：请求执行中读取数据时会首先读取各级缓存（对应 `ROW_CACHE_HIT`、`BLOOM_FILTER_CACHE_HIT`、`BLOCK_CACHE_HIT` 等字段），如果全部没有命中会产生一次实际的磁盘读取（对应 `DISK_READS` 字段）。通过统计缓存读取次数和磁盘读取次数，可以得出该请求执行过程中扫描行数的多少（扫描行数不等于实际物理读，会首先扫描各级缓存），从而判断该 SQL 是否需要优化。 - `ROW_CACHE_HIT`：行缓存命中次数。 - `BLOOM_FILTER_CACHE_HIT`：bloom filter缓存命中次数。 - `BLOCK_CACHE_HIT`：块缓存命中次数。 - `DISK_READS`：物理读次数。 - `RETRY_CNT`：重试次数。 - `TABLE_SCAN`：判断该请求是否含全表扫描。 - `CONSISTENCY_LEVEL`：一致性级别。 - `MEMSTORE_READ_ROW_COUNT`：MemStore 中读的行数。 - `SSSTORE_READ_ROW_COUNT`：SSStore 中读的行数。 - `REQUEST_MEMORY_USED`：该请求消耗的内存。 - `INSERT_DUPLICATE_ROW_COUNT`: 记录 `insertup` 或者 `replace into` 时重复行数的数量 `GV$OB_SQL_AUDIT` 视图的数据存放在一个可配置的内存空间中，每个租户在每个节点上都有一块独立的缓存，当内存使用或记录数达到淘汰上限时会触发自动淘汰，最久的数据优先淘汰。有经验的 DBA 在排查 SQL 问题时，往往第一件事就是关闭 SQL Audit 功能以保存现场，避免抖动现场的监控数据被淘汰。 通过以下参数可以控制 SQL Audit 功能的行为： - `enable_sql_audit`：集群配置项，控制全部租户的 SQL Audit 功能是否开启，动态生效。 - `ob_enable_sql_audit`：租户级别的系统变量，控制当前租户是否开启 SQL Audit 功能，动态生效。 - `ob_sql_audit_percentage`：租户级别的系统变量，控制当前租户 SQL Audit 功能占用租户内存的百分比，动态生效。为防止 SQL Audit 占用过高内存，系统设置其内存上限为 1GB。 通过 `GV$OB_SQL_AUDIT` 视图，我们可以方便的查询 SQL 执行的各种维度信息。 - 查询执行耗时超过 100ms 的 SQL。 ```shell obclient> select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10; +------------+----------------------------+--------------+------------+--------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ | request_id | usec_to_time(request_time) | ELAPSED_TIME | QUEUE_TIME | EXECUTE_TIME | query_sql | +------------+----------------------------+--------------+------------+--------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ | 1538599798 | 2023-03-08 11:00:46.089711 | 335152 | 462 | 329196 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | | 1538601580 | 2023-03-08 11:00:47.411316 | 276913 | 1420 | 275345 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | | 1538603976 | 2023-03-08 11:00:49.258464 | 154873 | 461 | 154236 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | | 1538613501 | 2023-03-08 11:00:56.123111 | 188973 | 688 | 188144 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | | 1538712684 | 2023-03-08 11:02:07.504777 | 288516 | 1137 | 287180 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | | 1538743161 | 2023-03-08 11:02:29.135127 | 289585 | 26 | 289380 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | | 1538749786 | 2023-03-08 11:02:33.890317 | 294356 | 45 | 294180 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | | 1538792259 | 2023-03-08 11:03:04.626596 | 192843 | 128 | 192569 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | | 1538799117 | 2023-03-08 11:03:09.567622 | 201594 | 55 | 201388 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | | 1538804299 | 2023-03-08 11:03:13.274090 | 235720 | 241 | 235302 | select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 100000 limit 10 | +------------+----------------------------+--------------+------------+--------------+------------------------------------------------------------------------------------------------------------------------------------------------------+ 10 rows in set (0.28 sec) ``` - 查询最近 1000 条 SQL 的平均排队时间。 ```shell obclient> select /*+ query_timeout(30000000) */ avg(queue_time) from v$OB_SQL_AUDIT where request_id > (select max(request_id) from v$OB_SQL_AUDIT) - 1000 ; +-----------------+ | avg(queue_time) | +-----------------+ | 350.8740 | +-----------------+ 1 row in set (0.26 sec) ``` - 查询占用租户资源最多的 SQL，按照 `执行时间 * 执行次数` 倒序排序，如果该租户当前存在容量不足（租户 CPU 使用率被打爆），可以通过该语句判断是否为 SQL 问题，及疑点 SQL。 ```shell obclient> select SQL_ID, avg(ELAPSED_TIME), avg(QUEUE_TIME), avg(ROW_CACHE_HIT + BLOOM_FILTER_CACHE_HIT + BLOCK_CACHE_HIT + DISK_READS) avg_logical_read, avg(execute_time) avg_exec_time, count(*) cnt, avg(execute_time - TOTAL_WAIT_TIME_MICRO ) avg_cpu_time, avg( TOTAL_WAIT_TIME_MICRO ) avg_wait_time, WAIT_CLASS, avg(retry_cnt) from v$OB_SQL_AUDIT group by 1 order by avg_exec_time * cnt desc limit 10; +----------------------------------+-------------------+-----------------+------------------+---------------+--------+--------------+---------------+------------+----------------+ | SQL_ID | avg(ELAPSED_TIME) | avg(QUEUE_TIME) | avg_logical_read | avg_exec_time | cnt | avg_cpu_time | avg_wait_time | WAIT_CLASS | avg(retry_cnt) | +----------------------------------+-------------------+-----------------+------------------+---------------+--------+--------------+---------------+------------+----------------+ | 2705182A6EAB699CEC8E59DA80710B64 | 54976.9269 | 43.8605 | 17664.2727 | 54821.5828 | 11759 | 54821.5828 | 0.0000 | OTHER | 0.0000 | | 32AB97A0126F566064F84DDDF4936F82 | 1520.9832 | 380.7903 | 63.7847 | 789.6781 | 63632 | 789.6781 | 0.0000 | OTHER | 0.0000 | | A5F514E873BE9D1F9A339D0DA7481D69 | 44032.5553 | 44.5149 | 8943.7834 | 43878.1405 | 1039 | 43878.1405 | 0.0000 | OTHER | 0.0000 | | 31FD78420DB07C11C8E3154F1658D237 | 7769857.0000 | 35.7500 | 399020.7500 | 7769682.7500 | 4 | 7769682.7500 | 0.0000 | NETWORK | 1.0000 | | C48AEE941D985D8DEB66892228D5E845 | 8528.6227 | 0.0000 | 0.0000 | 8450.4047 | 1601 | 8450.4047 | 0.0000 | OTHER | 0.0000 | | 101B7B79DFA9AE801BEE4F1A234AD294 | 158.2296 | 41.7211 | 0.0000 | 46.0345 | 286758 | 46.0345 | 0.0000 | OTHER | 0.0000 | | 1D0BA376E273B9D622641124D8C59264 | 1774.5924 | 0.0049 | 0.0000 | 1737.4885 | 5081 | 1737.4885 | 0.0000 | OTHER | 0.0000 | | 64CF75576816DB5614F3D5B1F35B1472 | 1801.8767 | 747.0343 | 0.0000 | 827.1674 | 10340 | 827.1674 | 0.0000 | OTHER | 0.0000 | | 23D1C653347BA469396896AD9B20DCA1 | 5564.9419 | 0.0000 | 0.0000 | 5478.2228 | 1257 | 5478.2228 | 0.0000 | OTHER | 0.0000 | | FA4F493FA5CE2DCC64F51CF3754F96C6 | 2478.3956 | 378.7557 | 3.1040 | 1731.1802 | 3357 | 1731.1802 | 0.0000 | OTHER | 0.0000 | +----------------------------------+-------------------+-----------------+------------------+---------------+--------+--------------+---------------+------------+----------------+ 10 rows in set (1.34 sec) ``` #### 说明 - 租户抖动时，表现一般是 “租户 CPU 被打满” 和 “所有 SQL RT 飙升”，此时首要判断 SQL RT 飙升是否是第一案发现场（是 SQL 自己的问题导致 RT 飙升，还是其他问题导致 SQL RT 飙升）。 - 上面介绍的这条 SQL 是一大利器，基于 `SQL_ID` 做聚合，按照资源占用量倒序排序（资源占用量可以认为是 `avg_exec_time * cnt`），观察 top 几条 SQL 是否存在明显异常，从而判断是否是第一案发现场。 上一篇 下一篇 ![有帮助](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) 咨询热线