【 使用环境 】生产环境
【 OB or 其他组件 】OCP
【 使用版本 】4.2.2-20240315150922
【问题描述】1-1-1三zone集群。
这台机器cpu负载过高。就想在ocp分析下sql,是哪些慢sql导致的。结果在ocp查询不到任何sql诊断内容。其他两台机器都是正常的。查询了近7天的数据,都显示无数据返回
【复现路径】
根据您提供的信息,OCP 在查询某台机器的 SQL 诊断时无法返回数据,而其他两台机器正常。以下是可能的原因及解决方法:
1. OBServer 节点问题
- 原因:目标 OBServer 节点可能存在异常,例如监控数据未正确上报到 OCP。
-
解决方法:
- 检查该 OBServer 的运行状态是否正常(如 CPU、内存等资源使用情况)。
- 确认 OBServer 是否与 OCP 正常通信。可以通过 OCP 的 节点管理 页面查看该 OBServer 的状态。
- 如果 OBServer 存在异常,尝试重启该 OBServer 节点。
2. 监控数据采集问题
- 原因:OCP 的监控数据采集可能存在延迟或丢失,导致无法获取该 OBServer 的 SQL 数据。
-
解决方法:
- 根据文档片段 7 的描述,SQL 诊断的数据来源于 OCP 的
monitordb
元数据。检查monitordb
中是否包含该 OBServer 的数据。 - 查询
monitordb
中的相关表(如gv$plan_cache_statistic
或gv$sql_audit
),确认是否有该 OBServer 的 SQL 执行记录。SELECT * FROM gv$sql_audit WHERE svr_ip = '172.25.49.130';
- 如果无数据,可能是 OBServer 的监控数据未正确上报,需排查 OBServer 的监控配置。
- 根据文档片段 7 的描述,SQL 诊断的数据来源于 OCP 的
3. OCP 数据同步问题
- 原因:OCP 的数据同步机制可能出现问题,导致部分 OBServer 的数据未能及时同步到 OCP。
-
解决方法:
- 检查 OCP 的日志文件,确认是否存在数据同步相关的错误。
- 尝试刷新 OCP 的缓存,重新加载数据。
4. SQL 执行量过低
- 原因:该 OBServer 上的 SQL 执行量过低,未达到 OCP 的采集阈值。
-
解决方法:
- 根据文档片段 6 和 9 的描述,OCP 的 SQL 诊断功能会筛选出 TopSQL 和 SlowSQL。如果该 OBServer 上的 SQL 执行时间较短或执行频率较低,可能不会被采集。
- 可以通过降低 SlowSQL 的阈值(默认为 100ms),观察是否有数据返回。
5. 硬件或网络问题
- 原因:目标 OBServer 的硬件性能不足或网络连接异常,导致 SQL 数据无法正常上报。
-
解决方法:
- 检查该 OBServer 的硬件性能(如 CPU、内存、磁盘 I/O 等)。
- 确认 OBServer 与 OCP 之间的网络连接是否正常。
综合建议
- 如果以上方法均无法解决问题,建议联系 OceanBase 技术支持团队,提供以下信息以便进一步排查:
- OCP 和 OBServer 的版本信息。
- 目标 OBServer 的运行状态和监控数据。
- OCP 的日志文件。
希望以上建议能帮助您解决问题!如果仍有疑问,请随时反馈。
具体信息可参考以下文档:
- ob_tenant_cpu_usage_over_threshold OceanBase 租户 CPU 使用率超限
- 诊断分析
- 租户性能诊断
- SQL 诊断概述
- ob_host_cpu_percent_over_threshold OB 服务器 CPU 使用率超限
- odp_sql_query_slow 慢查询 SQL 次数超限
- oas_anomaly_sql_from_anomaly_event_analysis_perf_degradation 主机 CPU 超限根因分析,SQL 性能下降
- tenant_cpu_percent_over_threshold OceanBase 租户线程使用率超限
- SQL 诊断
根据您的描述,GV$OB_SQL_AUDIT
视图中查询不到目标 OBServer(svr_ip = '172.25.49.130'
)的 SQL 审计数据。这表明该 OBServer 的 SQL 审计功能可能未正常工作或未生成相关记录。以下是可能的原因及解决方法:
1. 确认 SQL 审计功能是否开启
SQL 审计功能需要显式开启,如果未开启,则不会记录任何 SQL 执行信息。
检查 enable_sql_audit
参数状态:
SHOW PARAMETERS LIKE 'enable_sql_audit';
- 如果返回值为
false
,说明 SQL 审计功能未开启。 - 如果返回值为
true
,说明 SQL 审计功能已开启。
开启 SQL 审计功能:
如果未开启,可以通过以下命令开启:
ALTER SYSTEM SET enable_sql_audit = true;
注意:此操作会全局生效,影响所有 OBServer 节点。
2. 检查目标 OBServer 是否正常上报数据
即使 SQL 审计功能开启,如果目标 OBServer 的监控数据未正确上报到 OCP 或其他管理工具,也可能导致无法查询到数据。
检查 OBServer 的运行状态:
在 OCP 或通过 obclient
查询目标 OBServer 的状态:
SELECT * FROM oceanbase.__all_server WHERE svr_ip = '172.25.49.130';
- 确认
status
是否为ACTIVE
。 - 如果状态异常(如
INACTIVE
或STOPPED
),需重启该 OBServer 节点。
检查 OBServer 的监控数据上报:
确保 OBServer 的监控数据能够正常上报到 OCP。可以通过 OCP 的节点管理页面查看该 OBServer 的状态和监控数据。
3. 检查目标 OBServer 的 SQL 执行情况
如果目标 OBServer 上没有实际执行过 SQL,GV$OB_SQL_AUDIT
中自然不会有记录。
检查 OBServer 的 SQL 执行历史:
查询目标 OBServer 的 SQL 执行历史:
SELECT * FROM GV$OB_SQL_EXECUTION WHERE svr_ip = '172.25.49.130';
- 如果无数据,说明该 OBServer 上确实没有执行过 SQL。
- 如果有数据,但未出现在
GV$OB_SQL_AUDIT
中,可能是审计数据丢失或未正确记录。
4. 调整 SQL 审计内存配置
SQL 审计数据存储在内存中,受 ob_sql_audit_percentage
参数控制。如果内存不足或配置过低,可能导致审计数据被快速淘汰。
查询当前配置:
SHOW GLOBAL VARIABLES LIKE 'ob_sql_audit_percentage';
调整配置:
如果当前值较低(如默认值为 3%),可以适当增加:
SET GLOBAL ob_sql_audit_percentage = 10;
注意:调整此参数会占用更多租户内存,请根据实际资源情况合理设置。
5. 检查 OBServer 的日志
如果以上步骤均未发现问题,建议检查目标 OBServer 的日志文件,确认是否存在异常。
日志路径:
通常位于 /home/admin/oceanbase/log/observer.log
。
关键日志关键字:
sql_audit
audit_record
通过搜索这些关键字,可以定位是否因某些原因导致 SQL 审计数据未生成。
6. 重启目标 OBServer
如果问题仍未解决,可以尝试重启目标 OBServer 节点,以清除可能的缓存或状态异常。
停止 OBServer:
obd cluster stop <cluster_name>
启动 OBServer:
obd cluster start <cluster_name>
7. 联系技术支持
如果经过以上步骤仍无法解决问题,建议联系 OceanBase 技术支持团队,提供以下信息以便进一步排查:
- 集群版本(您提到的是 4.2.2)。
- 目标 OBServer 的运行状态和日志。
- OCP 的相关配置和日志。
希望以上建议能帮助您恢复目标 OBServer 的 SQL 审计功能!如果仍有疑问,请随时反馈。
更多信息请查看:
现在查看有数据吗