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

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OCP
【 使用版本 】4.2.2-20240315150922
【问题描述】1-1-1三zone集群。
这台机器cpu负载过高。就想在ocp分析下sql，是哪些慢sql导致的。结果在ocp查询不到任何sql诊断内容。其他两台机器都是正常的。查询了近7天的数据，都显示无数据返回
【复现路径】

image
image1698×609 45.9 KB

#3

@论坛小助手

#4

根据您提供的信息，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 的监控配置。

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 诊断
#5

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

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

#6

根据您的描述，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 审计功能！如果仍有疑问，请随时反馈。

更多信息请查看:

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

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

image
image1876×764 131 KB

#9

现在查看有数据吗

#10

有的