部署的新版本ocp与ob在sql诊断还是

【 使用环境 】测试环境
【 OB or 其他组件 】OCP
【 使用版本 】OB4.2.5.2 OCP4.3.5
【问题描述】
均部署在固态硬盘上
问题1：sys租户与创建的租户查询sql诊断都无数据
问题2：部署好的时候访问很快但是第二天访问加载十分慢不知道是什么原因

image1920×926 25.1 KB

image1898×435 32.6 KB

【复现路径】根据论坛小助手能查询到sql执行的记录，且这两个参数确定开启的

image1120×186 13.5 KB

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

根因分析场景: 事务等待超时报错
根因分析命令: obdiag rca run --scene=transaction_wait_timeout
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

推荐使用 obdiag 工具进行根因分析和日志采集，以便确认问题所在。上述命令将帮助您收集 SQL 性能相关的诊断信息，并分析是否存在事务等待超时的情况。

麻烦您提供一些信息以便我们更好地帮助您：

1. 您是否在 OCP 上配置了特定的资源限制或参数调整？如果有，请提供相关设置。
2. 您提到“SQL 诊断无数据”，能否确认是否有启用 SQL 审计功能？如果没有，请检查是否已开启此功能。
3. 第二天访问加载变慢的具体表现是什么？例如，是所有查询都变慢还是特定类型的查询受到影响？
4. 是否可以提供发生问题的时间段，以及在此时间段内的典型 SQL 语句？
5. 您是否观察到系统资源（如 CPU、内存、磁盘 I/O）在第二天有任何异常变化？如果有，请描述具体情况。

附上敏捷诊断工具 obdiag 使用帮助链接

1.查下sys租户及创建的这些租户

select count(*) from gv$ob_sql_audit;

2.ocp_meta，ocp_monitor及ocp应用的内存配置各是多少，
看下ocp_meta，ocp_monitor的监控以及ocp-server的负载

。，

内存配置都是4

image966×693 56 KB

根据您提供的信息，以下是针对问题的分析和解决方案：

问题 1：sys 租户与创建的租户查询 SQL 诊断都无数据

原因分析

1. SQL 审计功能未开启
   根据您上传的图片内容，gv$ob_sql_audit 视图为空（ERROR 1046 (30000): No database selected），这表明 SQL 审计功能可能未正确开启。

   • enable_sql_audit 参数需要在租户级别设置为 ON，才能记录 SQL 执行信息。
   • 如果该参数未开启，SQL 诊断页面将无法显示任何数据。

2. 权限问题
   确保当前用户具有访问 gv$ob_sql_audit 视图的权限。如果权限不足，也可能导致查询结果为空。

解决步骤

1. 检查并开启 enable_sql_audit 参数
   在 sys 租户和目标租户中执行以下命令，确保参数已开启：

   -- 切换到 sys 租户
   obclient> ALTER SYSTEM SET enable_sql_audit = ON;
   
   -- 切换到目标租户（例如 ocp_meta）
   obclient> ALTER TENANT ocp_meta SET enable_sql_audit = ON;
   

2. 验证 SQL 审计功能是否生效
   执行一些测试 SQL，并检查 gv$ob_sql_audit 是否有记录：

   obclient> SELECT COUNT(*) FROM gv$ob_sql_audit;
   

   如果返回非零值，则说明审计功能正常工作。

3. 确认权限
   确保 OCP 使用的数据库用户具有访问 gv$ob_sql_audit 的权限。可以通过以下命令授予权限：

   obclient> GRANT SELECT ON oceanbase.gv$ob_sql_audit TO your_user;
   

问题 2：部署好的时候访问很快，但第二天访问加载十分慢

原因分析

1. 资源争用

   • 您提到内存配置为 4 GiB，CPU 配置为 2 vCPU。如果系统负载较高，可能导致资源争用，从而影响性能。
   • 第二天访问变慢可能是由于后台任务（如统计信息收集、日志归档等）占用了较多资源。

2. 缓存失效

   • OceanBase 的查询性能依赖于内存中的缓存。如果缓存被频繁刷新或失效，可能导致查询变慢。

3. 网络延迟

   • 如果 OCP 和 OB 部署在不同的物理节点上，网络延迟可能会影响访问速度。

4. OCP 内部问题

   • OCP 自身可能存在某些问题，例如采集项过多或配置不当，导致性能下降。

解决步骤

1. 检查系统资源使用情况

   • 登录到 OB 集群节点，查看 CPU、内存、磁盘 I/O 的使用情况：

     top  # 查看 CPU 使用情况
     free -m  # 查看内存使用情况
     iostat -x 1  # 查看磁盘 I/O 使用情况
     

   • 如果发现资源使用率过高，可以尝试优化资源配置。

2. 分析 OCP 日志

   • 检查 OCP 的日志文件，定位是否存在异常错误或警告信息。日志路径通常为：

     /home/admin/ocp/logs/
     

3. 减少采集项

   • 如果 OCP 配置了过多的采集项，可能会增加系统负担。建议参考文档片段 9，筛选必要的采集项。

4. 重启 OCP 和 OB 服务

   • 如果问题持续存在，可以尝试重启 OCP 和 OB 服务，清理缓存并重新初始化系统状态。

5. 使用 obdiag 工具进行诊断

   • 使用 obdiag 工具收集性能相关的日志和诊断信息：

     obdiag gather scene run --scene=observer.perf_sql --env "{db_connect='-h127.0.0.1 -P2881 -utest@test -p****** -Dtest', trace_id='Yxx'}"
     

总结

• 对于问题 1，建议检查并开启 enable_sql_audit 参数，同时确保用户权限正确。
• 对于问题 2，建议从资源使用、缓存状态、网络延迟和 OCP 配置等方面逐一排查，并使用 obdiag 工具辅助诊断。

如果问题仍未解决，请提供更多详细信息（如具体 SQL 语句、系统日志等），我们将进一步协助您分析和解决问题。

更多信息请查看:

1. OCP V3.3.5
2. 常见内存问题
3. 集群总览
4. backup_storage_capacity_retry_times_exceeded 备份恢复容量获取重试次数超限
5. 配置自定义监控
6. backup_storage_capacity_timeout_or_interrupted 备份恢复目录容量获取超时或线程被中断
7. range_optimizer_max_mem_size
8. 查看内存的使用信息
9. 查看采集项
10. cpu_count

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

这样查吧

select count(*) from oceanbase.gv$ob_sql_audit group by TENANT_ID, SVR_IP;

学习了

学到了！！

努力学习，总结经验

跟着学习

解决了吗？

学习了！！1

没有

看不出问题方向来了

OCP管理的集群规模怎样呢？例如管理了多少套集群，多少台observer，多少个租户，数据量规模？

另外麻烦取下不显示SQL诊断数据的集群的monagent.log日志

image2910×1280 321 KB