ocp查询sql诊断,其中一台机器查询不到数据

【 使用环境 】生产环境
【 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_statisticgv$sql_audit),确认是否有该 OBServer 的 SQL 执行记录。
      SELECT * FROM gv$sql_audit WHERE svr_ip = '172.25.49.130';
      
    • 如果无数据,可能是 OBServer 的监控数据未正确上报,需排查 OBServer 的监控配置。

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 的日志文件。

希望以上建议能帮助您解决问题!如果仍有疑问,请随时反馈。

具体信息可参考以下文档:

  1. ob_tenant_cpu_usage_over_threshold OceanBase 租户 CPU 使用率超限
  2. 诊断分析
  3. 租户性能诊断
  4. SQL 诊断概述
  5. ob_host_cpu_percent_over_threshold OB 服务器 CPU 使用率超限
  6. odp_sql_query_slow 慢查询 SQL 次数超限
  7. oas_anomaly_sql_from_anomaly_event_analysis_perf_degradation 主机 CPU 超限根因分析,SQL 性能下降
  8. tenant_cpu_percent_over_threshold OceanBase 租户线程使用率超限
  9. SQL 诊断

@论坛小助手
执行sql :
SELECT * FROM GV$OB_SQL_AUDIT WHERE svr_ip = ‘172.25.49.130’;

显示无数据。如何让这台机器恢复正常

根据您的描述,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
  • 如果状态异常(如 INACTIVESTOPPED),需重启该 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 审计功能!如果仍有疑问,请随时反馈。

更多信息请查看:

  1. GV$OB_SQL_AUDIT
  2. V$OB_SQL_AUDIT
  3. GV$OB_UNITS
  4. 分析 SQL 监控视图

在ocp中, 关闭sql采集,重新打开。恢复了。。。 产生原因还是未知

现在查看有数据吗